7.9 OWASP 软件组件验证标准

与 NIST 的安全软件开发框架（SSDF）等由政府组织创建的框架不同，OWASP 的软件组件验证标准（SCVS）是一项由社区推动的工作，重点关注软件供应链。它主要通过确定可在整个软件供应链生命周期中实施的相关活动、控制措施和最佳实践来降低软件供应链中的风险。OWASP 的SCVS 在 NIST SSDF 指南中也有引用，这将在第 8 章中讨论。SCVS 1.0版于 2020 年发布，由 Steve Springett 及其他几位贡献者和审核者领导。

SCVS 分成六个控制系列，每个系列包含多个控制，用于软件组件验证和流程的各个方面：

■ 库存
■ SBOM
■ 构建环境
■ 软件包管理
■ 成分分析
■ 来源和出处

SCVS 级别

与 SLSA 相似，SCVS 也使用级别，级别越高，与之相关的控制越多。SCVS有三个级别。1 级适用于低保证要求和基本控制。第 2 级适用于中度敏感软件和需要额外严格控制的情况。第 3 级适用于因数据敏感性或任务关键性而需要最高保证的环境。让我们深入了解一下这些级别，以了解与之相关的一些基本控制措施。

1 级

正如 SCVS 指南所述，1 级为所有后续级别和更高级别保证奠定了基础。与其他框架一样，第 1 级包括一些基本活动，其中最重要的是建立准确的清单。在软件领域，这越来越多地涉及创建 SBOM，以了解应用程序中涉及的软件组件。第 1 级还包括使用持续集成（CI）来实现可重复的构建。流行的 CI 平台包括 CircleCI、Jenkins、GitLab 和 GitHub 等。持续集成涉及开发人员将所有代码工作副本合并到共享的主仓库。CI既涉及技术，也涉及实践，如 CI 或构建服务，还涉及开发人员学习频繁集成代码变更的文化方面。最后，第 1 级要求利用公开可用的工具和情报对第三方组件进行分析。各种工具可以帮助分析和识别与第三方软件组件相关的公开披露漏洞，我们将在下面的章节中对此进行更深入的探讨。SCVS 还包括第 2 级和第 3 级，每一级都在基线第 1 级的基础上增加了额外的严格性或要求。

2 级

如 OWASP 所述，SCVS 的第 2 级主要针对软件密集型组织，这些组织在其环境中的风 险管理已达到一定的成熟度。第 2 级以第 1 级中确定的控制措施为基础，引入更多利益相关者和相关方，例如可能涉及合同和采购等领域的非技术专业人员。

3 级

第 3 级是 SCVS 中最严格的级别，重点关注整个软件供应链的可审计性和端到端透明度。这一级别通常只适用于监管最严格、最敏感的行业以及最成熟的组织。
OWASP 建议企业使用 SCVS 来逐步提高软件供应链的安全性。他们还建议组织定制 SCVS，以适应与使用该标准的组织最相关的安全性和合规性要求。这是一个独特的视角，它提倡灵活性，而不是其他安全标准和框架通常采用的统一基线。
说到这里，让我们来了解一下 SCVS 所定义的控制族和相关控制。

库存

正如 SANS 和随后的 CIS 关键安全控制框架等资料所引用的那样，拥有准确的库存长期以来一直是一项关键安全控制。尽管已被引用，但长期以来，这也是各组织努力应对的一项挑战，因此，将 "库存 "作为 SCVS标准中列出的首个控制系列也就不足为奇了。在 SCVS 的背景下，重点在于对创建软件过程中使用的所有组件进行清查，并提倡控制措施应覆盖单个应用程序、整个组织范围内的清查，以及提高与软件获取相关的软件透明度。SCVS 与更广泛地推动软件透明化一样，主张建立全组织范围的软件清单，其中包括第一方和第三方软件组件，包括开放源码软件代码。

清单系列中的第 1 级侧重于关键活动，如在构建时了解直接组件和传递组件，以及使用软件包管理器管理第三方二进制组件。第 1 级还包括以机器可读格式编制第三方组件的综合清单，并为公开和商业应用程序生成 SBOM。第 2 级在这些控制措施的基础上，还要求为新采购的软件提供 SBOM。这是一个控制措施的例子，它超越了网络从业人员，并开始让其他非技术利益相关者参与进来，如采购专业人员，他们可以开始要求将这些工件作为采购的一部分。

库存系列中的第 3 级开始增加更严格的控制措施，如持续维护所有系统的 SBOM 和了解整个库存的组件类型。第 3 级不仅要求了解组件类型，还要求了解组件的功能，更重要的是了解所有组件的来源。这通常被称为与软件供应链相关的出处。

软件物料清单

软件物料清单（SBOM）是 SCVS 框架中的一个关键组件和安全控制系列。SCVS 指出，拥有成熟开发实践的组织正在创建 SBOM，作为其构建流水线活动的一部分，并以机器可读的格式进行创建。SCVS 认识到有多种 SBOM 格式，如 CycloneDX 和 SPDX，企业需要与最适合其使用案例的格式保持一致，甚至可能需要一种以上的格式，以满足功能和合同要求等方面的需要，并能够与多样化的供应商生态系统合作。

