01 总结
开源软件的安全问题理应受到业界的关注，但解决方案需要对挑战的共同理解和实施过程中的合作。 这个问题很复杂，涉及很多方面：供应链、依赖库管理、身份识别和构建管道。 如果问题能够准确定义，就能更快地找到解决方案； 因此，我们提出了一个关于业界应如何思考开源软件漏洞的框架（“了解、预防、修复”），列出了需要首先解决的具体问题，包括：
就元数据和身份标准达成一致。 我们需要就解决这个行业复杂问题的基本原理达成一致。 对元数据详细信息和识别达成共识将有助于实现手动化、减少更新软件所需的工作量并最大限度地减少漏洞的影响。
提高透明度并加强关键软件的代码审查。 对于安全关键型软件，我们需要就开发流程达成一致，以确保充分审查、防止单方面更改并透明地生成定义良好、可验证的即将发布的版本。
下面提出的框架和目标旨在引起整个行业对开源软件安全问题的澄清和进步。
由于最近的动荡，软件行业对供应链攻击的实际风险有了更深入的认识。 开源软件的安全风险相对较小，因为所有代码和依赖项都是可公开验证的。 通常情况下确实如此，但前提是人们确实进行了检查。 由于依赖项太多，监控所有依赖项是不切实际的，而且许多开源包没有得到很好的维护。
程序通常直接或间接依赖于数千个软件包和库。 例如，今天的 Kubernetes 依赖于大约 1000 个软件包。 与闭源软件相比，开源软件使用更多的依赖库，来自更广泛的供应商； 因此，需要信任相当多的不同实体。 这使得了解产品如何使用开源软件以及如何查找相关漏洞变得非常困难。 据悉，无法保证构建的程序与其源代码相匹配。
退一步来说，虽然供应链漏洞存在风险，但绝大多数漏洞都是普通且无意的——是善意的开发人员无意中犯下的错误。 据报道，恶意攻击者更倾向于使用已知的漏洞，而不是自己发现它们，原因很简单：因为这使攻击变得更容易。 因此，我们必须集中精力做出根本性改变，以解决大多数漏洞。 只有这样，整个行业才能深入解决这些复杂的问题（包括供应链漏洞）。
几乎没有任何组织可以验证他们使用的所有软件包，更不用说对这些软件包的更新了。 就目前而言，跟踪此类包裹需要大量基础设施和大量人力开销。 我们在 Google 拥有此资源，并且在管理我们使用的开源软件包方面做得很好，包括为我们内部使用的所有开源软件包维护一个私有存储库，但跟踪所有更新一直很困难。 更新的数量之多可能令人望而生畏。 所有解决方案的核心是更高程度的手动化，这将是我们 2021 年及以后开源安全工作的关键主题。
由于这是一个复杂的问题，需要行业合作，因此我们的目标是围绕具体目标展开对话。 Google 共同创立了 OpenSSF，并将其作为此次合作的重点。 为了更进一步，我们需要整个行业参与进来，并就问题所在以及如何解决问题达成共识。 首先，我们提出了一种解决此问题的方法，以及一系列我们希望能够加速全行业解决方案的具体目标。
我们建议将这一挑战定义为三个很大程度上独立的问题领域，每个领域都有特定的目标。
1. 注意软件中的漏洞
2.防止形成新的漏洞
3. 修复或消除漏洞
一个相关但独立的问题是提高开发过程的安全性，这对于保护供应链至关重要。 我们在第四节“关键软件计划”中概述了该问题的挑战并提出了目标。
02知道有漏洞
由于各种原因，了解现有漏洞比预期更加困难。 尽管存在漏洞报告机制，但很难确认特定版本的软件是否受到漏洞影响。
2.1 目标：获取准确的漏洞数据
首先，从所有可用数据源准确获取漏洞元数据至关重要。 例如，了解哪个版本引入了漏洞将有助于确定某个软件是否受到影响； 知道漏洞何时被修补，可以及时进行修补（并缩短潜在的漏洞窗口期）。 理想情况下，这些分类工作流程应手动完成。
其次，大多数漏洞存在于依赖库中，而不是存在于您直接创作或控制的代码中。 正因为如此，即使你的代码没有改变，漏洞也会不断出现，潮起潮落。
2.2 目标：构建漏洞数据库标准框架
需要改进基础设施和行业标准来跟踪和维护开源漏洞、了解漏洞的后果并管理缓解工作。 标准的漏洞框架将允许通用工具跨多个漏洞数据库工作并简化跟踪任务，特别是当漏洞涉及多种语言或子系统时。
2.3 目标：准确跟踪依赖关系
我们需要更好的工具来快速了解哪些软件受到新发现的漏洞的影响，而依赖树的巨大规模和动态性质使这个问题变得更加困难。 由于软件的版本只能通过安装程序来解析，如果不实际进行安装操作，目前很难准确预测所调用的软件的版本。
03 新漏洞防控
理想的情况是防止漏洞形成，虽然测试和分析工具有所帮助，但预防仍然是一个两难的选择。 在这里，我们重点关注两个具体方面。
1. 当决定采用新的依赖库时，您需要了解其中的风险。
2.改进安全关键软件的开发流程。
3.1 目标：了解新依赖库的风险
第一个方面主要是：当你决定使用一个软件包时，你需要了解它的漏洞。 接受新的依赖会带来固有的风险，因此需要做出明智的决定。 一旦使用了依赖库，随着时间的推移，它通常会变得越来越不可删除。 了解漏洞是一个好的开始，但我们可以走得更远。
理想情况下，如果没有进行显式更新，依赖库的版本应该是稳定的，但确切的行为因包装系统而异。 GoModules 和 NuGet 这两个打包系统的目标都是稳定性而不是快速升级，并且默认情况下它们仅在需求更新时安装升级； 依赖关系可能是错误的，但只有在显式更新时才能更改它们。
许多漏洞的产生是因为在软件开发过程中没有遵循安全最佳实践。 所有贡献者都使用双因素身份验证 (2FA) 吗？ 该项目是否已设置持续集成并正在运行测试？ 模糊测试是否集成？ 这些类型的安全检查将帮助用户了解新依赖项带来的风险。 需要仔细审查低“分”的软件包并制定风险缓解计划。
OpenSSF 最近宣布的“安全记分卡”项目尝试完全手动生成该数据。 使用记分卡还可以帮助防止拼写错误（名称看起来像流行软件包的恶意软件包）的流行，因为假冒的恶意软件包得分较低，但无法通过许多安全检查。
改进关键软件的开发流程不仅仅与漏洞预防有关，我们将在后续章节中进一步讨论。
04 修复或消除漏洞
传统意义上的漏洞修补问题超出了我们讨论的范围，但对于具体的软件依赖库漏洞管理问题，我们还需要做很多工作。 即使这在今天没有帮助，但随着我们提高准确性，有必要投资新的流程和工具。
事实上，一种选择是直接修补漏洞。 如果您可以以向后兼容的方式完成此操作，那么该补丁将适合您。 但挑战在于，您不太可能拥有有关此漏洞的专业知识，并且无法直接进行更改。 修补漏洞的前提是软件维护者意识到问题，但公开与漏洞相关的知识和资源。
相反，如果您只是删除包含该漏洞的依赖库，则该漏洞会为您以及导出或使用您的软件的人修补该漏洞，但不会为其他人修补。 这是直接在您控制之下的更改。
上述场景描述的是你的软件和漏洞位于依赖链的两端，但实际中可能还有很多其他相关的软件包。 您通常希望链条中的某个人可以修复它。 不幸的是，仅修补一个链接是不够的。 在您和错误之间的依赖链中的每个链接都已更新之前，您的软件不会得到修补。 每个链接必须引用其依赖链下方的包的修补版本，以消除漏洞。 因此，更新需要自下而上进行，除非您可以完全删除依赖项（这可能需要类似的英雄主义，并且几乎不可能发生 - 但在可能的情况下，这似乎是最好的解决方案）。
4.1 目标：了解消除漏洞的选项
今天，我们对这个过程仍然缺乏清晰的认识：其他人已经取得了哪些进展？ 应该在哪个级别应用升级程序？ 这个过程又卡在哪里了？ 谁负责修补漏洞本身？ 谁将负责传播修复程序？
4.2 目标：快速补丁通知
最终，您的依赖项将被修补，您可以在本地升级到新版本。 但了解这种情况何时发生很重要，因为它可以快速降低漏洞暴露的风险。 据悉，我们还需要一个漏洞发现通知系统； 一般来说，一个新的漏洞往往意味着发现了一个新的潜在问题，尽管实际代码没有改变（例如，Unix实用程序sudo漏洞已有10年历史）。 对于小型项目检测网站漏洞软件，这些问题大多出现在间接依赖的库中。 目前，我们还没有达到良好通知系统所需的精确度，因此，在我们提高错误级别和改进元数据（如上所述）的同时，我们还应该继续推进通知系统。
到目前为止，我们只描述了一个简单的情况：向后兼容升级链，这意味着除了错误被清理之外，行为没有什么不同。
但在实践中，升级往往不向后兼容，或者受到版本限制要求的限制。 此类问题意味着更新依赖树深处的包必然会导致依赖链下游出现一些混乱，或者至少会导致需求更新。 这些情况通常发生在最新版本（例如1.3版本）有更新程序，但您的软件或相关软件包需要引用1.2版本时。 这些情况都很常见，并且带来了重大挑战，而且让开源项目所有者更新相关软件包也很困难。 众所周知，如果您在数百个地方使用一个软件包（对于小型企业来说并不疯狂），那么您可能需要经历数百或数千次更新过程。
4.3 目标：补丁广泛使用的版本
修补旧版本中的漏洞同样重要，尤其是那些被大量使用的版本。 这些修补方法在这些年受支持的软件中很常见，但理想情况下，所有广泛使用的版本都应该修补，尤其是包含安全风险的版本。
手动方法可能会有所帮助：给定一个版本的补丁，我们实际上可以为其他版本手动生成良好的候选补丁。 目前，此过程有时是手动完成的，但如果大大简化该过程，我们将能够修补更多版本并减少依赖链上层的工作。
综上所述，我们需要更方便、更及时地修补漏洞，尤其是依赖库的漏洞。 除了是最新版本之外，广泛使用的版本还需要更多的机会被打补丁，因为最新版本通常包含其他更改，因此很难被采用。
最后，还有许多其他“修补”选项，包括各种缓解措施，例如防止调用特定方法，或通过沙箱或访问控制来限制风险。 这些都是重要且可行的选择，值得更多讨论和支持。
05关键软件防范措施
上述框架广泛适用于各种漏洞，无论恶意者是有意还是无意。 事实上，后者建议的目标涵盖了大多数漏洞，但仅靠这些还不足以防止恶意行为。 为了在防止恶意行为者（包括供应链攻击）方面做出真正的改变，我们需要改进开发流程。
这是一个艰巨的任务，但目前对于大多数开源项目来说是不切实际的。 开源的美妙之处在于，由于缺乏流程限制，它吸引了广泛的贡献者。 然而，这些灵活性可能会妨碍安全考虑。 我们需要贡献者，但我们不能指望每个人都同样关心安全。 相反，我们必须识别关键包并保护它们。 虽然可能会减少开发人员之间的摩擦，但此类关键包必须遵守一套更严格的开发标准。
5.1 目标：为满足更高标准的“关键”开源项目定义指标
识别被广泛依赖的“关键”软件包至关重要，这些软件包的泄露可能会损害关键基础设施或用户隐私。 因此，此类封装必须遵守更高的标准，我们在下面概述其中一些标准。
定义“关键”的标准尚不明确，并且定义的范围可能会随着时间的推移而扩大。 不仅包括 OpenSSL 或密钥加密库等显而易见的软件包，还包括一些广泛使用的软件包，其影响范围使其值得保护。 Google 启动了关键性评分项目（CriticalityScoreproject），与社区一起就这个问题集思广益，并与耶鲁大学合作主办了开源普查（OpenSourceCensus）。
5.2 目的：严禁对关键软件进行任何单方面的变更
我们在 Google 遵循的原则之一是变更不应是单方面的——也就是说，每项变更都至少涉及一名作者和一名第一审阅者/批准者。 目标是限制对手自己可以做的事情——我们需要确保有人真正检测到这种变化。 对于开源项目来说，做好这件事显然比在公司内部困难得多检测网站漏洞软件，公司内部有严格的身份验证，但会执行代码审查和其他检查。
防止单方面变革可以分为两个子目标。
1. 目标：要求对关键软件进行代码审查。
代码审查除了是改进代码的一种好方法之外，还应确保每项更改都被除作者之外的至少一个人检测到。 代码审查是 Google 内部所有变更的标准做法。
2. 目标：关键软件的变更需要两个独立方的批准。
为了真正实现“有人在检测”的目标，我们需要评审者独立于代码贡献者。 对于重大变更，我们可能需要不止一次独立审查。 事实上，我们需要梳理一下什么是“独立”审查，但对于大多数行业的审查来说，独立的理念非常重要。
5.3 目标：验证关键软件播放器
独立性的概念通常意味着您了解参与者 - 匿名参与者不能被视为独立或值得信赖。 直到今天，我们基本上都在使用别名：同一个人一遍又一遍地使用相同的身份来建立声誉，但我们不知道那个人是否值得信任。 这导致了一系列子目标。
1. 目标：对于关键软件，所有者和维护者不能是匿名的。
攻击者喜欢保持匿名。 在过去的供应链攻击中，攻击者利用匿名方式通过软件包社区成为维护者，而没有人意识到这个“新维护者”具有恶意（入侵代码最终被注入上游）。 为了减轻这些风险，我们认为关键软件的所有者和维护者一定不能匿名。
可以想象，与所有者和维护者不同，贡献者可以保持匿名，但前提是他们的代码已经经过可信人员的多次审查。
还可以想象，我们可以拥有一个“经过验证的”身份，即：受信任的实体知道他的真实身份，但公众出于隐私原因并不知道。 这将有助于有关独立性和起诉非法行为的决策。
2. 目标：为关键软件的贡献者提供严格的身份验证。
恶意攻击者寻找简单的攻击媒介，因此网络钓鱼攻击和其他形式的簿记欺诈很常见。 一个明显的改进是要求双因素身份验证，特别是对于所有者和维护者而言。
3. 目标：联合身份模型
为了继续对开源保持宽容，我们需要能够信任不同的身份，并且可验证的完整性仍然至关重要。 这意味着身份联合模型实际上类似于我们明天支持联合SSL证书的方式——多方可以生成有效的证书，但必须有严格的审核和相互监督。
OpenSSF 的数字身份工作组已经开始讨论这个主题。
5.4 目标：风险变更通知
我们应该扩大通知范围，将风险变化纳入其中。 最明显的是所有权的变更，这可能是新攻击的插曲（例如最近的 NPM 事件流攻击）。 其他反例包括检测图书盗窃、共谋或恶意行为者的其他行为。
5.5 目的：降低预制构件的透明度
安全散列通常用于衡量工件的完整性，而数字签名则用于证明真实性。 降低“透明度”意味着此类证据被公开记录，从而记录任何意图。 相反，外部各方可以监视日志中的假版本，尽管用户并不知道。 而且，当账本被盗后，我们可以知道账本是用什么预制件签名的，我们可以尝试将其删除。 这些透明度，包括持久的公共日志记录和第三方监控，已成功应用于 SSL 证书，并且我们为包管理器提出了类似的技术。 知道您正在使用正确的软件包或两个补充文件类似于知道您正在访问网站的真实版本。
5.6 目标：信任建立过程
1984年，肯·汤普森著名的图灵奖演讲证明，仅靠真实的源代码是不够的，最近发生的事件表明，创建过程也是一个真正的威胁。 如何确保您的构建系统值得信赖？ 其所有组件都必须通过持续的建立信任过程来获得信任和验证。
可重复的构建会有所帮助（具有确定性结果的构建，以便我们可以验证我们的构建是否正确），但这很难做到，因为临时数据（如时间戳）最终会出现在构建分布中。 而安全可重复的创建需要验证工具，验证工具必须通过可验证可重复的创建，所以推送。 我们必须打造一个值得信赖的工具网络并构建产品。
对预制件和工具的信任可以通过“委托”（上述透明过程的变体，称为补码委托）来建立。 在 Google 内部，构建系统对所有预制工件进行签名，并生成与源代码关联的清单。 对于开源项目，一个或多个受信任的代理可以将构建作为服务运行，签署预制件以证明他们对其完整性负责。 这些生态系统应该是存在的，大多数情况下你只需要意识到这一点并根据支持文档格式签署一些合同，我们就可以安全地手动自动化上述过程。
本节中描述的方法非常适合通用软件，现在在 Google 内部广泛使用，并且对于开源项目来说，它们的工作量要大得多。 我们希望通过专注于少数关键软件来实现这一目标，至少对于关键软件而言。 随着工具和手动化的改进，这一目标将得到更广泛的采用。
06 总结
开源的本质要求我们通过共识和协作来解决问题。 对于漏洞等复杂主题，这意味着将讨论集中在关键问题上。 我们提出了一种方法来构建这些讨论并定义一组目标，我们希望这些目标将加速整个行业的讨论并带来最终的解决方案。 第一组目标广泛适用于所有类型的漏洞，本质上是关于手动化、降低风险和努力工作。
原文链接：
