4.5 将 SBOM 与其他证明结合使用

SBOM 只是一种证明；它是一份包含其内部声明证据的文件。它通过附加到这些声明上的加密验证的质量和真实性得以强化。因此，通过数字签名将 SBOM 连接在一起的概念变得可行，这使得即使是不完整的 SBOM 也能提供价值，因为它们可以与其他 SBOM 结合，每个额外的证明为第一个 SBOM 增加保证信息。然而，我们希望探索其他一些可以与 SBOM 一起包含的证明类型，以构建完整的证据包。

来源真实性

来源真实性是 NERC CIP 合规性要求（CIP 010 和 013）重点关注的一个概念，其理念是您可以使用文件哈希或代码签名材料验证文件本身，但同样重要的是验证对文件来源的信任。它试图回答诸如文件来自哪里？它是受信任的实体吗？它是我们认为的同一个实体吗？该实体是否以某种意想不到的方式受到损害或修改？

解决方案提供商开始解决此问题的一些常见方法是查看与检索软件文件的 Web 域相关联的传输层安全性 (TLS) 证书信息，并确保证书有效，同时确保证书受信任。它是否有合理的有效期？它最近是否以不寻常的方式发生变化？公司名称是否符合预期？也许昨天是 Microsoft Corp.，但今天是 Microsoft, Inc.。这可能是需要调查的事情。最重要的是，创建正常基线和识别异常有助于组织识别来源的真实性或试图破坏它的行为。

DNS 信息是可能需要验证的其他信息。域名是否已更改为一组新的 IP 地址或地理定位到世界不同地区？对于可能根据互联网健康状况或请求者位置为来自世界各地的流量提供服务的内容交付网络 (CDN)，很难以高度的信心进行探索。有些人甚至提出，互联网路由劫持（例如多年来发生的 BGP 劫持）可用于提供恶意文件。这也变得非常难以验证，但这些场景对于威胁模型来说相当有趣。

通过根据这些标准进行检查并生成可以加密绑定到正在生成的 SBOM 的证明文件，我们可以进一步丰富 SBOM 中已经包含的出处数据。

构建证明

关于构建环境的证明对于增强软件工件的保证也非常有用。这些可以包括有关构建系统本身的信息，甚至可以验证构建活动中使用的流程或控制。

考虑一下，在软件工件供应链级别 (SLSA) 框架中，攻击目标之一是构建系统。如果攻击者可以破坏构建系统，您如何信任在该服务器上构建的任何东西？理想情况下，构建服务器与生产服务器正确隔离，并作为极其敏感的资产进行适当强化。验证服务器是否符合强化指南，例如安全技术实施指南 (STIG)，它们是安全模板，可提供额外的保证，确保构建服务器不太可能成为入侵源。有些供应链供应商（例如 TestifySec）将这些证明用作其自动化的一部分，甚至可以应用构建策略，要求通过 STIG 检查才能成功构建。

同样，您可能已经实施了一些流程，例如需要多个开发人员同意代码签入，然后才能继续构建。这些构建证明可以捕获上游流程所需的任意数量的安全要求，以用作构建流程的安全门，以及可用于验证高保证软件构建的证明。支持这一点的工具的一个例子是 OSS 项目“Witness”，它有助于创建证明并执行策略以确保软件供应链的完整性。（www.testifysec.com/blog/attestations-with-witness）

依赖管理和验证

随着开发人员对来自外部来源的软件组件的使用不断增加，管理这些库、包、组件或依赖项（通常称为依赖项）的需求也随之增加。正如我们所讨论的，依赖项通常被集成以节省开发人员和组织的时间和资源，并加快上市/任务的时间并加速创新。不可避免的现实是，您使用的依赖项越多，您必须管理的依赖项就越多。

