开源软件本质上比闭源软件更安全的概念——或相反的概念——是无稽之谈。当人们说这样的话时，它通常只是FUD，并没有有意义地推进讨论。

要对此进行推理，您必须将讨论限制在特定项目中。一款针对特定需求的软件，由特定团队创建，并具有明确的目标受众。对于这样的特定情况，可以推断开源或闭源是否最适合该项目。

推销所有“开源”与所有“闭源”实现的问题在于，这不仅仅是比较许可证。在实践中，开源受到必须志愿工作的青睐，而闭源最常见于商业工作。所以我们实际上是在比较：

• 许可证。
• 访问源代码。
• 非常不同的激励结构，营利与娱乐。
• 非常不同的法律责任情况。
• 不同且千变万化的团队规模和团队技能组合。
• 等等。

试图判断所有这些对于作为开放/封闭源代码发布的所有软件的安全性如何发挥作用只是失败了。它成为一种观点陈述，而不是事实。

维护的软件比没有维护的软件更安全。当然，维护工作与所述软件的复杂性和正在查看它的人的数量（和技能）有关。开源系统更安全的理论是有“很多眼睛”在看源代码。但这在很大程度上取决于系统的普及程度。

例如，2008 年在 OpenSSL 中发现了几个缓冲区溢出，其中一些导致远程代码执行。这些错误在代码中已经存在好几年了。因此，尽管 OpenSSL 是开源的并且拥有庞大的用户群（毕竟这是用于 HTTPS 网站的主要 SSL 库），但源代码审核员的数量和技能不足以克服 ASN.1 解码固有的复杂性（漏洞潜伏的 OpenSSL 部分）和 OpenSSL 源代码（坦率地说，这不是有史以来最易读的 C 源代码）。

平均而言，闭源系统进行问答的人要少得多。但是，许多闭源系统已经支付了开发人员和测试人员的费用，他们可以全职从事这项工作。这并不是打开/关闭问题所固有的；一些公司雇用人员来开发开源系统，并且可以想象，人们可以免费生产封闭源代码软件（这在 Windows 的“免费软件”的情况下相对常见）。然而，付费测试人员和封闭源代码之间仍然存在很强的相关性（相关性并不意味着因果关系，但这并不意味着相关性也应该被忽略）。

另一方面，封闭源代码更容易隐藏安全问题，这当然是不好的。

有开源和闭源系统的例子，有很多或很少的安全问题。开源 *BSD 操作系统（FreeBSD、NetBSD和OpenBSD以及其他一些）在安全性方面有着非常好的记录。Solaris 也是如此，即使它是一个闭源操作系统。另一方面，Windows 在这方面的名声很糟糕。

总结：在我看来，“开源意味着安全”的想法被高估了。重要的是用于跟踪和修复安全问题的时间（和技能），这主要与源的开放性问题正交。但是，您不仅想要一个安全的系统，还想要一个您肯定知道是安全的系统（不被盗很重要，但也能在晚上睡觉）。对于这个角色，开源系统有一点优势：当系统是开源的时，更容易让人相信没有故意隐藏的安全漏洞。但是信任是一件微不足道的事情，正如最近围绕OpenBSD 中所谓的后门的悲喜剧所证明的那样 （据我所知，事实证明这是一条红鲱鱼，但从概念上讲，除非我自己检查代码，否则我无法确定）。

我认为最简单、最简单的方法是软件工程。论据通常如下：开源软件更安全，因为你可以看到源代码！

您是否具备自上而下理解内核的软件工程知识？当然，您可以查看这样的驱动程序，但是您是否完全了解真正说“啊是的，那里一定有错误”的情况？

这是一个有趣的例子：不久前，一个空指针取消引用错误出现在一个 beta 内核中，这是一件相当大的事情，由来自 grsecurity（PaX 补丁）的人发现：

• LWN 文章
• 斜线点覆盖

它是在这样的一段代码中引入的：

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

并且pointer == NULL编译器正确地优化了检查 - 因为空指针不能取消引用到包含成员的结构，所以函数中的指针永远为空是没有意义的。然后，编译器会删除开发人员预期在那里的检查。

因此，与 vis 相对，一致地，这样一个大型项目的源代码很可能看起来是正确的 - 但实际上并非如此。

问题是这里需要的知识水平。您不仅需要非常熟悉（在这种情况下）C、汇编、特定的内核子系统以及与开发内核相关的所有内容，而且您还需要了解您的编译器在做什么。