SBOM 系列的第 1 级规定了一些基本控制措施，如提供结构化和机器可读的 SBOM、为 SBOM 分配唯一标识符以及使用时间戳等元数据。在这些控制措施的基础上，SCVS 要求为 SBOM 所描述的所有组件提供完整准确的 SBOM 清单，并分析 SBOM 中与组件相关的任何漏洞。最后，还要求确保组件标识符在可能的情况下来自本地生态系统，并为 SBOM中包含的组件提供准确的许可信息。

在第 1 级要求的基础上，SBOM 系列的第 2 级增加了一些控制措施，如不仅要由发布者、供应商或认证机构签署 SBOM，还要执行签名验证活动。第 2 级还要求 SBOM 具备应用程序所有测试组件的准确清单，以及SBOM 所描述的资产或软件的元数据。最后，还要求 SBOM 中定义的组件具有有效的 SPDX 许可证 ID 或表达式（如适用）。

第 3 级为 SBOM 系列活动增加了更多控制措施。其中包括以机器可读格式（如 PURL）标识组件的来源点，以及为 SBOM 中定义的软件组件提供有效的版权声明。此外，第 3 级还要求为 SBOM 中定义的组件提供详细的出处和血统信息，并为 SBOM 中定义的组件使用 SHA-256 等文件哈希值。

构建环境

SCVS 认识到现代构建环境的复杂性，包括源代码和软件包库、CI/CD流程、测试活动以及支持软件构建和交付的网络基础设施和服务。正如SCVS 所述，构建环境和管道中的每一个实体和活动都为恶意行为者提供了可能的攻击载体，也为传统故障和错误配置的发生提供了机会。其他框架（如 SLSA）或许最能说明这一点，它们说明了现代管道和构建流程中的各种攻击载体和潜在弱点。

构建环境控制系列是 SCVS 标准中最大的控制系列，与之相关的控制有 20 多项。第 1 级涉及基本控制措施，如拥有可重复的构建流程、与构建说明相关的文档以及使用 CI 管道。它还涉及一些控制措施，如确保应用程序构建管道只能从版本控制系统中的源代码执行构建，并确保在构建时对源代码和二进制文件进行已知和定义的更改。最后，第 1 级要求为每次构建记录所有第一和第三方软件组件的校验和。

构建环境控制的第 2 级开始增加一些活动，如构建管道不允许在执行构建的作业之外修改构建，或更改软件包管理设置，或在作业构建脚本的上下文之外执行代码。第 2 级还要求在构建管道上执行身份验证和授权以及默认拒绝设置。鉴于构建管道本身可能会因系统和软件过时而受到威胁，第 2 级要求为构建管道技术栈制定维护计划。最后，第 2 级要求对所有组件进行校验，并在打包或分发组件时进行带外交付。

第 3 级的最终要求包括要求在构建管道中修改系统设置时分清关注点/职责，以及保留所有系统变更和构建作业变更的可验证审计日志。此外，还要求监控编译器、版本控制系统 (VCS)、开发工具和软件开发工具包 (SDK)，以防篡改和恶意代码。控制措施要求确保未使用的直接和传递组件已被识别并从应用程序中移除，这有助于减少攻击面和最大限度地减少恶意行为者的潜在攻击载体。

软件包管理

SCVS 指出，现代开放源码软件组件通常会发布到特定于生态系统的软件包资源库中，如 Maven、.NET 和NPM。SCVS 指出，现代开放源码软件组件通常发布到生态系统特定的软件包库中，如 Maven、.NET 和 NPM。越来越多的组织被引导建立内部存储库，不仅包含第一方组件，还包含可信的第三方组件，NIST 800-161r1 和《美国国家安全局开发人员安全指南》等指南都建议采用这种方法。SCVS 指出，在构建过程中经常会调用软件包管理器，使用软件包管理器在业务和技术上有很多好处，但同时也要考虑到安全问题。

软件包管理系列的 1 级控制包括确保从软件包资源库检索二进制组件，并确保其内容与开放源码软件组件的权威来 源一致。软件包库还必须支持在更新这些组件时进行审计/记录，并在从远程软件包库或文件系统检索软件包时验证其完整性。软件包管理器还应为数据交换执行传输层安全（TLS）等加密措施，并确保 TLS 证书链经过验证，或在无法验证时安全失效。安全失效是指当 TLS 证书链无法验证时，系统会默认为安全状态，而不是允许进行中的功能和活动。软件包管理器也不得执行组件代码，软件包安装数据应以机器可读格式提供。