依赖项通常在两种情况下讨论，即直接依赖项或传递依赖项。顾名思义，直接依赖项是您的应用程序直接引用和使用的组件。传递依赖项是您的依赖项本身使用的组件，从而创建了对依赖项的依赖关系。这两种类型的依赖项都有其相关的风险和注意事项。虽然好处很多，但随着直接或传递依赖项数量的增加，潜在风险也在增加。当然，其中包括许可问题，但从安全角度来看，它们还包括漏洞、恶意代码和攻击媒介的可能性。

Endor Labs 的《依赖管理现状》等报告指出了这一点。报告发现，95% 的漏洞存在于传递依赖项中，这增加了开发人员评估和解决的难度。此外，还有一项发现，50% 的最受欢迎的软件包在 2022 年没有发布，30% 的软件包的最新版本在 2018 年之前，导致代码陈旧且可能存在漏洞 (www.endorlabs.com/blog/introducing-the-state-of-dependency-management-report)。

使用许多依赖项还存在管理开销方面的挑战。开发社区本身使用了一个可爱的术语“依赖地狱”，因为安装依赖于其他特定版本软件包的软件包会带来挫败感。问题是由于多个软件包依赖于相同的共享组件但版本不同或存在兼容性问题的情况而发生的。

每个依赖项或组件都有其问题。包括库被废弃且未被维护、代码编写不当、没有文档，当然还有易受攻击的代码，如果维护人员仍然存在或目前是项目的积极参与者，他们可能会或可能不会修复这些代码。

话虽如此，组织可以采取一些最佳实践来减轻与依赖项管理相关的一些挑战和风险。这些建议包括确定哪些依赖项必须先于其他依赖项更新，使用诸如对项目的关键性或安全风险等因素。另一个建议，当然，说起来容易做起来难，是通过完全删除来最小化未使用的依赖项，只保留代码中需要的依赖项。不这样做会导致代码臃肿、攻击面增加和管理开销挑战。在许多情况下，您还可以自动更新软件依赖项，从而最大限度地减少与依赖项管理相关的手动工作量。在这种情况下，最受欢迎的示例之一是 Dependabot，它有助于自动更新各种编程语言（如 Ruby、JavaScript、Python 和其他几种语言）的依赖项。 Dependabot 得到了 GitHub 和 GitLab 等最大的持续集成平台的支持。

除了自动化之外，组织还应制定软件依赖关系管理策略。为组织的开发人员制定依赖关系管理指南可以确保整个组织遵循标准化方法，并可以实施治理，如 Microsoft 的 S2C2F 或 NIST 的软件供应链指南等框架中所述，我们将在第 6 章“云和容器化”中介绍。制定标准化的政策和流程有助于监控安全问题、提高应用程序性能和确保许可合规性。

软件依赖关系不会消失，而且整个行业对软件包、库和组件的大规模重用只会加速。这不可避免地导致需要适当的软件依赖关系管理和验证流程。未能实施结构化方法将导致安全风险得不到解决，从而给开发团队带来负担，这可能会阻碍交付并为许可违规敞开大门。

Sigstore

软件供应链安全的一个基本方面涉及对完整性、透明度和保证的需求。这就是 Sigstore 发挥作用的地方。正如本书中提到的那样，我们看到了对软件供应链的极大关注，尤其是在 SolarWinds 和 Log4j 等重大事件之后。NIST 在其网络安全供应链风险管理 (C-SCRM) 800-161 文档以及 CISA 中发布了网络安全 EO 和更新指南。我们还看到了白宫的关注，白宫于 2022 年初主办了软件供应链安全峰会。在那次峰会之后，Linux 基金会和 OpenSSF 发布了 OSS 安全动员计划，该计划的重点是使用数字签名来增强对软件供应链的信任。这项任务主要集中在采用和发展一种名为 Sigstore 的技术上。

Sigstore 是用于签名、验证和保护软件的标准。正如我们所讨论的，软件的使用在每个垂直行业和业务类别中都无处不在。然而，尽管我们使用软件的方式已经并正在改变世界，但确保我们在整个生态系统中使用的软件具有通常所需的完整性水平的方法却很少。软件供应链通常缺乏数字签名的使用，而当它没有使用数字签名时，它通常使用传统的数字签名技术，而这些技术在自动化、扩展和审计方面可能具有挑战性。