不要误会我的意思，我同意 Linus 的观点，只要有足够的眼睛，所有的 bug 都是浅薄的。问题在于眼睛背后的大脑中的知识。如果你付钱给 30 位神童来开发你的产品，但你的开源项目只有 5 个人对代码库有真正的了解，那么很明显，假设复杂性相对相似，闭源版本的错误更少的可能性更大.

显然，正如 Thomas Pornin 所讨论的，这也适用于任何给定的随时间推移的项目。

更新已编辑以删除对 gcc 错误的引用，因为它不是。

我认为大多数用来区分封闭源代码和开源代码的前提是非常明确的。其中许多都列在这里，都有他们的拥护者。不出所料，封闭源代码的支持者是那些出售它的人。开源的支持者也把它变成了一个漂亮整洁的生意（除了少数人把它当作一种宗教。）

Pro Open Source 运动讲的是基础知识，当涉及到一般安全性时，这里是最适合讨论的要点：

1. 定制前提
2. 许可证管理前提
3. 开放格式前提
4. 多眼前提
5. 快速修复前提

因此，按前提打破这一点，我认为这里的其他人已经相当简洁地介绍了最后两个，所以我将不理会它们。

1. 定制前提
   当它适用于安全性时，定制前提使采用该软件的公司能够在现有平台上构建额外的安全控制，而无需获得许可证或说服供应商修复他们的某些东西。它使需要或看到差距的组织能够提高产品的整体安全性。SELinux 是一个完美的例子，你可以感谢 NSA 将其回馈给社区。
   

2. 许可证管理的前提
   经常有人提出，如果您使用 F/OSS 技术，则不需要与第三方管理技术许可证（或者如果您这样做，则更少。），完全开源也是如此生态系统。但是许多许可证（尤其是 GPL）对分销商提出了要求，并且大多数现实世界的环境都是封闭和开源技术的异构混合。因此，虽然它最终确实减少了软件支出，但源代码的可用性可能会导致一些公司在有义务发布源代码时将源代码保密，从而违反 OSS 许可证。这最终可以将许可管理前提变成一种责任（这是反对GPL 等许可的封闭源代码。）

3. 开放格式前提
   这是一个很大的前提，而且我倾向于同意，所以我会保持简短，以免讲道。30 年后，我希望能够打开我编写的文件。如果使用专有 DRM 控件“保护”该文件并且我需要访问它的软件不再出售，那么访问我自己的内容的难度就会大大增加。如果有一种用于创建我的文档的格式是开放的，并且在 30 年前的开源产品中可用，我很可能能够找到它并合法地使用它。一些公司正在跳上“开放格式”的潮流而没有跳上开源的潮流，所以我认为这个论点是一个非常合理的论点。

我没有列出第六个前提，因为它没有得到很好的讨论。我倾向于陷入困境（称之为妄想症。）我认为第六个前提是世界各地国防部门的羽毛。当 Windows 2000 的一部分源代码泄露时，它向全世界公布了。

封闭源代码责任前提
如果一家公司几十年来一直在通过多个版本生产封闭源代码库或 API，那么一小群个人在其整个生产过程中都可以访问该源代码。其中一些是第三方审计小组，以及已经转到其他公司/政府的开发人员。如果该代码是足够静态的，以保持兼容性作为一个封闭源代码的好处前提，那么一些弱点可能会在很多年内都没有公布。那些有权访问该封闭源代码的人可以自由地对其运行代码分析工具来研究这些弱点，这些软件开发商店的错误存储库中充满了可能导致漏洞利用的“小”错误。所有这些信息都可供许多内部人员使用。

攻击者知道这一点，并且他们自己想要这些信息。如果您是这些商店中的一员，这将对您公司的内部基础架构造成巨大的影响。就目前而言，您的开发过程成为安全责任。如果您的公司足够大，并且您的代码库分布得足够好，您甚至可以成为人类渗透工作的目标。在这一点上，查理米勒技术：用足够的钱贿赂开发人员，他会写给你一个无法检测到的错误成为一种明显的可能性。

这并不意味着它也不会以同样的方式进入 OSS 产品。这只是意味着您拥有一组数据，然后在发布时可能会暴露您的安装基础中的弱点。保持隐私对您的客户安装的系统产生了编码债务，您无法立即偿还。