开源中的产品 vs. 项目

开源是一件好事。开源对于安全性来说尤其是一件好事。 我之前已经写过关于这个的文章（特别是在不相信多眼假设 和 开源共同体 中），我将继续撰写相关文章。 然而，在本文中，我想更多地谈谈开源的一个特性，这个特性可以说既是可能的缺点也是优点：项目和产品之间的区别。 我将坚定地站在一边（剧透：对于组织来说，是“产品”），但我想先做一个小小的免责声明。 我受雇于红帽公司，我们是一家通过支持开源来赚钱的公司。 我相信这是一件好事，我赞同我们使用的模式，但我希望在文章开头就标明任何潜在的偏见。

开源有利于安全性的主要原因是，当出现问题时，你可以看到发生了什么，并且有机会修复它。 或者，更现实地说，除非你是具有特定开源项目专业知识的安全专业人员，否则其他人有机会修复它。 我们希望有足够多的具有所需专业知识的安全人员来修复我们关心的软件项目中的安全问题和漏洞。

然而，这比那复杂一点。 作为一个组织，有两种主要方式可以使用开源

• 作为项目： 你获取代码，选择要使用的版本，自己编译，测试，然后管理它。
• 作为产品： 供应商获取项目，选择要打包的版本，编译它，测试它，然后销售该软件包的支持，通常包括文档、补丁和更新。

现在，不可否认的是，以“原始”方式使用项目可以为你提供更多选择。 你可以跟踪最新版本，随时编译和测试，并且可以比产品版本更快地获取安全补丁，选择那些最适合你的业务和用例的补丁。 总的来说，这似乎是一件好事。 然而，也存在一些特定于安全性的缺点。 这些包括

1. 一些安全修复程序带有 禁运，只有少数组织（通常是供应商）可以访问。 虽然你可能与更广泛的生态系统同时获得修复程序，但你需要检查和测试它们（除非你盲目应用它们——不要这样做），供应商已经执行过这些操作。
2. 做出不一定或立即进入上游项目的代码更改的巨大诱惑意味着你很可能正在运行代码的一个分支。 即使你确实设法及时将这些代码提交到上游，但在你运行这些更改但它们不在上游的这段时间内，你面临的主要风险是任何安全补丁都不会立即适用于你的版本。（当然，对于非安全补丁也是如此，但安全补丁通常更紧急。）当然，如果你认为你的版本很可能被其他人使用，那么一个选择是创建一个项目的官方分支，并尝试鼓励一个社区围绕它发展；但最终，你仍然需要决定是内部还是外部支持新版本。
3. 除非你确保软件的所有实例都在你的部署中运行相同的版本，否则将安全修复程序向后移植到旧版本将需要你投入与最初创建修复程序的人员相等（或接近相等）的安全专业知识。 在这种情况下，你放弃了开源的“共同体”优势，因为你需要支付专家来复制社区的技能。

基本上，你通过选择部署项目而不是产品，是在决定对项目进行内部产品化。 你不仅失去了安全修复的共同体优势，还失去了供应商支持的产品模式所固有的显著规模经济。 你还可能错过范围经济：许多供应商将拥有他们支持的多个产品，并且能够以你的核心重点不是产品支持的组织可能无法做到的方式跨这些产品应用安全专业知识。

这些经济体反映在使用供应商的共同体的另一个潜在好处：多个客户正在使用他们的产品这一事实意味着供应商有动力和收入来源来花费在安全修复和一般功能上。 他们可能会应用资源的其他类型的修复和改进，但熟练安全专家的相对稀缺意味着比较优势原则表明他们应该处于为更广泛的社区应用它们的最佳位置。¹

如果你使用的提供开源项目产品化版本的供应商倒闭或决定停止支持该产品怎么办？ 嗯，当然，这在专有软件的世界中也是一个问题。 但在专有软件的情况下，可能出现三种结果

• 你现在无法访问软件源代码，因此无法进行改进。
• 你可以访问软件源代码，但它不适用于更广泛的世界，因此你只能靠自己。
• 每个人都可以访问软件源代码，但不存在改进它的现有社区，它要么消亡，要么需要大量时间才能建立一个围绕它的社区。

然而，在开源的情况下，如果你选择的供应商倒闭了，你始终可以选择使用另一个供应商，鼓励新供应商接手，自己产品化（并将其提供给其他组织），或者，如果最坏的情况发生，在寻找可扩展的长期解决方案时，采取内部产品化路线。

在现代开源世界中，我们（社区）非常擅长管理这些选项，正如开源联盟²的增长所表明的那样。 在联盟中，组织和个人群体聚集在一个软件项目或一组相关项目周围，以鼓励社区发展，围绕特性和功能添加保持一致，进行一般安全工作，以及为可能尚未明确定义的用例进行产品化，同时努力利用上述规模经济和范围经济。 其中一个例子是Linux基金会的机密计算联盟，Enarx 项目旨在为此做出贡献。

选择将开源软件作为产品而不是项目使用涉及一些权衡，但至少从安全的角度来看，组织的经济效益非常明确：除非你有能力雇用大量的安全专家，否则产品最有可能满足你的需求。

1. 注意：我不是经济学家，但我认为在这种情况下这是成立的。 很高兴听到评论解释我为什么是错的（如果我是的话……）。

2. 如果你真的必须的话，就用 "Consortiums" 。

本文最初发表在Alice, Eve, and Bob上，经作者许可转载。