一、摘要
开源软件的安全自然引起了业界的关注，但解决方案需要就实施过程中的挑战和合作达成共识。这个问题非常复杂，涉及供应链、依赖库管理、身份识别和流水线建设(build pipelines)。如果能准确定义问题，就能更快地得到解决方案；为此，我们提出了一个框架("了解、预防、修复")，该框架是关于如何考虑开源软件在行业中的漏洞，并列出了需要首先解决的具体问题，包括：
- 就元数据和身份识别标准达成共识。我们需要在基本面上达成一致来解决这些行业复杂问题。就元数据细节和身份识别达成的共识将有助于实现自动化，减少更新软件所需的工作量，并将漏洞的影响最小化。
- 提高关键软件的透明度，加强代码审查。对于安全关键软件，我们需要就开发过程达成协议，确保充分审查，避免单方面变更，并透明、公开地生成定义明确、可验证的正式版本。
以下框架和目标旨在引导全行业探讨开源软件的安全问题，寻求进步。
由于最近的事件，软件行业对供应链攻击的实际风险有了更深入的了解。由于所有代码和依赖关系都可以公开检查，开源软件的安全风险相对较小。一般来说，这是真的，但前提是人们真的在检查。由于许多依赖性，监控所有这些依赖性是不现实的，许多开源包没有得到很好的维护。
程序通常直接或间接地依赖于数千个软件包和库。Kubernetes现在我们依赖大约1000个软件包。与闭源软件相比，开源软件使用的依赖库更多，供应商来源更广；因此，我们需要信任相当多的不同实体。这使得了解产品如何使用开源软件以及如何发现相关漏洞极其困难。此外，没有办法确保构建的程序与源代码匹配。
退一步，虽然供应链攻击是一种风险，但绝大多数漏洞都是普通和无意的--善意的开发者犯了无意的错误。此外，恶意攻击者更倾向于使用已知的漏洞，而不是亲自发现漏洞：因为这使得攻击更容易。因此，我们必须专注于做出根本性的改变来解决大多数漏洞。只有这样，整个行业才能深入解决这些复杂的问题（包括供应链攻击）。
很少有组织能验证他们使用的所有程序包，更不用说更新了。目前，跟踪这些软件包需要大量的基础设施和显著的劳动力成本。Google拥有这些资源，不遗余力地管理我们使用的开源包--包括维护我们内部使用的所有开源包的私人仓库--但仍然很难跟踪所有的更新。巨大的更新流令人生畏。所有解决方案的核心部分都是更高程度的自动化，这将是2021年及以后开源安全工作的关键主题。
因为这是一个需要行业合作的复杂问题，我们的目标是围绕具体目标进行对话。Google联合创立了OpenSSF并将其作为合作的重点。但为了更进一步，我们需要参与整个行业，并就如何解决问题达成共识。从一开始，我们就解决这个问题提出了一种 *** 和一系列具体的目标，希望这些目标能加速整个行业的解决方案。
我们建议将这一挑战定义为三个基本独立的问题领域，每个领域都有具体的目标。
- 了解软件中的漏洞
- 防止新漏洞的产生
- 修复或消除漏洞
另一个相关但独立的问题是提高开发过程的安全性，这对确保供应链的安全至关重要。我们将在第四节"预防关键软件"总结问题所面临的挑战并提出目标。
二、知道已有漏洞
由于各种原因，知道现有的漏洞比预期的要困难得多。虽然存在漏洞报告机制，但很难确定软件的特定版本是否受到漏洞的影响。
1. 目标：获取准确的漏洞数据
首先，准确地从所有可用的数据源中获取漏洞元数据是非常重要的。例如，知道哪个版本引入了漏洞将有助于判断软件是否受到影响；知道什么时候修复漏洞可以准确和及时地修复（并减少潜在的漏洞使用窗口期）。理想情况下，应自动完成此转移工作流程。
其次，大多数漏洞都存在于依赖库中，而不是在你直接编写或控制的代码中。因此，即使你的代码没有改动，漏洞也会不断地出现，此消彼长。
2. 目标：建立漏洞数据库的标准架构
需要建立基础设施和行业标准来跟踪和维护开源漏洞，了解漏洞的后果，并管理缓解措施。特别是当漏洞涉及多种语言或子系统时，标准的漏洞架构将允许通用工具跨越多个漏洞数据库并简化跟踪任务。
3. 目标：准确跟踪依赖关系
我们需要更好的工具来快速了解哪些软件受到新发现漏洞的影响，而依靠树木的巨大规模和动态特性使这个问题更加困难。由于软件版本只能通过安装程序进行分析，因此很难准确预测被调用的软件版本。
三、防止新漏洞
理想的做法是防止漏洞的产生。虽然测试和分析工具有帮助，但预防始终是一个难题。在这里，我们将重点讨论两个具体方面。
- 在决定使用新的依赖库时，需要了解风险。
- 改进安全关键软件(security-critical software)开发过程。
1. 目标：了解新依赖库的风险
之一个方面主要是：当你决定使用一个软件包时，你需要知道它的漏洞。接受一个新的依赖库会带来固有的风险，你需要做出明智的决定。一旦使用了依赖库，随着时间的推移，它通常会变得越来越难以移除。理解漏洞是一个很好的开始，但我们可以更进一步。
理想情况下，如果没有显式更新，依赖库的版本应该是稳定的，但具体行为因包装系统而异。Go Modules和NuGet这两个包装系统都以稳定为目标，不追求快速升级。默认情况下，只有在需求项更新时才会安装升级程序；依赖可能是错误的，但只有在显式更新时才会修改。
许多漏洞是由于在软件开发过程中没有遵守更佳的安全实践造成的。所有贡献者都使用双因素认证吗？(2FA)?项目是否设置了连续集成和运行测试？模糊测试是否集成？这些类型的安全检查将帮助用户了解新依赖库的风险。"得分"较低的软件包需要仔细审查，并制定风险缓解计划。
OpenSSF最近公布的“安全记分卡”(Security Scorecards)该项目试图自动生成这些数据。使用记分卡还可以帮助抵抗猖獗的假名(Typosquatting)攻击(恶意软件包采用与流行软件包相似的名称)，因为仿冒的恶意软件包得分会很低，并且无法通过很多安全检查。
关键软件开发过程的改进不仅与漏洞预防有关，还将在后续章节中进一步讨论。
四、修复或消除漏洞
传统意义上的漏洞修复问题超出了我们的讨论范围，但我们仍然需要做很多管理软件依赖数据库中的漏洞。虽然现在没有帮助，但有必要投资于新的过程和工具，以提高准确性。
当然，一个选择是直接修复漏洞。如果您能以后兼容的方式完成修复，则可以使用修复程序。但挑战是你不太可能有专业知识，也不能直接修改。修复漏洞的前提是软件维护人员意识到问题，并披露与漏洞相关的知识和资源。
相反，如果你只是简单地删除了包含漏洞的依赖数据库，那么你和那些导入或使用你的软件的人已经修复了漏洞，但没有其他人。这是一个可以由你直接控制的变化。
以上场景描述了您的软件和漏洞位于依赖链的两端，但在实践中可能还有许多其他相关的软件包。我们通常希望依靠链上的某人来修复它。不幸的是，仅仅修复一个链接还远远不够。只有在更新了您和漏洞之间依赖链中的每个链接后，您的软件才能被修复。每个链接都必须引用其依赖链以下软件包的修复版本来消除漏洞。因此，更新需要自下而上进行，除非你能完全消除依赖（这可能需要类似的英雄勇气，而且几乎不可能——但在可能的情况下，这实际上是更好的解决方案)。
1. 目标：了解消除漏洞的可选方案
今天，我们对这个过程仍然缺乏清晰的认识：其他人取得了什么进展？应该在哪个层面应用哪个升级程序？这个过程卡在哪里？谁负责修复漏洞本身？谁负责传播和修复程序？
2.目标：快速修复通知
最后，您的依赖库漏洞将被修复，您可以在本地升级到新版本。但重要的是要找出什么时候会发生，因为它可以迅速降低漏洞暴露的风险。此外，我们还需要一个漏洞发现通知系统；一般来说，新的漏洞通常意味着新的潜在问题，即使实际代码没有改变（例如Unix实用程序sudo漏洞已有10年的历史）。对于大型项目，这些问题大多出现在间接依赖库中。目前，我们仍然缺乏通知系统所需的准确性。因此，在提高漏洞准确性和元数据（如上述）的同时，也应促进通知系统的进步。
到目前为止，我们只描述了一个简单的情况：一系列的向后兼容升级，这意味着除了消除漏洞外，行为没有区别。
但事实上，升级往往不兼容，或受到版本限制要求的阻碍。这些问题意味着更新依赖树深处的软件包必然会在依赖链的上层造成一些混乱，或者至少导致需求更新。这通常发生在最新版本（例如1.3版本)有更新程序，但需要引用您的软件或相关包1.2版本。这种情况很常见，成为一个重大挑战，因为很难让开源项目的所有者更新相关的包。此外，如果你在数百个地方使用软件包（这对大公司来说并不疯狂），你可能需要经历数百个更新过程。
3. 目标：修复广泛使用的版本
修复旧版本中的漏洞也很重要，尤其是那些经常使用的版本。这种修复 *** 在长期支持的软件中很常见，但在理想情况下，应修复所有广泛使用的版本，特别是包含安全风险的版本。
自动化 *** 可能有帮助：给出一个版本的修复代码，也许我们可以自动为其他版本生成一个良好的替代修复代码。这个过程有时是手工完成的，但如果这个过程大大简化，我们可以修复更多的版本，减少更高层次的依赖链。
综上所述，我们需要更方便、更及时地修复漏洞，特别是依赖于图书馆中的漏洞。不仅是最新版本，而且广泛使用的版本也需要更多的修复机会，因为最新版本通常包含其他变化，所以很难使用。
最后，在"修复"还有许多其他的选择，包括各种缓解措施，如避免使用特定的 *** ，或通过沙箱或访问控制来限制风险。这些都是重要和可行的替代方案，应该得到更多的讨论和支持。
五、关键软件的预防措施
上述框架广泛应用于各种漏洞，无论是恶意攻击者故意造成的，还是只是无意中的错误。虽然上述建议的目标涵盖了大多数漏洞，但仅仅依靠这些并不足以防止恶意行为。为了实质性地改变恶意攻击者（包括供应链攻击），我们需要改进开发过程。
这是一项艰巨的任务，对大多数开源项目来说是不现实的。从某种意义上说，开源之美吸引了广泛的贡献者，因为缺乏过程约束。然而，这种灵活性阻碍了安全考虑。我们需要贡献者，但我们不能希望每个人都关注安全。相反，我们必须确定并保护关键软件包。虽然开发人员之间的摩擦可能会增加，但这些关键包必须遵循一系列更严格的开发标准。
1. 目标：定义符合更高标准的目标“关键”开源项目评价标准
确定广泛依赖"关键"软件包非常重要。如果失败，将危及关键基础设施或用户隐私。因此，这些软件包必须遵循更高的标准，我们在下面总结了一些标准。
如何定义"关键"标准不明确，定义范围可能会随着时间的推移而扩大。除了明显的软件，比如OpenSSL或者密钥加密库，还有一些广泛使用的软件包，覆盖面广，值得保护。Google关键得分项目启动(Criticality Score project)，与社区合作开展开源普查(Open Source Census)工作。
2. 目标:禁止单方面更改关键软件
我们在Google一个原则是变化不应该是单方面的--也就是说，每一个变化至少涉及一个作者和一个审查员/批准者。目标是限制对手自己能做的事情--我们需要确保有人真的在检查这些变化。对于开源项目来说，做好这一点比在公司内部要困难得多，因为公司有严格的身份认证，并将进行代码审查和其他检查。
避免单方面变更可以分为两个子目标。
(1) 目标:需要代码审查关键软件。
代码审查不仅是改进代码的好 *** ，而且确保至少有一个人在检查除作者以外的每一个变化。代码审查是Google所有内部变更的标准做法。
(2) 目标:两个独立方需要批准关键软件的变更。
真正实现"有人在检查"我们需要审查员独立于代码贡献者。对于重大变化，我们可能需要不止一次独立审查。当然，我们需要弄清楚什么是"独立"但对于大多数行业的审查来说，独立思想是非常重要的。
3. 目标:认证关键软件参与者的身份
独立的概念通常意味着你理解参与者——匿名参与者不能被视为独立或值得信赖。今天，我们基本上使用化名：同一个人反复使用相同的身份来积累声誉，但我们不知道这个人是否可信。这导致了一系列的子目标。
(1) 目标:所有者和维护者不能匿名使用关键软件。
攻击者喜欢匿名。在过去的供应链攻击中，攻击者试图通过软件包成为维护者，而没有人意识到这一点"新的维护者"具有恶意企图(入侵代码最终被注入上游)。为了减轻这种风险，我们认为关键软件的所有者和维护者一定不能匿名。
贡献者可以匿名，不同于所有者和维护者，但前提是他们的代码已经通过了可信人士的多次审查。
也可以想象，我们可以拥有它"已验证"也就是说，有一个可信的实体知道他的真实身份，但由于隐私，公众不知道。这将有助于独立决策和起诉非法行为。
(2) 目标:为关键软件的贡献者提供严格的身份认证。
恶意攻击者会找到容易的攻击载体，所以 *** 钓鱼攻击和其他形式的凭证盗窃是很常见的。一个明显的改进措施是使用双因子认证，特别是对所有者和维护者。
(3) 目标:身份联合模型
为了继续保持开源的包容性，我们需要能够信任各种身份，但可验证的完整性仍然是必不可少的。这意味着身份的联合模型可能类似于我们今天的支持SSL证书的方式——多个团体可以生成有效的证书，但必须有严格的审计和相互监督。
OpenSSF数字身份认证工作组已经开始讨论这个话题。
(4) 目标:风险变化通知
为了涵盖风险的变化，我们应该扩大通知的范围。最明显的是所有权的变化，这可能是新攻击的前奏(比如最近NPM事件流(NPM event-stream)失落)。其他例子包括被盗、串通或其他恶意行为者的行为。
(5) 目标:增加构件的透明度
通常使用安全散列来检测构件(artifact)使用数字签名来证明真实性是否完好无损。"透明度"这意味着这些证书将被公开记录，以便文档所有的意图。另一方面，即使用户不知道，外部各方也可以监控日志中是否存在伪造版本。此外，当凭证被盗时，我们可以知道这些凭证被用来签署哪些部件，并试图删除它们。这种透明度，包括持久的公共日志和第三方监控，已成功应用于SSL我们还为包管理器提出了类似的证书 *** 。知道你使用了正确的软件包或二进制文件，类似于知道你正在访问一个网站的真实版本。
(6) 目标：信任构建过程
1984年，肯-汤普森著名的图灵奖演讲证明，仅仅依靠真实可信的源代码是不够的。最近的事件表明，构建过程攻击也是一个真正的威胁。如何确认您的构建系统是可信的？它的所有组件都必须可信，并通过不断建立信任的过程进行验证。
可重复构建(Reproducible builds)它将有助于（构建具有确定的结果，因此我们可以验证我们的构建是正确的），但由于临时数据（如时间戳）最终会出现在构建的发行版本中，因此难以实现。安全可重复的构建需要验证工具，验证工具必须经过验证和可重复的构建，以此类推。我们必须建立一个可信的工具和产品构建 *** 。
通过信任工具的信任可以通过"委托"(以上透明过程的变体称为二进制授权)建立。Google在内部，构建系统将签署所有组件，并生成与源代码相关的列表。对于开源项目，一个或多个值得信赖的 *** 可以将构建作为一种服务运行，并签署组件以证明其完整性。这种生态系统应该存在，在大多数情况下，我们只需要意识到这一点，并签署一些协议，我们就可以安全地自动化上述过程。
本节所述的措施非常适合一般软件，目前正在进行中Google它在内部得到了广泛的应用，但对于开源项目来说，它们的工作量要大得多。我们希望至少通过关注一些关键软件来实现这些目标。随着工具和自动化程度的提高，这些目标将更容易被广泛使用。
六、总结
开源的本质要求我们通过共识和合作来解决问题。对于漏洞和其他复杂的主题，这意味着关注关键问题。我们提出了一个框架 *** ，并定义了一系列的目标，我们希望这些目标能加快对整个行业的讨论，并得到最终的解决方案。之一组目标广泛应用于各种漏洞，其本质是实现自动化，降低风险和努力工作。
原文链接：
https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.htm