第七章 现有和新兴商业指南

随着围绕软件供应链安全的对话日趋成熟，许多组织已开始为行业提供强大的指导、框架和资源，以加强其针对此类攻击的安全态势。在接下来的章节中，我们将讨论其中一些资源以及提供这些资源的组织，其中包括云原生计算基金会 （CNCF）、国家安全局 （NSA） 和美国国家标准与技术研究院 （NIST） 等

7.1 软件制品的供应链等级

  随着软件供应链攻击的增加，很明显，需要一个全面的端到端框架来定义软件供应链袭击和缓解方法。2021年6月，谷歌开源安全团队推出了软件工件（SLSA）工作该工作的目标是确保软件工件的完整性在整个软件供应链生命周期中得到维护。
  SLSA包括四个级别，每个级别都提供更高级别的完整性保证，但实施者的成熟度和严格性水平相一致。组织根据其特定的行业和监管或安全要求，有各种需求来指导其追求的SLSA级别。 与其他安全工作一样，SLSA是一个需要时间和精力才能实现的过程。图7.1显示了四个级别，并对每个级别进行了描述。
  SLSA提供了一个框架，涵盖了从原始开发者到下游消费者和用户的整个软件路径，包括软件与源代码存储库、构建系统、包存储库的交互，以及其间的所有步骤。图7.2显示了 软件供应链，恶意行为者可能会损害消费者在生产环境中使用的下游软件工件的完整性。
  如果恶意者可以在源代码存储库中提交错误代码，则可能会在整个构建过程中执行的下游活动中引入漏洞。引入错误代码并不是与源代码管理相关的唯一问题，因为源代码管理（SCM）系统本身可能会受到攻击和破坏，从而影响存储在其中的代码以及它所促进的下游构建和分发活动。
  这种威胁既适用于自托管SCM，也适用于云提供的SCM。在自托管场景中，自托管SCM的组织从基础设施和托管的角度负责其安全性，而在基于云的场景中，如果作为软件即服务（SaaS）交付，则云服务提供商（CSP）拥有底层基础设施和平台的责任，在一定程度上还负起应用程序本身的责任。
  研究人员François Proulx在其文章《SLSA Dip-At The Source of The Problem！》中描述了与SCM折衷相关的攻击树(https://medium.com/boostsecurity/slsa-dip-source-of-the-problema1dac46a976)。 图7.3显示了恶意行为者的示例攻击向量 可以用于危害SCM存储库，如GitHub。
  持续潜在的软件供应链威胁模型，恶意行为者可能使用批准的构建过程和基础设施，但引入的代码与SCM本应使用的代码不匹配。这是一个代码来源信息对于确保所使用的代码来自预期来源并且没有受到篡改或完整性攻击至关重要的例子。SLSA将出处定义为“关于软件工件的可验证信息，描述在何处、何时以及如何生产。”SLSA级别越高，对出处的要求就越严格。
  构建平台是软件供应链的另一个关键部分，是攻击者的另一个主要目标。这个攻击向量被用于Solar-Winds事件，导致构建系统和恶意软件被插入SolarWinds Orion IT管理产品的软件构建中。随后，SolarWinds的下游客户下载并安装了它，其中包括18000多个组织，其中许多是政府实体，这一事实无疑促成了我们在我们在第一章“背景软件供应链威胁。”提到的网络安全行政命令。
  另一种潜在的攻击途径是，恶意行为者可以注入良性依赖，随后可以对其进行修改以产生恶意行为。一个真实的例子是事件流npm包，其中有人自愿承担项目的维护职责，但最终添加了一个名为flatmap流的恶意依赖项。这尤其有影响力，因为事件流包每周下载量超过190万次！
  恶意行为者还利用机会上传会让下游消费者下载并受到影响的恶意软件包。最引人注目的例子是Codecov事件，该事件涉及恶意行为者使用泄露的凭据将恶意软件包上传到Codecov的云存储中。从那时起，Codecov漏洞也影响了数百个客户网络，因为恶意行为者使用Codecov攻击下游客户网络。如果消费者一直在使用出处验证方法，他们可能会发现下载的工件与源代码存储库中预期的不一样。
  LSA还强调软件证明，他们将其定义为“关于软件工件或软件工件集合的经过验证的声明（元数据）”(https://slsa.dev/attestation-model)。
  SLSA列出了一个表示软件验证的通用模型，如图7.4所示。
  2023年初，SLSA推出了他们的候选版本（RC）规范，这是自2021年6月SLSA首次发布以来的首次重大更新。重大变化包括将SLSA划分为多个SLSA轨道，以衡量软件供应链的特定方面。RC规范 还简化和澄清了原始规范的各个方面，并为原产地验证提供了新的指导。也就是说，截至本文撰写之时，每个拟议曲目的具体内容尚未完全定义，将在SLSA的未来版本中解决。如果您有兴趣了解有关1.0候选版本的更多信息，请访问（https://slsa.dev/blog/2023/02/slsa-v1-rc）

7.2 用Google Graph理解制品组合

  在SLSA框架的一个巧妙命名的后续行动中，谷歌与花旗和普渡大学等合作伙伴还宣布了一项名为“理解工件组成图”（GUAC）的开源软件（OSS）工作，如图7.5所示。根据他们的声明，“GUAC解决了整个生态系统中生成软件构建、安全性和依赖性元数据的快速发展所带来的需求”(https://security.googleblog.com/2022/10/announcing-guac-great-pairing-with-slsa.html).
  该公告承认，OpenSSF等组织领导的大量开放源码软件工作，以及软件材料清单（SBOM）格式的软件供应链工作，为保护数字供应链的对话做出了贡献。也就是说，许多信息需要整理和理解。从SBOM格式（如软件包数据交换（SPDX）和CycloneDX），到SLSA等框架和我们讨论过的各种漏洞数据库（如国家漏洞数据库（NVD）、全球安全数据库（GSD）和开源漏洞（OSV））的证明，组织发现自己正试图理解所有数据。
  虽然所有信息都是有用的，但GUAC的工作指出，需要将所有信息结合起来，综合起来，全面了解软件供应链风险。GUAC将各种元数据源整合到图形数据库和关系中，这在审计和风险管理以及开发人员授权等用例中都有好处。
  根据谷歌的公告，GUAC专注于四个关键领域：

  集合包括OSV和GSD等来源，甚至包括内部存储库。Ingestion允许接收上游数据源，如工件、项目和资源。排序从各种来源获取原始元数据，并将其组装成一个标准化的图，以显示项目/开发人员、漏洞和软件版本等实体之间的关系。最后，查询功能支持对组装的图和相关元数据进行搜索，查询SBOM、项目记分卡、漏洞等工件。见图7.6。
  如图7.6所示，收集、摄入、整理和查询支持各种角色和用例，如治理、风险和合规（GRC）和政策专业人员、首席信息安全官（CISO），甚至开发人员。正如公告所提到的，了解特定OSS漏洞的影响需要在企业和更广泛的生态系统中聚合和分析大量数据。GUAC旨在使所有这些信息都可操作，重点是让用户能够回答以下三个基本问题：

  1. 我们如何防止供应链妥协？
  2. 是否有适当的保障措施？
  3. 如果事件发生，我们的组织是否受到影响？

  这三个问题有三个主题领域，如图7.7所示：

  积极主动主题旨在了解软件供应链中最关键的组件以及您的主要弱点和风险敞口。预防措施主题重点是确保部署的应用程序与组织的策略和要求保持一致。被动主题使您的组织能够了解漏洞出现时受到的影响。

7.3 CIS软件供应链安全指南

随着行业不断成熟的软件供应链实践，我们看到了NIST、开源安全基金会（OpenSSF）和互联网安全中心（CIS）等组织的指导。在本节中，我们将讨论最近发布的CIS软件供应链安全指南（https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-SoftwareSupply-Chain-Security-Guide-v1.0.pdf）。本指南是与Aqua Security合作创建的，Aqua Security创建了一个名为chain bench的开源工具，以帮助您审核软件供应链堆栈是否符合CIS指南（https://github.com/aquasecurity/chain-bench）。

《软件供应链安全指南》的CIS基准旨在提供一套与平台无关的高级最佳实践，随后可用于为GitHub、GitLab等平台构建特定于平台的指南。

该指南由五个核心领域组成：

它还涵盖了软件供应链的各个阶段，从源代码到部署，并涉及整个过程中存在的各种潜在威胁载体。如图 7.8 所示，它让人想起另一个新兴框架 SLSA，以及现有的开放全球应用安全项目 (OWASP) 软件组件验证标准 (SCVS) 框架。

总体而言，该指南涵盖了所讨论的五个类别中的 100 多项建议。让我们逐一介绍这五个类别，重点介绍该领域的重要性以及其中包含的一些值得注意的建议。

源代码

如前所述，该指南遵循软件供应链生命周期，因此源代码不可避免地位于列表的顶部，因为它是该生命周期的第一阶段。由指南得出源代码是其余流程/阶段的真实来源。

在处理保护源代码时，您将寻求保护代码以及源代码管理系统，恶意行为者可能会利用这些系统来破坏源代码本身。指南表示保护源代码涉及开发人员、代码中的敏感数据以及源代码管理平台本身等方方面面。

源代码类别本身分为以下几个小节：

■ 代码变更
■ 存储库管理
■ 贡献访问
■ 第三方
■ 代码风险

这些小节包括关键建议，所有这些建议都与源代码安全有关。在“代码变更”小节中，一些值得注意的示例包括确保在版本控制中跟踪代码更改、扫描代码合并以查找风险以及确保代码更改需要两个经过严格身份验证的用户的批准。这些控制措施试图确保跟踪更改、在允许代码更改之前降低风险，以及由具有适当身份验证措施的用户进行同行/双人代码审查。

在“存储库管理”小节中，建议使用安全控制措施，例如确保将 SECURITY.md 文件发布在公共存储库中并清理不活动的存储库。这些措施有助于保护存储库的完整性、指导安全和/或漏洞反馈，并防止存储库蔓延和缺乏治理。

控制贡献访问是用于验证代码完整性是否得到解决的另一项基本措施。在贡献访问子部分中，建议的控制措施包括要求对代码贡献进行多因素身份验证 (MFA)、实施对存储库的最低许可访问控制以及将 Git 访问限制在特定的允许列表 IP 地址。采取这些措施可提高代码贡献流程和源代码的安全性，仅向获得授权、经过适当身份验证且来自获准 IP 地址的用户授予访问权限。

代码存储库中的第三方应用程序对组织构成风险。包括与第三方工具的集成，以实现增强的功能或能力以及开发人员的工作效率。采取措施，例如确保管理员批准已安装的应用程序、删除过时的应用程序以及实施最低许可控制，可以大有裨益。第三方子部分中的这些基本控制措施可最大限度地减少组织的攻击面，并限制第三方应用程序受到攻击时的爆炸半径。

降低代码风险是组织在处理其源代码安全时必须执行的一项关键活动。在代码风险小节中，建议采用风险控制措施，例如扫描代码中的敏感数据（如机密和机密蔓延），特别是在云原生 DevOps 环境中。还包括需要通过静态应用程序安全测试 (SAST) 扫描代码中的漏洞，以及使用软件组合分析 (SCA) 和新兴的 SBOM 工具和实践来查找 OSS 组件中的漏洞。

构建管道

根据 CIS 指南的定义，构建管道用于获取源代码的原始文件并运行一系列任务以获得最终的工件作为输出。这相当于存储并最终部署的软件/应用程序的最新版本。构建管道部分包括构建环境、构建工作者、管道说明和管道完整性。该指南强调，许多建议与自托管构建平台有关，而不是即服务 SaaS 产品。也就是说，即服务产品（例如基于 SaaS 的产品）有其独特的风险，我们在第 6 章“云和容器化”中提到过。

对于构建环境，该指南建议采取一些控制措施，例如将管道专用于单个存储库、使用不可变的管道基础设施和配置，以及确保记录构建环境的活动。这些控制措施可确保组织避免诸如漂移和配置偏差、出现问题时缺乏可见性/日志记录等问题，并在创建构建环境期间促进自动化，从而最大限度地降低手动活动的风险。这些控制有助于避免诸如人为错误之类的问题，这些问题可能导致数据泄露和配置错误，而恶意行为者可以利用这些错误。

构建工作者，称为运行者，是管道操作基础设施的核心组件，也是那些试图造成破坏的人的目标。工作者可以签出代码、执行测试，甚至将代码推送到注册表，所有这些都可以用于邪恶的目的。这里的安全控制包括一次性构建工作者、构建工作者之间的职责分离以及运行时安全性的实施。这些活动试图确保监视运行时事件是否存在恶意行为模式，将构建工作者的潜在攻击限制在其分配的职责而不是更广泛的环境中，并最大限度地降低数据被盗的风险。

管道指令用于将源代码转换为最终工件。当被篡改时，指令可用于执行恶意活动。安全控制包括将构建步骤定义为代码、明确定义输入和输出以及自动扫描管道以查找配置错误。这些控制确保构建步骤不可变且可重复，并具有预期的输入/输出，并且扫描可以识别错误配置以避免后门或妥协。

维护管道完整性是一项关键控制，包括验证管道、必要的依赖项及其生成的工件是否符合要求且未经更改。此领域的关键控制包括尝试确保工件在发布时签名、依赖项在使用前经过验证以及管道生成可重现的工件。这些控制可验证工件是否由受信任的实体签名、依赖项在使用前经过审查以及管道是否持续生成工件以确保未发生篡改。该指南还建议不仅为软件或构建过程的每个组件生成 SBOM，还建议确保对 SBOM 进行签名以进一步证明其有效性。这些建议与 NIST 和 OpenSSF 的指导一致，并利用 Sigstore 等技术，我们在第 4 章“软件物料清单的兴起”中关于 SBOM 和软件签名的讨论中介绍了这些技术。

依赖项

CIS 指南认识到依赖关系在软件供应链中发挥的基本作用。它强调依赖关系通常来自第三方来源（例如 Log4j），一旦被利用，可能会造成巨大损失。事实上，Sonatype 和 EndorLabs 等研究表明，七分之六的漏洞来自传递依赖关系。

第三方软件包需要适当的管理和使用，包括努力建立信任并适当管理其使用。第三方软件包不仅会影响您的软件，还会影响您软件的下游消费者，Log4j 及其相关的受影响软件供应商的大量通知就是明证。此处的安全控制包括验证第三方工件和开源库、要求第三方供应商提供 SBOM 以及要求/验证构建过程的签名元数据。 这些步骤有助于降低使用恶意或高风险第三方组件的风险，从而了解供应商/供应商的软件内部情况，并确保工件在构建过程中没有受到损害。

该指南要求验证软件包以了解如何以及是否使用它们，它包括政策和技术控制的组合，例如建立组织范围内的依赖项使用指南、扫描软件包中的已知漏洞以及保持对所有权变化的认识。这些控制有助于管理软件包的使用，同时确保现有软件包不易受攻击，并跟踪可能导致新所有者进行恶意活动的所有权影响。

工件

根据 CIS 指南的定义，工件是存储在软件包注册表中的软件的打包版本。该指南强调需要在整个生命周期内保护工件，从创建到部署到环境中。

进行验证控制是必要的，例如确保工件由管道签名，然后在分发之前加密，以及控制谁可以执行解密。此类控制可确保工件具有完整性和机密性，仅限于有权查看工件解密副本的人员。

必须实施工件的基本访问控制也是必须的。此领域通常涉及存储工件的注册表，确保在交付给客户之前，工件没有通过各种攻击媒介被篡改。控制包括控制可以上传新工件的允许用户数量，并为用户访问实施 MFA。这追求将用户管理从软件包注册表分离到外部身份验证机制/服务器的目标。

软件包注册表是攻击面的另一个组成部分，也是组织工件的存储位置。虽然目标是保护工件，但如果不保护存储它们的注册表，您就无法做到这一点。 控制措施包括审核软件包注册表的配置更改以及以加密方式验证软件包注册表中的工件。

来源可追溯性或代码出处是另一种越来越受关注的最佳实践。它是确保组织及其客户都了解工件的来源以及工件来自可信来源的过程。必须通过 SBOM 和元数据等方法确保工件包含有关其来源的信息。组织还应使用代理注册表来代理来自公共注册表的内部软件包请求。此建议与 NIST 800-161r1 附录 F（https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf）相一致，该附录要求建立已知验证组件的内部注册表。NIST 800-161 附录 F 有自己的网页（www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains）。

部署

最后，我们进入开发阶段——软件供应链的最后阶段，在此阶段，工件被部署到运行时环境。此阶段的控制包括部署配置和部署环境。

对于部署配置，建议您将部署配置文件与源代码分开，跟踪部署配置更改，并使用扫描器来保护基础设施即代码 (IaC) 清单。 部署配置中的错误配置或漏洞会使部署环境变得脆弱。

部署环境建议包括使部署自动化和可重复，并限制对需要它的人的访问。这些建议确保部署不可变，避免配置偏差，并限制访问以最大限度地减少威胁。

虽然软件供应链安全仍然是一个不断发展的领域，但 CIS 指南以及本书中提到的其他组织的指导，成为历史上网络安全阴暗领域的一盏明灯。 软件供应链是一个极其复杂和脆弱的生态系统，由于它影响到无数的组织、消费者、供应商和行业，它存在系统性风险。请务必留意后续特定于平台的 CIS 基准，这些基准建立在《CIS 软件供应链指南》中引用的控制和建议的基础上.

7.4 CNCF的软件供应链最佳实践

在有关软件供应链安全的讨论中经常引用的另一个行业指导来源是 CNCF 的软件供应链最佳实践白皮书 https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)。该白皮书于 2021 年发布，涵盖了保护源代码、物料、管道、工件和部署。它引用了 SolarWinds 事件作为引起人们对软件供应链关注的关键问题，并围绕四个基本原则构建：

■ 供应链中的每一步都必须值得信赖。
■ 供应链中的每一步都必须使用自动化。
■ 必须正确定义和保护构建环境。
■ 供应链环境中的所有实体都必须进行相互身份验证。

白皮书还认识到，不同组织和行业存在各种保证角色和风险偏好。并非所有组织都有相同的保证要求；国防部 (DoD) 运营的武器系统的安全要求比不处理敏感数据的简单 Web 应用程序要严格得多。组织可以根据其特定的风险承受能力和保障要求使用白皮书中的建议来降低软件供应链风险。

白皮书采用了低、中、高三个保证级别。低保证环境是指在开发过程中投入很少时间来保护产品的完整性（或安全性）的环境。中等保证包括合理的保证要求，与大多数部署相一致，并作为本文的基准。最后，高保证环境要求产品不被篡改、抵制未经授权的更改，并采用高保真证明和验证流程。

如图 7.9 所示，白皮书将其与与原材料、产品和制造相关的传统供应链进行了类比。它指出，就像技术如何从精益制造中采用敏捷和 DevOps 实践一样，软件供应链可以利用制造业的洞察力

尽管如此，尽管与制造业供应链有相似之处，白皮书也强调了一些关键差异。首先，现实情况是软件供应链是无形的，包括虚拟和数字组件，这些组件不像物理领域的组件那样可见。其他关键差异包括软件供应链确实并将继续以更快的速度发展，因为它们以技术为中心。最后是重用的存在和数字供应链的复杂性。许多人经常使用短语“一路向下的乌龟”，这意味着在大多数情况下它是一个无限的回归，具有多个级别的直接和传递依赖关系。许多产品和供应链是其他产品或供应链的一部分或组件。这种现实可能会带来一些挑战，特别是因为数据显示大多数漏洞普遍存在于传递依赖关系而非直接依赖关系中，但大多数组织并不了解其传递依赖关系的全部范围。

与物理供应链非常相似，数字和软件驱动供应链中的每一步都有可能引入风险——因此，出现了诸如 SLSA 之类的框架，以及相关的最佳实践，以减轻软件供应链生命周期每一步的风险。与更广泛的网络安全和技术非常相似，软件供应链的强度取决于其最薄弱的环节，因此供应链某一环节的漏洞可能会对供应链的其余部分以及所有下游消费者和利益相关者产生连锁影响，正如我们在供应商和 OSS 组件中多次看到的那样。

CNCF 的指南强调了一些关键主题，例如验证、自动化、受控环境中的授权和安全身份验证。这些主题对于确保整个软件供应链生命周期的强大保证至关重要，并贯穿整个文档的各种建议和推荐控制。

验证是确保从一个阶段到下一个阶段的完整性的关键，而自动化有助于促进可重复和不可变的流程。对机器和人类实体的权限进行适当调整可确保每个实体和阶段只能进行明确定义和要求的活动。虽然这是一种长期存在的安全最佳实践，但这种最不宽松的方法也在行业推动零信任的过程中得到强调，因此在这方面有相似之处。

最后，安全身份验证可确保供应链中实体之间的相互身份验证，使用与环境和所涉及组织的保证级别相一致的身份验证方法。该指南涵盖了供应链的五个阶段——保护源代码、保护材料、保护构建管道、保护工件和保护部署——我们将在以下章节中讨论每个阶段

确保源代码安全

  软件供应链起源于源代码。创建和保护这些源代码是一项基础活动，有可能影响整个下游供应链的完整性。CNCF 的指南指出，身份访问管理 （IAM） 是任何平台或供应商在这方面最关键的攻击媒介，它适用于有权访问源代码存储库的人类和机器实体。Verizon 的 2022 年数据泄露调查报告 （DBIR; www.verizon.com/business/resources/reports/dbir） 等报告证实了这一说法，该报告显示，超过 60% 的数据泄露涉及泄露的凭据。

源代码安全建议涵盖了前面提到的五个主题。这些包括验证活动，例如实施签名提交以确保源提交或修改的完整性和不可否认性。有更传统的方法，例如 GNI 隐私保护 (GPG) 密钥或安全/多用途互联网邮件扩展 (S/MIME) 证书，但也有创新的新兴解决方案，例如 GitSign (https://github.com/sigstore/gitsign)，它使用 Sigstore 来促进“无密钥”签名。由于与传统签名和密钥管理活动相关的开销减少，这是一种越来越有吸引力的签名工件和元数据的方法。

自动化还可用于保护源代码和相关存储库。其中一个领域是暴露秘密的问题。在这种情况下，秘密是诸如凭证文件、安全 Shell (SSH) 密钥、访问令牌和应用程序编程接口 (API) 密钥之类的项目。机密蔓延，即敏感凭证的传播和分发，是一个严重的问题，尤其是在包含声明式方法和在各种清单和配置文件中提交机密的机会的云原生 DevSecOps 环境中。

GitGuardian 是一家专注于机密管理的公司，它制作了高度翔实的报告，例如《2022 年机密蔓延状况报告》（www.gitguardian.com/state-of-secrets-sprawl-report-2022），该报告深入探讨了这一问题。一些令人震惊的指标包括 2021 年每位应用程序安全工程师检测到的机密事件超过 3,000 次，2021 年公开暴露的机密超过 600 万个，是 2020 年的两倍。本书的一位作者撰写了一篇文章，介绍了机密管理的现状以及不良做法可能产生的影响（www.csoonline.com/article/3655688/keeping-secrets-in-a-devsecops-cloud-native-world.html）。这些暴露的机密可能会授予恶意行为者的访问权限并在整个环境中造成严重破坏。 GitGuardian 发布的《2023 年机密蔓延状况》报告发现，在公共 GitHub 存储库中暴露了超过 1000 万个新机密，而问题似乎也没有改善。2022 年，机密也以某种形式或方式卷入了安全事件，影响了业内一些最著名的组织，例如 Uber、NVIDIA、Microsoft 和 Slack (www.gitguardian.com/state-of-secrets-sprawl-report-2023)。

为源代码存储库实施受控环境提供了一个机会，可以通过相应的控制来减轻多种风险，包括建立和遵守管理代码贡献的贡献政策。根据先前关于适当调整权限的建议，也有机会协调角色并将权限与组织内的职能职责相关联。组织可以采取更进一步的措施通过使用基于上下文的访问控制机制，检查一天中的时间和设备姿势等因素，以提供动态的、基于时间的访问，这在零信任环境中很常见。网络安全的许多领域经常提出的另一项基本建议是强制职责分离，以便请求的作者不能同时是其批准者。

身份验证是一种帮助授予实体（无论是人还是机器）对源代码存储库的初始访问权限的活动。这里的一些建议包括强制执行 MFA 以访问存储库和使用 SSH 密钥来促进开发人员访问等活动。这些密钥应该有一个相关的轮换策略，以确保如果密钥被泄露，它们在恶意访问和活动方面产生负面影响的能力是有限的。对于机器或服务实体，组织应该采用短期和短暂凭证。这些凭证可以允许机器和服务（例如管道代理）访问，但也可以减轻凭证泄露的影响，因为密钥不断被生成、使用和丢弃。如前所述，被盗用的凭证是恶意行为者最常见的攻击媒介之一，因此使用短期凭证可以减轻这种影响。

确保物料安全

  在软件供应链的背景下，CNCF 的指南将材料作为依赖关系和库进行讨论，无论它们是直接的还是可传递的。这一部分与本书的总体概念密切相关，该概念侧重于软件供应链的透明度和安全性。该指南提到，某些高可靠性环境可能需要仅使用受信任的存储库，同时阻止对其他存储库的访问。值得一提的是，NIST 800-161r1 指南建议建立已知可信组件的内部存储库以供开发使用，我们将在第 8 章“现有和新兴政府指南”中讨论，该指南涵盖了 NIST 的 800-161r1 指南。

  CNCF 指南强调，当涉及到他们正在使用的第二方和第三方软件时，组织应该使用风险管理方法。虽然组织和开源项目都习惯于发布易受攻击代码的常见漏洞和暴露 （CVE），但该指南指出，CVE 也是一个尾随指标，这意味着一旦发现并发布漏洞，它们就会通知消费者;他们使用的代码已经很脆弱。对于组织来说，利用其他指标也很重要，这些指标可以告知使用者与与运营运行状况等指标相关的项目和代码相关的风险。其中一个项目是OpenSSF的记分卡项目，我们将在即将到来的 “OpenSSF记分卡”一节中讨论。

  组织使用来自外部实体的软件组件，因此验证这些第三方库和组件至关重要，包括使用校验和和验证签名等方法。组织还可以（并且应该）使用 SCA 和 SBOM 生成等方法来确定他们正在使用的软件中是否存在任何易受攻击的开源组件。一旦组织使用了 SCA 和 SBOM，他们就可以开始跟踪其使用的 OSS 组件与其所属系统之间的依赖关系，作为其更广泛的软件资产清单工作的一部分。组织可以开始生成供应链清单，该清单不仅包括 OSS 组件，还包括整个组织使用的软件供应商、供应商和来源。

  该指南警告的另一个风险是，恶意代码可能包含在编译软件中，例如二进制文件或压缩包，这些软件是编译的，而不是源代码或文本格式。因此，该指南建议组织从源代码构建其库，而不是使用已编译的软件，因为这些软件可能已被恶意行为者破坏。与创建软件供应链清单的建议非常相似，该指南建议组织拥有受信任的包管理器和存储库的清单，并控制其访问权限，以限制从未经批准的来源引入代码。
  组织还应利用自动化手段来确保从外部获取的材料的安全性。这方面包括扫描软件以发现漏洞、许可影响，并识别与所引入软件相关的直接和传递依赖项。

保护构建管道

  CNCF的SSCP指南将制造业装配线与软件供应链生态系统中的构建流水线进行了类比，甚至将构建流水线称为“软件工厂的核心”。这条流水线汇集了前文讨论过的许多材料，来自诸如源代码控制仓库和第三方提供者等来源。这些构建流水线由多个组件组成，包括构建步骤、工作器、工具和流水线编排器，我们稍后在“安全软件工厂参考架构”章节也将对这些组件进行讨论。
  确保构建流水线的安全性需要加固构建步骤及其相关输出，以确保既不会危害构建流水线本身，也不会危害其过程。恶意行为者知道，如果他们能够入侵构建流水线，他们可以向下游消费者分发恶意软件，而这些消费者可能并不知道上游构建过程已经被入侵。

CNCF 建议采取一些关键步骤来保护构建管道： ■ 使用单个存储库来存储所有构建组件
■ 记录步骤和相关输入/输出
■ 使用签名工件和元数据等方法来确保构建过程的完整性

  组织还应对其构建流水线和基础设施进行威胁建模和自动化安全测试，就像对其他生产系统和环境进行的操作一样。简而言之，从安全的角度来看，您的构建系统应该像生产系统一样对待，因为它们的输出最终会进入运行时环境。如果这些输出受到威胁，生产运行时环境也将受到威胁。
  虽然CNCF的出版物没有具体提到，但关于这个主题的一个优秀的指南来源是新成立的OWASP Top 10 CI/CD安全风险项目。正如该项目所言，CI/CD环境、流程和系统是现代软件交付的核心。该项目指出，滥用CI/CD环境已导致了几起显著的安全事件，如SolarWinds、Codecov等，影响了成千上万的下游消费者和组织（链接：https://owasp.org/www-project-top-10-ci-cd-security-risks）。
  该指南指出了现代构建环境的核心组件，例如流水线编排器、构建工作器以及从安全的工件存储库获取（见图7.10）。这些实体协作执行诸如构建和链接依赖项、构建应用程序、测试并发布到安全存储库等步骤，最终部署应用程序。如果这些过程和实体受到威胁，将对部署环境产生下游影响。
  验证是指南强调的另一个关键活动。这个领域包括使用加密来验证策略的遵从性、在使用前验证环境和依赖关系，以及验证构建工作器的运行时安全性，如图7.10所示。指南提到，产生端到端的加密保证是其中一种选项。
  另一个重点是在高保证和高风险环境中使用可重现构建。简而言之，可重现构建能够使用特定输入生成可以进行加密证明的输出。这意味着可以识别和应对恶意或无意的修改。这种实践在其他指南来源中也有体现，如SLSA所指出的，但众所周知，这并非一项简单的工作，可能在时间和资源上成本高昂。因此，这是一种为高保证环境保留的实践。

其他值得注意的实践和功能包括：

■ 自动创建构建环境
■ 在不同基础设施环境中分发构建
■ 使用自动化来标准化跨团队和项目的管道
■ 配置安全的编排环境以托管软件工厂（请参阅即将到来的部分“CNCF 的安全软件工厂参考架构”

保护工件

  在完成构建阶段后，会生成软件和制品，以及与它们相关联的元数据。为了确保这些制品的完整性，可以采用多种方法进行保护，例如签名。CNCF建议在制品的每个生命周期阶段都进行签名，以确保其完整性。签名是一种通过使用加密密钥对制品进行数字签名的方法，以证明制品在特定时间点由特定实体生成，并且在传输或存储过程中没有被篡改。通过在每个重要阶段对制品进行签名，可以确保制品在整个生命周期内都可以追溯到其源头，并防止未经授权的更改或操纵。
  CNCF的指南建议组织在构建过程中的每个步骤都进行签名，并验证生成的这些签名。他们引用了更新框架（The Update Framework，TUF）、SPIFFE和SPIRE作为可以用来支持整个过程所需证明的项目示例。SPIFFE和SPIRE旨在为现代和异构基础设施提供统一的身份控制平面。SPIFFE和SPIRE的支持包括保护微服务通信、实现安全认证以及用于零信任安全模型的跨服务认证（链接：https://spiffe.io）。通过使用TUF和Notary来自动化管理制品的签名、存储相关元数据和输出，组织可以采纳自动化方法。
  组织还应采取措施限制特定方能够签名的制品，并将这些能力与时间绑定，定期进行审查。时间绑定涉及在凭证和访问有效性上设置时间限制。制品生成后，在分发之前，组织应对其进行加密，并以只有授权平台和消费者能够解密的格式进行加密。遵循这些步骤确保了制品在其各个生命周期阶段内的完整性，并确保最终消费者或接收方（无论是个人还是非个人实体）拥有适当范围的权限和访问控制。这些措施有助于防止未经授权的篡改或访问，从而保护制品的安全性和可信度。

保护部署过程

  在CNCF SSCP白皮书的结尾部分是“Securing Deployments”（保护部署）部分。CNCF再次强调了在这一活动中TUF的重要性，并且有必要能够检测和防止恶意活动。
  验证被提出作为一个关键活动，一旦软件制品被部署，客户端接收到软件制品后可以验证其完整性，还可以验证相关的元数据。这意味着他们可以验证一个软件构建物清单（SBOM）的签名（如果有的话），并验证其是否由授权方签名。

7.5 CNCF的安全软件工厂参考架构

  对许多人来说，将软件生产与工厂这一术语联系起来可能看起来有些奇怪。大多数人仍将工厂与收集、处理和制造物理材料如钢铁、汽车或消费电子产品联系在一起。然而，讽刺的是，现代大多数工厂环境的运作依赖软件，而软件的生产方式越来越具有与工厂类似之处。术语“软件工厂”通常指为了以高效、可重复和安全的方式生产软件而必需的工具、资源和流程的集合。
  这个术语在公共和私营部门都得到了广泛应用，并且得到了包括MITRE和VMware在内的组织的认可。美国国防部（DoD）拥有29个软件工厂的强大生态系统，其中最著名的包括Kessel Run、Platform One和陆军软件工厂。软件工厂的概念也正在扩展到美国联邦民用机构，例如医疗保险与医疗补助中心（CMS）的batCAVE项目。这个术语还得到了行业领先组织如CNCF的认可，他们发布了他们的安全软件工厂参考架构。让我们来更详细地了解一下。

安全软件工厂参考架构

  CNCF定义软件供应链为“在编写、测试、打包和分发应用软件给最终消费者时执行的一系列步骤。” 软件工厂是在总体上促进软件交付的逻辑构造，在正确实施时确保安全性是应用交付过程的关键组成部分。
  CNCF安全软件工厂（SSF）参考架构（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/securesoftware-factory/Secure_Software_Factory_Whitepaper.pdf）建立在先前的CNCF出版物基础上，如云原生安全最佳实践（链接：https://github.com/cncf/tag-security/tree/main/security-whitepaper）和软件供应链最佳实践（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf）。该参考架构强调现有的开源工具，重点放在安全性上。它还围绕着《软件供应链最佳实践》白皮书中的四个总体原则展开：

  每个原则都是确保从软件的起源和代码到生产环境安全交付的必要条件。
  该参考架构还明确指出，它并不专注于像代码扫描和签名这样的关注点，而是更深入地关注代码来源和构建活动。这种关注的理由在于，下游活动，如静态应用安全测试/动态应用安全测试（SAST/DAST），依赖于验证来源以及您从中接收某些内容的方当的身份是否是受信任的实体。这些身份可以是与人类用户相关联的身份，也可以是与机器身份相关联的身份。签名的结合以及验证其来自可信源的事实对于保证来源的可靠性至关重要。
  安全软件工厂（SSF）中的每个实体都有依赖关系，无论这些依赖关系是与更广泛的组织IAM系统相关、源代码管理相关，还是下游消费者依赖于SSF本身来证明和签名他们正在使用的制品。
  SSF具有多个组件，其中一些被认为是核心组件、管理组件和分发组件。核心组件负责接收输入并使用它们来创建输出制品。管理组件专注于确保SSF与您的策略保持一致运行。最后，分发组件将工厂的产品安全地移动到下游进行消费。

核心组件

  这些核心组件包括您的调度和编排平台、流水线框架与工具，以及构建环境。所有SSF组件都使用平台及其相关的编排来执行它们的活动。流水线及其相关工具能够促进构建软件制品的工作流程。指南强调，流水线应该符合与您的工作负载相同的要求。这旨在指出流水线是您攻击面的一部分，并且可以被利用来影响下游消费者，就像SolarWinds事件中的情况一样。这种强调也得到了像SLSA等新兴框架的支持。
  最后，您有构建环境，这是将您的源代码转换为机器可读软件产品（称为制品）的地方。成熟的构建环境正在努力提供关于构建过程中使用的输入、操作和工具的自动证明，以验证构建过程及相关输出/制品的完整性。
  像TestifySec（www.testifysec.com）这样的组织正在进行创新，以确保组织能够检测流程篡改或构建受损。一个显著的例子是Witness项目，旨在防止构建材料的篡改，并验证从源到目标的构建过程的完整性（链接：https://github.com/testifysec/witness）。

管理组件

  管理组件包括策略管理框架、证明者和观察者。在SSF的背景下，您的策略管理框架是帮助编码组织和安全需求的核心，例如IAM（身份和访问管理）、分配的工作节点和授权的容器镜像。由于不同的风险容忍度和多种适用的监管框架，这些策略在每个组织中可能会有所不同。随着零信任模型的推广，策略管理框架尤为关键。
  确定谁有权做什么及在何种上下文中进行是执行零信任原则（如最低权限访问控制）的关键。您不希望部署由未经授权的个人推送的容器，甚至不希望使用您不信任或未经您信任来源签名的容器等。鉴于云原生环境通常意味着您使用容器和像Kubernetes这样的编排器，您将拥有节点证明者、工作负载证明者和流水线观察者等实体。它们验证节点和工作负载的身份和真实性，以及与流水线过程相关的可验证元数据。

分发组件

  在SSF中识别的关键组件中，还包括分发组件，包括制品库和准入控制器。您的流水线过程的输出产生制品，这些制品存储在您的制品库中。这些制品可以包括容器镜像、Kubernetes清单、SBOM（软件供应链安全性清单）以及相关签名。越来越多地，我们看到使用诸如Sigstore之类的解决方案来签署不仅仅是代码，还有SBOM和证明。这在之前讨论过的Linux Foundation/OpenSSF开源软件安全动员计划中得到了强调（链接：www.csoonline.com/article/3661631/the-open-source-software-security-mobilization-plan-takeaways-for-security-leaders.html）。在制品库之后，您有准入控制器，负责确保只有授权的工作负载可以由调度和编排组件运行。这些控制器可以执行策略，例如允许哪些来源进入构建，允许哪些组件进入节点主机，并且使用的组件是可信且可验证的。

变量和功能

  SSF指南理解到，SSF的输入和输出会有所不同。输入包括源代码、软件依赖、用户凭据、加密材料和流水线定义等。输出包括软件制品、公共签名密钥和元数据文档等。白皮书还讨论了SSF的功能，例如项目在SSF中的流动过程，最终提供经验证和具有一定保证水平的安全输出和制品，以建立与下游消费者的信任关系。

小结

  初看起来，SSF参考架构似乎很复杂，而实际上确实如此。在现代云原生环境中交付软件涉及许多组成部分和相关流程，以确保所消耗和生产的内容能够以符合组织风险容忍度的保证水平完成。
  这种复杂性还强调了将所有要素整合在一起的挑战性，以及系统中可能存在的错误和配置错误的机会，这些可能会对整个生态系统中的消费者产生连锁反应的影响，而现代经济中的所有这些都由软件驱动。人们常说，防御者必须始终正确，而恶意行为者只需一次正确。在充满人员挑战和认知负荷的复杂云原生环境中，这就像在一堆针中寻找特定的针，而不是在一堆草垛中寻找。

7.6 微软的安全供应链消费框架

  作为开源软件（OSS）的主要贡献者和消费者之一，微软推出了一个名为安全供应链消费框架（Secure Supply Chain Consumption Framework，S2C2F）的软件供应链安全框架并不奇怪。微软于2022年8月正式宣布了S2C2F，但他们早在2019年就已经开始在内部使用该框架来保护他们自己的开发实践。更进一步，微软于2022年11月将S2C2F贡献给了开源社区，通过让行业开源软件安全基金会（OpenSSF）正式采纳（链接：www.microsoft.com/en-us/security/blog/2022/11/16/microsoft-contributes-s2c2f-to-openssf-to-improve-supply-chain-security）。
  把我们深入了解一下这个框架，看看它涵盖了哪些内容并旨在实现什么目标。微软表示，该框架的目标是阐明安全消费开源软件依赖的核心概念，并实施安全开源软件消费的核心实践。与类似的框架一样，该框架强调了开源软件在软件生态系统以及更广泛的行业中的关键作用，无论是在推动生产力还是创新方面。微软指出，该指导分为两个部分：

  S2C2F具有三个高层次的目标：

  这三个框架目标与以下三个核心概念相辅相成：

  图7.11展示了这些目标和核心概念。
  尽管核心概念表面上听起来简单，但在开发软件的大型企业环境中，它们可能非常复杂和令人畏惧。正如S2C2F指出的那样，现代软件开发人员以多种方式消费开源软件。开发标准化的开源软件消费方式，并让开发人员坚持这些方式，有助于确保开源软件的安全性。
  整个组织的所有开发团队中引入一种受控和结构化的开源软件（OSS）消费方法至关重要。与大多数安全框架类似，S2C2F是组织踏上的一段旅程，因此它被构建为一个专注于持续过程改进的成熟度模型。组织可以优先考虑早期实施的特定要求，并在新的威胁和风险出现时进行调整。
  最后，单独实施的做法和成熟度并不高效，也无法应对现代企业广泛的攻击和风险面。因此，S2C2F以规模化作为一个核心概念。指南特别提到的一个具体例子是倡导开发人员使用集中式内部注册表，这也是NIST软件供应链指南800-161 r1等来源的建议之一。
  正如框架指出的，一旦单个开发人员决定从内部注册表之外的任何地方拉取开源软件组件，这种模型就会崩溃，而内部注册表本身需要额外的开销和管理，这带来了相关的负担和成本。正如他们所言，S2C2F的设计旨在在不采用其他指南中提倡的集中化方法的情况下，规模化地确保开源软件的消费安全性。这种思维方式对于倡导或采取更为分散化方法的组织应该是有共鸣的。
  S2C2F是一个结合工具和要求的能力成熟度路线图，专注于通过治理确保安全的开源软件摄入。S2C2F指南讨论了常见的开源软件供应链威胁，不仅涵盖威胁本身，还包括现实世界中发生的攻击实例，并将它们映射到具体的S2C2F要求上。S2C2F提供的示例涵盖了从开源软件代码或容器中的意外漏洞到仓库和软件包中的有意后门和恶意活动。该指南借鉴了诸如Google的《软件供应链威胁》等来源，其中涵盖了源头、构建、部署/运行时和依赖项等方面的威胁（链接：https://cloud.google.com/software-supply-chain-security/docs/attack-vectors）。列出的威胁还包括了更为温和的来源，如已经停止更新并且不再修复漏洞的开源软件组件，以及维护者未能在消费者期望的时间内修复漏洞。

7.7 S2C2F 实践

  如前所述，S2C2F包括一系列解决方案和供应商无关的实践，这些实践可以帮助组织确保其开源软件供应链的安全使用。合规、安全、工程管理人员以及首席信息安全官（CISO）等领导者可以参考这些实践，以识别其组织在安全使用和治理开源软件方面存在的差距。现在让我们逐步了解这些实践，以理解它们包含了哪些内容。
  第一个被引用的实践是摄入（Ingestion）。正如S2C2F指出的那样，安全保障软件供应链的第一步是控制工件输入，包括打包和源代码工件。这里的实践旨在使组织能够在外部开源软件源可能被 compromised 或不可用的情况下仍能够交付资产。打包工件包括诸如Linux软件包仓库或Open Container Initiative（OCI）注册表等内容。组织需要代理这些外部来源并保存所需的副本。在源代码工件方面，该实践提倡在内部镜像外部源代码仓库，并在本地缓存软件包，以使组织能够在不利情况下继续运作，从而展示业务连续性。这还允许组织进行安全扫描，甚至在需要时向上游贡献修复程序，或在本地修复代码而不是向上游贡献。
  在摄入（Ingestion）之后，下一个实践是扫描（Scanning），其目标是确保消费组织和个人能够看到与开源软件组件相关的漏洞。正如S2C2F所述，通过扫描摄入的开源软件组件，组织可以识别配置错误、易受攻击的代码、已知漏洞或增加潜在攻击面的额外代码，从而建立对组件安全状况的可见性，进而构建信任。   组织可以利用众多开源软件和专有的扫描工具来执行这一实践。一旦组织摄入并扫描了开源软件组件，它们需要对其进行清单管理，以便了解这些开源软件组件存在于生产环境中的位置。S2C2F使用的一个完美例子是Log4J事件。那些准确记录开源软件组件清单的组织，比那些缺乏这种清单的组织在应对事件时表现得更加从容。随着其他重要漏洞在开源软件组件中的出现，有清单的组织可以通过修复或优先处理易受攻击或已被入侵的组件和系统来快速响应。
  经过扫描和编制清单的开源软件组件是一个很好的开始，但众所周知，软件像牛奶一样会老化——这意味着生产环境中的组件必然需要更新和修补。因此，接下来的实践是具备根据需要更新组件的能力。众所周知，当漏洞被公开披露时，通常是组织修补或处理漏洞与恶意行为者利用漏洞之间的竞赛。
  因此，跨企业的开源软件覆盖面，对于在规模上更新和修补易受攻击组件的能力至关重要。另一个考虑因素是，开源软件组件通常由志愿者维护，并没有与漏洞处理相关的服务级别协议（SLA）。因此，如果开源软件维护者未直接提供补救措施，消费者必须准备实施虚拟修补和其他缓解控制措施。
  拥有围绕开源软件摄入和使用制定的标准化流程是一回事，但你必须能够审计你的环境，以识别那些偏离流程或对你的组织构成风险的组件。
  因此，指南中的下一个做法是审计。这意味着组织可以对其开放源码软件组件进行审计，并验证它们是否经过了摄取、扫描和清点的标准化流程；否则，治理就会开始崩溃。
  审计固然重要，但组织必须能够对发现的不受治理的开放源码软件组件采取措施。因此，执行是指南中的下一个实践。如果开发人员绕过既定流程，从不受信任的来源引入不受管理的开放源码软件组件，那么组织必须能够纠正这种偏差。指导意见提供的例子是，如果引入未经验证的开放源码软件组件，则强制执行 DNS 流量重路由或在构建流程中建立关卡，以中断构建。越来越多的恶意行为者试图破坏构建流程或基础架构，从而导致二进制文件和工件受损。
指南中的下一项内容是，能够从源代码中重建部署的每个开放源码软件工件。如果恶意行为者能够插入带有后门的恶意开放源码软件包，或在构建过程中对生成的二进制文件进行未经授权的更改，这一点就变得非常关键。
  S2C2F 强调，对于关键工件或关键业务的高价值资产，可能有必要为用于创建生产服务或应用程序版本的每个工件创建从原始源代码开始的监管链。本实践的重点是使依赖于关键开放源码软件组件的开发人员能够获取源代码、重建源代码、在需要时修改源代码（如通过签名），然后缓存重建后的工件供内部使用。
  这种做法直接指向可重现构建，即软件开发中创建从源代码到二进制代码的独立可验证路径的做法 (https://reproducible-builds.org/docs/definition)。这将导致所有相关工件的比特位完全相同的副本。您会注意到这一实践在其他新兴指南（如 SLSA）中也很普遍，尤其是在成熟度较高的情况下。
  S2C2F 的最后一项实践是能够修复问题并向上游反馈。S2C2F 规定："我可以在接到危害通知后 3 天内私下修补、构建和部署任何外部工件，并将修复结果秘密贡献给上游维护者。这是一种非常成熟的做法，因为它将责任从严格依赖维护者转移到了软件消费者作为开放源码软件项目或组件的积极贡献者。这正是我们在文中其他部分提到的研究人员所倡导的行为类型，例如 Chinmayi Sharma 题为 "数字公共资源的悲剧 "的研究。
  尽管如此，该指南指出，这仅适用于极端情况，以及上游维护者无法在贵组织可接受的风险窗口内提供公共修复时的临时风险缓解。这体现了对允许维护者采取适当行动的认可，同时也愿意在适当的时候提供帮助，这正是开放源码软件社区的精神所在。S2C2F 还提倡组织为开放源码软件社区做出贡献的几种方式，如直接或通过基金会提供财政支持、参与赏金计划、倡导最佳实践，以及积极参与重要的开放源码软件项目。

7.8 S2C2F 实施指南

如图 7.12 所示，与 SLSA 等其他框架一样，S2C2F 也围绕四个成熟度级别展开，从最基本的开放源码软件治理一直到高级威胁防御，每个级别都有自己的相关活动。

第1 级包括基本活动，如内部缓存软件包、进行基本清查和基本扫描，以及更新环境中的开放源码软件。第 2 级在此基础上，缩短修补易受攻击组件和执行事件响应的平均恢复时间（MTTR）。第 3 级包括创建一个已知恶意或不可靠组件和来源的否认列表，扫描开放源码软件组件中的恶意软件，并强制执行出处。最后，第 4 级被认为是理想级，这意味着除了行业内资源最丰富、最敏感的组织外，大多数组织都无法达到这一成熟度级别。这一级别的活动包括在可信的构建基础架构上重建开放源码软件，以及为重建的开放源码软件组件创建和数字签名 SBOM。

虽然这四个成熟度级别和相关的能力或要求很有帮助，但组织需要了解如何根据这些级别来评估自己或他人。S2C2F 提供了两个高级步骤：准备评估和实际执行评估。准备工作包括确保组织能够自如地与开发和工程团队接触，以了解指南中讨论的工具、能力和工作流程。指南还提供了一系列可用于评估的示例问题。这些问题涉及了解项目中目前如何使用开放源码软件、其来源以及现有的治理和安全实践，正如前面的核心概念、目标和框架的成熟度级别中所讨论的那样。

评估结束后，各组织应能更好地了解其目前在框架建议的能力和实践方面的成熟度。有了这种认识，组织就有能力制定改进计划，以解决评估过程中发现的不足或薄弱环节。然后，各组织可以根据各自的目标和风险承受能力，有针对性地进行投资和采取举措，以提高他们认为最关键的能力和做法。

S2C2F 以矩阵表的形式列出了框架的要求，其中包括实践、要求 ID、成熟度级别、要求标题以及实施该实践给组织带来的相关收益。由于工具是一个核心组件，并符合各种要求和成熟度级别，指南还提供了工具的可用性和建议，其中包括现有的免费工具、微软提供的工具以及微软正在开发的拟议工具。

S2C2F 指南是对供应链安全对话的有益补充，微软对 OpenSSF 框架的贡献表明了微软对开放源码软件社区和帮助业界解决这一问题的承诺。

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），帮助管理和推动组织在其生产的软件中使用开放源码软件，以及开放源码软件的消费者。

7.10 开放源码安全基金会评分卡

每个人都知道Marc Andreessen在十多年前提出的“软件正在吞噬世界”(https://a16z.com/2011/08/20/why-softw-is-eating-the-world)。软件几乎为现代社会的方方面面提供了动力，无论是个人还是职业，它对现代经济甚至国家安全都至关重要——这是毋庸置疑的。考虑到这一现实，也可以说OSS已经吞噬了软件行业。据Linux基金会等组织估计，自由和开源软件(FOSS)构成了任何现代软件解决方案或产品的70%到90% (www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-opensource-software-application-libraries-the-world-depends-on)。

现代软件不仅主要由OSS组件组成，而且IT领导者也更有可能与那些也为OSS社区做出贡献的供应商合作(www.redhat.com/en/enterprise-open-source-report/2022)。 大量使用OSS的原因有很多，比如灵活性、成本节约、通过社区支持的项目进行的创新，以及通过审查代码和在代码上拥有更多“眼球”的能力而获得的更好的安全性，特别是对于大型OSS项目。也就是说，OSS并非没有自己的担忧，包括受影响代码的漏洞和cve。CVE是MITRE的一个项目，致力于“识别、定义和编目公开披露的网络安全漏洞”(cve.mitre.org)。

然而，正如CNCF软件供应链最佳实践白皮书所指出的那样，cve是一个“跟踪度量”，这意味着cve是已公开披露的漏洞的枚举。它们也是与软件相关的潜在风险和漏洞之一。出于这个原因，建议组织使用其他方法来评估他们正在使用的特定OSS项目的安全状态，其中最值得注意的是OpenSSF的Scorecard项目(http://openssf.org)，我们将在下面讨论它。

开源项目的安全记分卡

在2020年底，OpenSSF宣布了他们的项目“记分卡”，该项目旨在为OSS项目自动生成安全评分，以帮助消费者和组织对其OSS消费做出风险知情的决策。 组织正在大量使用OSS依赖项，但是确定消耗这些依赖项的风险在很大程度上仍然是一项手工活动，特别是在跨软件生态系统的规模上。Scorecard项目试图使用他们的自动启发式和安全检查来减轻一些负担，评分范围为0-10(参见图7.13)。

名称 描述 风险等级
二元属性 项目是否不包含签入的二进制文件? 高
分支保护 项目是否使用分支保护? 高
CI测试 项目是否在CI中运行测试，例如GitHubActions,Prow? 低
CL-最佳实践 项目是否有CI最佳实践徽章? 低
代码复查 在合并代码之前，项目是否需要对代码进行审查? 高
贡献者 项目是否有来自至少两个不同组织的贡献者? 低
危险工作流 项目是否避免了GitHub Action工作流中的危险编码模式? 被批评的
依赖更新工具 项目是否使用工具来帮助更新其依赖项? 高
模糊 项目是否使用模糊化工具，例如OSS-Fuzz? 中等
许可证 项目是否声明许可证? 低
维护 项目是否维护了? 高
固定依赖 项目是否声明固定依赖项? 中等
包装 项目是否从CI/CD构建和发布官方软件包，例如GitHub发布? 中等
SAST 项目是否使用静态代码分析工具，例如CodeQL、LGTM、SonarCloud? 中等
安全政策 项目是否包含安全策略? 中等
符号释放 项目是否对发布进行加密签名? 高
Token允许 项目是否将GitHub工作流令牌声明为只读? 高
漏洞 项目是否存在未修复的漏洞?使用OSV服务。 高
表7.13

计分卡项目的目标也不低;他们根据直接依赖关系扫描一百万个最关键的OSS项目，并每周将结果发布到公共数据集中。除了利用这个公开可用的数据集，组织还可以通过使用GitHub Actions对自己的GitHub项目运行记分卡。然后，当存储库中有变化时，GitHub Actions会运行并向这些项目的维护者提供警报。

Scorecard项目使用Critical、High、Medium和Low的评分等级，这是许多安全从业人员所熟悉的严重级别。Scorecard项目运行一个针对所有项目的标准检查列表，无论是公共项目还是您在自己的GitHub存储库中本地使用它。对于那些感兴趣的人，你可以深入了解其中一些分支是什么。它们包括基本的安全实践，例如使用分支保护和对发布进行加密签名。

为了检测未修复漏洞的存在，计分卡项目使用OSV漏洞数据库(http://osv.dev)，采用OpenSSF OSV格式的开源软件分布式漏洞数据库。OSV的核心是图7.13中使用OSV模式的其他漏洞数据库的聚合，例如GitHub安全咨询和全球安全数据库等。

OSC还支持api和命令行界面(CLI)工具，用于扫描CycloneDX或SPDX格式的soms，我们在第3章“漏洞数据库和评分方法”中讨论过。

组织如何使用记分卡项目?

如前所述，组织正在广泛使用OSS。然而，对OSS消费进行尽职调查、治理和风险管理的实践仍处于起步阶段。我们看到了支持软件供应链弹性和成熟组织软件供应链安全实践的巨大推动，NIST的系统和组织网络安全供应链风险管理实践，NIST的SSDF, OpenSSF OSS安全动员计划，SLSA，以及许多其他最佳实践和指导来源已经出现。所有这些都涉及到管理组织对OSS的消耗，并确保这种消耗与组织的风险容忍度保持一致的需要。

虽然表面上听起来很简单，但是在整个健壮的OSS项目和组织正在使用的组件的生态系统中这样做的想法并不是那么微不足道。OpenSSF的Scorecard项目提供了一种自动化的方式来获取超过100万个领先的OSS项目的安全和风险洞察，并允许组织将该项目原生地用于他们自己的软件和项目。

组织可以通过CLI对他们不拥有的项目使用记分卡，也可以对npm、PyPi或RubyGems等项目使用包管理器。 Scorecard也可以作为Docker容器使用，也可以通过这个路径进行部署。

计分卡项目每两周开一次会，并且有一个活跃的Slack频道。它由来自谷歌、Datto和思科等公司的推动者领导。自成立以来，Scorecard越来越受欢迎，并被列为有超过3000名Stargazers或用户，他们已将该项目加入书签。随着组织继续推动其OSS消费治理实践的成熟，该项目将不可避免地越来越受欢迎。组织和个人贡献者也有机会参与项目，包括提交用于评分评估的检查。组织还可以定制他们对Scorecard的使用，并只运行可能与组织或行业特定安全需求相一致的特定检查。

Scorecard提供了一种关键的功能，可以自动执行一组健壮的评估标准，对于组织来说，无论是在他们正在使用的公共项目上，还是在他们想要评估的内部项目上，手动执行这些标准是不切实际的。众所周知，尽管开源软件带来了价值和创新，但大多数自由/开源软件项目人员不足，并且由无偿的志愿贡献者领导。

这并不是说组织不应该利用OSS项目，而是说他们应该对他们所使用的项目和这些项目所带来的风险有一些严格的要求。Scorecard项目以易于使用的方式完全满足了这种需求。它在评估OSS项目的安全问题时完成了所有这些工作，这些安全问题与最佳实践(如签名、SAST等)保持一致，这些都是公共和私人安全领导者已经提倡的。

7.11未来之路

虽然开源软件提供了巨大的好处，但许多关注和研究发现，自由/开源软件开发人员在很大程度上没有优先考虑安全性。Linux基金会的OpenSSF和哈佛大学创新科学实验室的一项研究发现，自由/开源软件开发人员平均只花大约2.3%的时间来提高代码的安全性(www.darkreading.com/applicationsecurity/open-source-developers-still-not-interested-in-secure-coding)。

这保证了使用OSS组件的组织采取各种措施，例如在使用之前审查OSS组件，并使用soms来了解与他们的OSS消费相关的漏洞以及这些组件在企业中的位置，因此他们能够更好地响应下一个Log4j类型的情况。

为了获得更具体的指导，组织可以参考NIST的开源软件控制推荐实践，该实践是根据网络安全行政命令(EO) 14028发布的，改善国家网络安全(www.nist.gov/itl/executive-order-14028-improvingnations-cybersecurity/software-security-supply-chains-open)。
这些包括基于组织成熟度的分层能力:基础的、持续的和增强的。在这些层中有一些功能，例如使用SCA源代码审查来识别易受攻击的组件，优先使用带有内置护栏的编程语言，以及在将OSS组件引入生产环境之前，将收集、存储和扫描OSS组件到加固的内部存储库的过程自动化。

现在应该很明显，安全使用OSS或任何软件都没有灵丹妙药或银弹。也就是说，通过人员、流程和技术的正确组合，按照这个顺序，组织可以获得OSS的好处，同时降低使用OSS的风险。

7.12 总结

在本章中，我们讨论了现有的和新兴的软件供应链安全指南。这包括SLSA的努力以及来自微软、CNCF和其他机构的资源。在下一章中，我们将讨论来自政府实体的现有和新出现的指导意见。