软件包管理系列中的第 2 级将控制措施从第 1 级提升到第 2 级，要求对软件包存储库进行强身份验证，包括使用 MFA。企业可能需要特别关注防网络钓鱼的 MFA (www.yubico.com/resources/glossary/phishing-resistant-mfa/?gclid=Cj0KCQjwj7CZBhDHARIsAPPWv3fXCG329UPlV7Oz3WZvIvcdHfJeDqo60tPOHaa9KsNcXZ2BZK5N_voaAvhqEALw_wcB)，因为最近发生的事件涉及 MFA 被泄露或滥用（www.malwarebytes.com/blog/news/2022/08/twilio-data-breach-turns-out-to-be-more-elaborate-than-suspected#:~:text=Earlier%20this%20month%20%2C%20messaging%20service,more%20elaborate%20than%20originally%20assumed）。除强身份验证外，第 2 级还要求确保软件包库支持进行安全事件报告和向发布者通报安全问题的能力。还有一些控制措施要求软件包资源库能够将组件版本与 VCS 中的源代码进行可验证的关联，并要求在将软件包发布到生产资源库时进行代码签名。

最后，软件包管理系列中的第 3 级增加了一些额外的控制。这些控制措施包括确保软件包存储库的组件已通过 MFA 和自动安全事件报告发布，包括通知用户安全问题。此外，还要求软件包存储库在发布组件之前执行SCA，然后将这些结果提供给软件组件消费者，并进行分析和保证。

成分分析

SCVS 的第五个控制系列是 "组件分析"，即识别使用开放源码软件和第三方组件（不仅包括直接组件，还包括传递组件）的潜在风险领域的过程。各组织需要了解与开放源码软件及其应用程序和系统中使用的第三方组件相关的任何固有风险。开放源码软件和第三方软件的使用非常普遍，绝大多数现代应用程序都由开放源码软件和第三方软件组件组成。企业必须了解他们正在使用的组件以及与这些组件相关的任何漏洞和风险。

为了了解漏洞，组织通常会参考 NIST 国家漏洞数据库 (NVD) 等来源来查找已知漏洞。除已知漏洞外，组织还应熟悉其他数据，包括组件版本货币、组件类型、功能和数量等术语。这意味着要了解组件是否过期或报废，是否可能存在漏洞，还要了解组件类型及其升级和风险的相关影响。各组织应了解组件的功能，以识别重复组件，并只使用质量较高的组件，从而将风险降至最低。企业还应该了解其库存中的组件数量，因为管理组件蔓延变得越来越困难。最后，企业必须了解与正在使用的组件相关的许可证类型，因为可能存在会带来业务风险的分配要求、限制和冲突。

组件分析系列第 1 级涉及的活动包括能够使用衬砌器和静态分析对组件进行分析。重点是自动化活动，如识别与组件相关的公开披露漏洞，识别使用中的非指定组件版本或过时组件。各组织还必须有自动流程来识别使用中的组件数量和与组件相关的许可。

第 2 级在此基础上更进一步，确保组件通过内衬和静态分析（包括组件的每次升级）进行分析，并自动识别使用中的组件类型。

第 3 级的主要区别在于自动识别已确认的可利用性、组件的使用寿命/支持以及组件功能。

来源和出处

最后一个控制系列是 "来源和出处"，这一点至关重要，因为如果不了解所消费软件的质量、来源和交付过程中的监管链，就很难信任或了解与软件消费相关的风险。

在 "来源与出处 "系列中，第 1 级涉及记录修改组件的出处，并以与未修改组件相同的严格程度分析修改组件。此外，还包括控制措施，以确保组织了解修改过的组件及其相关变体所独有的风险。

在第 1 级的基础上，第 2 级增加了控制措施，以确保组织记录了可验证的组件修改血统，并对修改后的组件进行唯一标识。

第 3 级的唯一控制措施是建立一个可对源代码和二进制组件进行审计的监管链。

开放源代码政策

虽然该指南不是 SCVS 中的正式控制系列，但它为组织更广泛地使用开放源码软件提出了建议。虽然开放源码软件的使用非常普遍，并涉及到组织生产和消费的许多现代应用程序，但许多组织在管理其消费和使用方面的安全成熟度很低。

SCVS 建议企业制定开放源码软件政策，并由跨职能利益相关者支持和执行。这些政策应涵盖与开放源码软件相关的重要考虑因素，如了解所使用组件的使用年限、设定使用旧的主要或次要修订版的要求，以及不断更新组件的自动化功能。各组织还应制定排除已知存在漏洞的组件的指导原则，或至少对可接受的风险水平做出规定。有风险的组件应有 明确的 MTTR 标准，并因其固有风险而限制使用报废组件。有些组织甚至可能会因为漏洞、国家安全问题或其他因素而制定一份禁止使用的组件清单。

如前所述，虽然开放源码软件的使用非常普遍，但许多组织并没有花时间将其对开放源码软件的立场编入正式的政策和指南中。我们已经开始看到一些组织率先垂范，超越了政策的范畴，建立了开放源码项目办公室（OSPOs）（www.linuxfoundation.org/resources/open-source-guides/creating-an-open-source-program），帮助管理和推动组织在其生产的软件中使用开放源码软件，以及开放源码软件的消费者。