Sigstore 最初于 2021 年 3 月由 Red Hat 和 Google 合作发布，并作为 Linux 基金会的一个项目发布，旨在解决软件来源或构建方式的问题。Sigstore 特别致力于改善软件供应链的完整性和验证活动。

正如 Sigstore 联合创始人 Dan Lorenc 所说，Sigstore 是“为软件开发人员提供的免费签名服务，通过轻松采用由透明日志技术支持的加密软件签名来提高软件供应链的安全性。”正如 Sigstore 项目创始人、Red Hat 的 Luke Hinds 在博客“Sigstore 介绍”(https://next.redhat.com/2021/03/09/introducing-sigstore-software-signing-for-the-masses) 中所写，该项目基于一些真实的假设，例如很少有项目实施代码签名，以及密钥管理是一项困难的活动。从那时起，该小组问了自己一系列“如果”问题，例如“如果密钥不需要撤销或存储会怎样？”以及“如果所有签名事件都在安全媒介上公开，会怎样？”

采用

自推出以来，Sigstore 的行业采用率和兴趣度不断提高。尽管 Sigstore 是在 2021 年初才发布的，但它已经引起了一些最大的 OSS 项目的关注，其中之一就是 Kubernetes 项目。Kubernetes 是市场上规模最大、采用最广泛的容器编排平台。它宣布将以 Sigstore 为标准，并在其 1.24 版本中使用 Sigstore (https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73)。这使 Kubernetes 的消费者能够确保他们使用的发行版是用于消费的。除了这一认可之外，如前所述，OpenSSF 的 OSS 安全动员计划有一个专门用于数字签名的部分，重点关注采用和使用 Sigstore 作为软件供应链完整性缺口的解决方案。 2022 年初，Sonatype 宣布 Maven Central 将采用 Sigstore 作为解决软件供应链中出处问题的解决方案 (https://blog.sonatype.com/maven-central-and-sigstore)

Sigstore 组件

那么，Sigstore 到底是什么？它是如何工作的？为什么它很重要？Sigstore 的成立是为了帮助解决 OSS 供应链中现有的一些空白，以及我们如何处理完整性、数字签名和 OSS 组件的真实性验证。这至关重要，因为据估计，90% 的 IT 领导者都在使用 OSS（请参阅 www.soocial.com/open-source-adoption-statistics），组织优先考虑聘用 OSS 人才，而且我们已经看到了几起值得注意的软件供应链事件。Sigstore 汇集了多种 OSS 工具，如 Fulcio、Cosign 和 Rekor，以协助进行数字签名、验证和代码来源检查。代码来源是指拥有一条保管链的能力，显示代码的来源和来源。 Uber 隐私和安全团队在 https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5 上发表了一篇精彩的博客，讨论了他们如何处理代码来源路径。

要解压一些核心 Sigstore 组件，让我们从 Fulcio (https://github.com/sigstore/fulcio) 开始。Fulcio 是一个专注于代码签名的根证书颁发机构 (CA)。它是免费的，颁发与 OpenID Connect (OIDC) 相关的认证，并且经常使用开发人员已经关联的现有标识符。随着云原生架构和容器部署的快速采用和增长，对容器进行签名已成为一项关键的安全最佳实践 (www.csoonline.com/article/3656702/managing-container-vulnerability-risks-tools-and-best-practices.html)。密钥管理是一项繁琐的活动，通常由 CSP 或第三方提供商在云空间中作为托管服务提供。 Sigstore 通过支持 Cosign 的方式帮助缓解部分复杂性，并通过使用“无密钥签名”或使用临时密钥或临时密钥缓解部分密钥管理挑战（www.chainguard.dev/unchained/zero-friction-keyless-signing-with-kubernetes#:~:text=Keyless%20enables%20this%20signing%20process,Let's%20Encrypt%20did%20for%20TLS）。尽管使用了临时密钥，您仍然可以通过 Fulcio 的时间戳服务确保签名的有效性（www.chainguar.dev/unchained/busting-5-sigstore- myths）。

这就是 Cosign 的作用所在，因为它支持各种签名选项，并且可以无缝支持生成密钥对和签名容器工件以存储在容器注册表中。它使云原生环境能够根据公钥验证容器，并确保容器由受信任的来源签名。在构建期间对映像工件进行数字签名并验证这些签名是云原生计算基金会 (CNCF) 云原生安全白皮书 (https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) 中强调的一项关键安全最佳实践。

接下来是 Rekor (https://docs.sigstore.dev/rekor/overview)，它是一个不可变且防篡改的账本，是软件维护和构建活动的一部分。它使软件消费者能够检查元数据并对他们正在使用的软件及其整个生命周期中涉及的活动做出风险知情决策。回到我们之前关于软件来源的观点，开发人员可以使用 Rekor 通过透明日志为软件来源做出贡献。

另一个值得注意的方向是新兴的指南，例如软件制品的供应链等级（SLSA；https://slsa.dev/spec/v0.1/levels）和 NIST 安全软件开发框架（SSDF）（https://csrc.nist.gov/publications/detail/sp/800-218/final）。SLSA 第 3 级强调需要审计软件来源和完整性，这一点 Sigstore 支持，如前所述。SSDF 中提到的具体实践也指出了提供来源和验证机制的必要性。这很重要，因为联邦政府正逐步要求向政府销售软件的生产商按照 SSDF 中的实践进行证明（www.nextgov.com/cybersecurity/2022/02/nist-suggests-agencies-accept-word-software-producers-executive-order/361644）。通过采用 Sigstore，您可以使您的组织与这里讨论的新兴标准和最佳实践保持一致，并减轻可能导致安全事件及相关影响的关键软件供应链风险。

提交签名

在现代源代码管理中，Git 通常是事实上的选择系统。Git 允许各种实体（如作者和提交者）提交提议的更改。通常，这些实体是同一个人，但并非总是如此。也就是说，在许多情况下，通过设置用户名或电子邮件，冒充另一个提交者可能很简单。因此，特别是在敏感环境中，签署 Git 提交已成为一种最佳实践，这确保了你可以证明你是某段代码及其元数据（如时间戳）的作者。签名的提交虽然不能解决所有问题，但可以减轻一些潜在风险，例如前雇员试图通过冒充同事引入恶意代码或创建恶意拉取请求，而假身份有良好声誉。

签名提交不能阻止恶意行为者冒充他人，因为他们仍然可以尝试假冒身份，但没有数字签名将迅速引起那些足够关注的人的怀疑。

Git 通常使用 GNU Privacy Guard（GPG）等方法来促进签名提交。GPG 在 Git 中的工作原理是允许你将公钥上传到流行的 Git 平台（如 GitHub 和 GitLab），然后使用你的私钥签署提交。GitHub 提供了管理提交签名和签名提交的文档（https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits）。

SBOM 的批评和关注

如果我们不讨论一些在整个行业中 SBOM 采用过程中的常见批评、关注和挑战，我们将是不负责任的。

这些关注中最集中的来源之一是 NTIA 发布的 SBOM FAQ(www.ntia.doc.gov/files/ntia/publications/sbom_faq_-_fork_for_october_22_meeting.pdf)中的“常见误解与关注”部分，但其他行业的其他人也通过各种渠道提出了此类关注。

让我们来看看 NTIA 文件中列出的常见误解和担忧，以及其他一些误解和担忧.

攻击者的可见性

围绕 SBOM 的一个担忧是它们可能作为“攻击者的路线图”，这是它们常被提及的。这可以更广泛地描绘为围绕通过模糊性提供安全的辩论，这在网络安全行业已经持续了一段时间，双方都有合理的观点。通过模糊性提供安全通常总结为通过保密作为提供系统或组件安全的主要方法，而不是具体的安全控制和合理的安全工程。我们可以引用长期行业思想领袖 Daniel Miessler 的观点，他区分了良好的模糊性与糟糕的模糊性，指出“判断模糊性是好是坏的关键在于它是作为良好安全的层次使用，还是作为其替代品使用。前者是好的，后者是坏的。”（https://danielmiessler.com/study/security-by-obscurity）
  Miessler 的观点是，保密在某些情况下肯定是有益的，但它不是合理安全工程的替代品。行业中的其他人认为 SBOM 可用于攻击 API，例如 Dan Epp 在其博客中所讨论的“Can SBOM Help You Attack APIs?”（https://danaepp.com/can-sbom-help-you-attack-apis）但即便如此，该文章也指出 SBOM 帮助防御者了解它们是否易受攻击以及在何处，这比进攻方面的担忧更重要，因为攻击者无论有无 SBOM 都会不可避免地寻找这些弱点。
  针对 SBOM 是否为“攻击者的路线图”的问题，NTIA 指出，恶意行为者不需要 SBOM，因为事先了解不是攻击的前提条件。NTIA 还指出，恶意行为者已经有工具来识别软件组件，不受法律约束，因此可以这样做，而不像守法的道德用户。NTIA 声明，SBOM 将“拉平竞争环境”，为防御者提供他们已经拥有的同样的见解和透明度。恶意行为者能够使用二进制分析工具来理解软件组成和组件组成。虽然这点没有争议，但拥有 SBOM 将使软件消费者更好地理解与其使用的软件相关的初始风险，以及现有和新出现的漏洞。通过这样做，SBOM 帮助防御者了解风险并采取适当行动。

知识产权

围绕 SBOM 讨论的另一个常见担忧是知识产权和源代码。NTIA 反驳了这一点，指出 SBOM 不要求组织披露源代码，源代码是否共享由软件提供商自行决定。SBOM 专注于构建软件的组件，而不是披露源代码本身。软件组件代表部分情况，但不是软件实际运行的完整路线图。NTIA 的指南指出，了解第三方成分和整个执行配方之间存在显著差异，此外第三方组件不属于使用它们的软件供应商的知识产权，而是属于创建这些组件的上游实体，并受其创建时分配的任何适当许可证的约束。值得指出的是，尽管推动增加 SBOM 采用，但所有相关来源都建议适当保护 SBOM 本身，符合最低特权访问控制和知情即需的最佳实践。像 OMB 的 22-18 备忘录这样的来源，要求联邦机构可能需要从软件供应商获取像 SBOM 这样的工件，也要求机构在这些工件未公开发布时安全地存储它们。

工具和运营化

围绕广泛采用 SBOM 最有效的担忧之一是缺乏广泛可用的工具来促进创建、分发、摄取、丰富、分析和运营化 SBOM。现在许多人同意有足够的工具来帮助创建 SBOM，并且我们在整本书中多次提到它们。然而，撰写本文时，用于处理附加活动（如分发、摄取、丰富和分析）的工具仍在成熟中。如前所述，国土安全部（DHS）和网络安全基础设施安全局（CISA）等组织正在努力创新这一领域，以及商业领域，我们看到一系列商业公司正在进行研发投资和产品以填补这一空白。值得注意的例子包括 ChainGuard，该公司由前 Google 工程师创立，在 2022 年筹集了 5000 万美元。其他值得注意的例子包括 Endor Labs、TestifySec 和其他几家公司，包括行业领导者 Google，他们正在为组织提供帮助管理其 OSS 摄取和使用的创新软件供应链重点管理服务。再次引用美国联邦领域，OMB 的 22-18 备忘录还要求政府“建立一个集中存储库，用于软件证明和工件”，其中将包括 SBOM。
  虽然围绕 SBOM 的担忧（如对攻击者的可见性、知识产权、工具和能力的成熟度）可能是有效的，但作为一个行业，我们普遍同意，透明度的推动及其带来的好处超过了这些担忧。这并不是说这些担忧完全没有价值，不应该被解决，但继续走不透明的软件生态系统的道路，无法了解底层软件组件及其相关风险和漏洞已不再可行。