如今，开源软件无处不在，这固然很好，但您如何确定应该信任下载的软件来完成您想要做的事情？软件供应链管理领域（本文讨论是其中的一部分）在行业中还相当新，但其重要性正在日益增长。我将考虑一个具体的例子。
不过，首先，这不像那些警匪剧，嫌疑包裹被送到警局，有人及时意识到这可能是一枚炸弹。我在这里谈论的是开源软件包（尽管如果您不够警惕，它对您的应用程序的影响可能类似）。关于信任意味着什么，作为一个起点，有很多话要说（我有一本关于计算和云中的信任的新书，由Wiley出版）。
就本文而言，假设您需要一个提供某种加密协议实现的库。您需要了解什么，以及您的选择是什么？现在，我假设您已经做出了几乎可以肯定是正确的选择，并选择了开源实现（请参阅我的许多先前文章，了解为什么开源是安全性的最佳选择），并且您不想一直从源代码构建所有内容。您需要一些稳定且维护良好的东西。您应该从哪里获取新软件包？
选项 1 – 使用供应商
有很多供应商通过各种机制（通常是订阅）提供开源软件。Red Hat，我的雇主（请参阅我的博客上的标准披露），就是其中之一。在这种情况下，供应商通常会为特定软件包的适用性提供支持，提供补丁等。在许多情况下，这是您最简单也是最佳的选择。但是，有时您可能想使用供应商未提供的软件包，或者您的首选供应商未打包的软件包。那么您该怎么办？同样，供应商需要做出哪些关于如何信任软件包的决策？
选项 2 – 深入挖掘
事情开始变得复杂了。事实上，非常复杂，以至于我将在我的书中详细考察它们。不过，在本文中，我将尽量简明扼要。我将从假设软件包只有一个维护者和多个贡献者开始。贡献者向项目提供代码（以及测试和文档等），维护者提供构建版本——二进制文件/库——供您使用，而不是您获取源代码并自行编译（这实际上是供应商可能做的事情，尽管他们仍然需要考虑以下大多数要点）。这个库提供加密功能，因此可以相当肯定地假设您关心它的安全性。您需要详细考虑至少五个特定领域，所有这些领域都在很大程度上依赖于维护者。（我在这里使用了安全性的例子，尽管对于几乎任何软件包，都存在非常相似的考虑因素。）看看这些问题。
- 构建： 您正在使用的软件包是如何创建的？构建过程是否在具有适当编译器和库的“干净”（即未被破坏）的机器上执行？（这里有一个乌龟问题！）如果二进制文件是用不受信任的工具创建的，那么您如何完全信任它，并且维护者采取了哪些措施来确保构建环境的“清洁度”？如果构建过程被记录为可重复构建，那就太好了，这样想检查它的人就可以这样做。
- 完整性： 这与构建有关，因为您要确保构建过程的源代码输入——例如，来自 Git 存储库的代码——是您所期望的。如果以某种方式将受损代码注入到构建过程中，那么您将处于非常糟糕的境地。您想确切地知道正在使用的源代码版本作为您正在使用的软件包的基础，以便您可以跟踪功能和错误。如上所述，拥有可重复构建在这里是一个巨大的优势。
- 响应性： 这是衡量维护者对更改的响应速度——或不响应速度。通常，您希望稳定的功能与已知的版本相关联，但对错误和（特别是）安全补丁的快速响应。如果维护者没有及时接受补丁，您就需要担心软件包的安全性。您还应该问诸如“是否存在明确定义的漏洞披露管理流程？”之类的问题（请参阅我的文章“安全披露还是漏洞管理？”）。如果是，那么“它是否被遵守”？
- 出处： 并非所有代码都是相同的，维护者应该跟踪的事情之一是贡献者的出处。如果一个身份不明的贡献者，使用一个匿名的电子邮件地址，并且没有安全功能贡献的历史，突然在一个软件包的提供特别敏感功能的部分提交了大量代码，这应该引起警觉。另一方面，如果一个由一家具有开源贡献历史和经过良好审查的代码的公司雇用的一组贡献者提交了一个大型补丁，这可能就不那么麻烦了。这是一个难以管理的问题，通常没有明确的“确定”或“禁止”的迹象，但维护者对贡献者及其贡献的意识和管理是一个重要的考虑点。
- 专业知识： 这是最棘手的。您可能有一个维护者，他在管理上述所有要点方面都很出色，但在贡献代码的功能的某些方面只是不是专家。但是，作为软件包的使用者，我需要确保它适合用途，这可能包括（在本文考虑的安全相关软件包的情况下）确保使用了正确的加密原语，在字节流上强制执行边界检查，使用了正确的密钥长度，或者为特定原语提供了恒定时间实现。这非常困难，如果维护者充当大型和/或复杂项目的专家，那么维护者的工作很容易变成全职工作。实际上，在这种情况下，最佳实践是拥有一支由受信任的、经验丰富的专家组成的团队，他们作为共同维护者或项目的高级顾问组工作。或者，让外部人员或组织（例如行业机构）在关键时刻对项目进行审计——例如，当主要版本即将发布或重要漏洞被修补时——允许维护者分担这种责任。重要的是要注意，项目不会仅仅因为它是开源的而神奇地变得“安全”（请参阅“不相信人多力量大假设”），但是当社区聚集在一起时，可以显着提高项目的使用者对其生产的软件包的信心。
一旦您考虑了这些领域，您就需要弄清楚如何衡量和跟踪每个领域。谁有资格判断任何特定维护者在多大程度上履行了每个领域？您能在多大程度上信任他们？这些都是复杂的问题，还有很多需要写，但我热衷于揭示对计算，特别是开源计算的明确信任的重要性。围绕开源供应链管理正在进行一些工作——例如，新的Project Rekor——但仍有许多工作要做。
但请记住：当您获取一个软件包时——无论是库还是可执行文件——请考虑您正在使用什么，您可以信任它的哪些方面，以及这种信任基于什么保证。
本文最初发表于 Alice, Eve, and Bob，经作者许可转载。
评论已关闭。