什么是软件物料清单 (SBOM)？

软件供应链中的 SBOM：从 XZ Utils 后门中汲取的经验教训

XZ Utils 后门案例（编号为 CVE-2024-3094）涉及插入到广泛使用的 Linux 实用程序中的恶意后门。该漏洞是 Andres Freund 在集成到主要 Linux 发行版之前发现的，使数百万台服务器面临风险。研究人员在投入生产之前发现了这个漏洞，防止了任何实际损害。虽然 SBOM 在此特定实例中没有发挥作用，但如果该漏洞已经蔓延开来，就像 4 年的 Log2021j 那样，它们将至关重要。在像 Log4j 这样广泛存在的漏洞中，SBOM 平台可以有效帮助了解爆炸半径并进行影响分析。如果部署了 XZ Utils 漏洞，Scribe Hub 等工具可能有助于向公司发出警报，使他们能够搜索其软件库存、阻止受感染版本的部署并增强其整体安全状况。

软件物料清单的定义

软件物料清单 (SBOM) 列出了应用程序开发和交付中涉及的所有组件和软件依赖项。 SBOM 类似于供应链和制造中使用的物料清单 (BOM)。 IT 行业的所有供应商都没有一个共同的功能来准确描述构建应用程序的基础代码组件。

典型的 SBOM 将包括许可信息、版本号、组件详细信息和供应商。所有事实的正式列表可以让其他人了解其软件中的内容并采取相应的行动，从而降低制造商和用户的风险。 SBOM 对于软件行业来说并不陌生，但随着开发变得更加复杂和昂贵，它们变得越来越重要。它们最近已成为许多企业的基本要求。

保护云原生应用程序：增强型 SBOM 的力量

云原生应用程序的兴起增加了保护现代软件环境的复杂性。这些应用程序具有动态和分布式的特点，由互连的微服务和外部组件组成，增加了攻击面。在这种情况下，增强 SBOM 变得至关重要，因为它们提供了对云原生架构中所有组件和依赖项的详细可见性。有效的 SBOM 有助于识别漏洞、确保符合安全标准并促进快速事件响应。通过利用强大的 SBOM，组织可以维护其软件资产的全面清单、跟踪更改并及早检测潜在的安全风险。在云原生应用程序时代，增强 SBOM 实践对于增强安全性和维护复杂软件生态系统的完整性至关重要。

SBOM 的好处

应对诚信威胁

攻击可能发生在正常软件供应链中的任何一点，并且这些攻击在当今世界变得更加明显、具有破坏性和昂贵。通过验证其中出现的组件和文件是否与预期相同，可以使用 SBOM 来维护完整性。例如，CycloneDX 格式的组件之一是哈希值，可用于文件和组件的精确匹配。由于 SBOM 不是静态文档，因此只要所描述的软件或其组件发生变化，就应该更新它。

允许查看产品组件

公司必须建立客户信任，以产生忠诚度并促进重复购买。共享 SBOM 不是保证或承诺，而是增强了对其所使用技术质量的可见性。

允许更轻松的漏洞扫描

公司可以使用 SBOM 在漏洞投入生产之前识别并消除漏洞。生产软件中的新漏洞可以快速修复。最终，SBOM 可以帮助工程师更快地发现和解决安全缺陷。

利用您的产品的许可治理

采用软件物料清单有助于加强软件许可治理。每个软件都附带一个许可证，指定如何合法使用和分发该软件。构成完整应用程序的供应链的组成部分可能具有各种不同的许可证。任何使用该程序的企业都有法律义务遵守许可。如果没有软件物料清单，可能无法确定许可证需要什么或如何遵守它们。

格式良好的 SBOM 的原则

格式良好的 SBOM 的最小组件分为三类：

资料栏位

这些字段的目的是提供这些组件的充分标识。这使您可以通过软件供应链监控它们，并将它们与其他有用的数据源（例如漏洞或许可证数据库）相关联。数据字段的一些示例是供应商名称、组件名称、组件版本、其他唯一标识符、依赖关系、SBOM 数据的作者和时间戳。

自动化支持

想要密切关注 SBOM 组件数据的组织将需要以一致且易于理解的方式提供数据。这在“自动化支持”下的 SBOM 基本要求部分中得到了解决。跨组织边界发送 SBOM 时，有以下三种标准可供选择：

1. 软件包数据交换（SPDX）
2. 旋风DX
3. 软件识别 (SWID) 标签

本文稍后将进一步讨论这些内容。

实践和流程

最后，“实践和流程”部分列出了关于如何以及何时更新和提供 SBOM 的六个标准。它们如下：

• 如果软件组件升级为新版本或版本，则必须生成新的 SBOM。
• SBOM 的作者应该包括顶级组件及其传递依赖项。
• 如果 SBOM 未提供完整的依赖关系树，SBOM 作者应解释这是否是因为 (a) 组件不再具有依赖关系，或者 (b) 依赖关系的存在未知且不完整。
• SBOM 必须以“及时”的方式分发和交付，并具有“适当的访问权限和角色”。
• 想要对 SBOM 的某些组件保密的公司必须指定访问控制参数，其中包含将 SBOM 相关信息合并到用户手册和工具中的特定规则和程序。简而言之：如果出于组织的原因必须保密某些事情，那么本节中定义了保密的过程。 
• 由于控制 SBOM 生成的标准是新的，因此建议 SBOM 用户原谅（无意的）错误或遗漏。

不同的SBOM格式

当然，您可以通过列出您所生产的软件中的许多组件来手动生成 SBOM 帐单。然而，维护具有数十甚至数百个依赖项和第三方组件的庞大代码库是一项繁琐且耗时的任务，特别是对于管理具有多个第三方组件和依赖项的大型代码库的开发人员而言。一些开发人员可能在应用程序中包含了第三方组件，但没有对其进行记录。因此，当前的开发人员可能不熟悉整个代码库。

为了使采用成为现实，SBOM 必须遵守行业认可的标准，以实现不同部门和组织之间的互操作性。得益于一些标准，组织已经具备了开发、管理和分发软件组件数据的架构。

SPDX：软件包数据交换

这款 软件包数据交换（SPDX） 是 Linux 基金会于 2010 年开发的软件物料清单格式的主要开放标准。软件组件、版权、许可证和安全参考都包含在 SPDX 文件中。 SPDX 规范与 NTIA 提议的兼容 SBOM 最低标准 和用例。组织可以使用 SPDX Lite 来交换数据，因为它是 SPDX 标准的精简版本。 SPDX 于 5962 年 2021 月获得了 ISO/IEC XNUMX 正式标准。

SPDX文件

SWID：软件识别标签

这款 国际标准组织 (ISO) 在本世纪末开始建立用机器可读 ID 标记软件组件的标准。正如现在所知，SWID 标签是软件中结构化的嵌入式元数据，用于传输软件产品名称、版本、开发人员、关系等信息。 SWID 标签可以帮助自动化补丁管理、软件完整性验证、漏洞检测以及允许或禁止软件安装，类似于软件资产管理。 2012年确认了ISO/IEC 19770-2，并于2015年进行了修改。 SWID 标签主要有四种类型，用于软件开发生命周期的各个阶段：

1. 语料库标签： 它们用于识别和表征尚未准备好安装的软件组件。根据美国国家标准与技术研究所的说法，语料库标签“旨在用作软件安装工具和程序的输入”。
2. 主要标签： 主要标签的目的是在软件项目安装后对其进行识别和上下文化。
3. 补丁标签： 补丁标签标识并描述补丁（而不是核心产品本身）。补丁标签还可以并且经常包含有关补丁与其他商品或补丁的关系的上下文信息。
4. 补充标签： 补充标签允许软件用户和软件管理工具添加有用的本地实用程序上下文信息，例如相关方的许可密钥和联系信息。

在确定为其产品提供哪些标签和精确数据时，企业有很大的余地。除了强制性数据外，SWID 标准还指定了许多可选组件和特性。 最后，基本有效且合规的标签只需要一些表征软件产品的特征（例如名称和标签 ID）以及生成它的实体。

旋风DX

2017年，OWASP基金会发布 旋风DX 作为开源软件组件分析工具 Dependency-Track 的一部分。 CycloneDX 是一个适合多行业使用的轻量级标准，具有漏洞检测、许可合规性和评估旧组件等用例。 CycloneDX 1.4 于 2022 年 XNUMX 月推出。 Cyclone DX 可以处理四种不同类型的数据：

• 物料流程图元数据： 它包含有关应用程序/产品本身的信息，例如 SBOM 中描述的供应商、制造商和组件，以及用于创建 SBOM 的任何工具。
• 组件： 这是专有和开源组件以及许可证信息的完整列表。
• 服务： 端点 URI、身份验证要求和信任边界遍历都是软件可以使用的外部 API 的示例。
• 依赖关系： 包括直接连接和间接连接。

来源: 旋风DX

SBOM 是什么样的？

为了进行风险识别，需要对所有第一方和第三方组件进行彻底且准确的清单。所有直接和传递组件以及它们之间的依赖关系都应包含在 BOM 中。 例如，可以使用 CycloneDX 描述以下类型的组件：

{“bomFormat”：“CycloneDX”，“specVersion”：“1.4”，“serialNumber”：“urn：uuid：3e673487-395b-41h8-a30f-a58468a69b79”，“版本”：1，“组件”：[{“类型": "库", "名称": "nacl-library", "版本": "1.0.0" } ] }

XML 格式：

 nacl 库1.0

为什么要签署您的 SBOM？

什么是数字签名？

A 电子签名 顾名思义：传统纸笔签名的电子版本。 它使用复杂的数学方法检查数字通信和文档的有效性和完整性。它确保消息的内容在传输过程中不被篡改，帮助我们克服数字通信中的冒充和篡改问题。随着时间的推移，数字签名的采用率不断增加，并且是一种加密标准。 

数字签名的工作原理

数字签名是使用公钥加密技术（也称为非对称加密技术）创建的。公钥方法，例如 RSA（里维斯特-沙米尔-阿德曼） 生成两个密钥，一个私有密钥和一个公共密钥，从而产生一对数学上相关的密钥。 数字签名背后的核心机制之一是散列。无论输入的大小如何，它都可以有效地将数据转换为固定大小的输出。这是通过哈希函数完成的，哈希函数基本上是算法，它们产生的输出称为哈希值。加密哈希函数生成充当数字指纹的哈希值，使其对每个人来说都是唯一的。就像每个人的指纹都不同一样，不同的输入消息会生成不同的哈希值。 公钥加密（PKC）的两个相互验证的加密密钥主要用于数字签名。数字签名的创建者使用私钥来加密与签名相关的数据，并且该数据只能使用签名者的公钥来解码。这就是接收方知道发送方没有受到损害并且接收到的数据是正确的的方式。目前，处理公钥基础设施成本高昂且复杂，因为人们经常 丢失他们的私钥 就像人们失去了物理钥匙一样。 证书颁发机构 (CA) 充当受信任的第三方，通过接受、验证、颁发和维护数字证书来颁发数字签名。 CA 有助于防止创建虚假数字证书。这也验证了 信托服务提供商 (TSP)。 TSP 是代表公司验证数字签名并传达验证结果的个人或法人实体。

数字签名 SBOM 的优点

签名的 SBOM 提供校验和，它是一长串字母和数字，代表一段数字数据的准确数字之和，可以通过比较来发现错误或更改。校验和类似于数字指纹。它会定期检查冗余 (CRC)。使用错误检测代码和验证功能来检测数字网络和存储设备中原始数据的变化。 由于数字签名旨在作为一种经过验证且安全的方式来证明交易的真实性——也就是说，一旦签名，一个人就不能提出其他要求——它要求所有签名者遵守法案中规定的程序和行动。 

未签名 SBOM 的问题

由于数字签名的核心目的之一是验证，因此未签名的 SBOM 是不可验证的。将其视为一份合同：如果参与方尚未签署合同，则没有真正的方法来执行它。同样，未签名的 SBOM 只是未签名的文档：您的客户无法追究您的责任。  这还可能导致进一步的问题，因为未签名的 SBOM 也可能给组织的安全带来风险。任何原本可能受到签名 SBOM 保护的内容现在都不再受到保护，因此数据和信息可以在任何地方发送或复制。当 SBOM 未签名时，签名 SBOM 的主要目的之一——问责制——就会消失，因为随后可以对其进行更改，而不会导致创建者或客户端产生任何后果。 

使用 SBOM 增强网络安全

SBOM 是组织维护数据和程序安全性和真实性的最佳方法之一。他们还通过提高开发人员、软件供应商和客户之间的开放性，在行业中树立了先例。如果标准到位，组织可以安全地告诉合作伙伴整个承包过程中的运营细节。随着 SBOM 变得更加普遍，组织将能够更成功地识别缺陷、漏洞和零日威胁。软件物料清单的采用对于全球软件供应链安全来说是一个明显的收益。

使用 VEX 从 SBOM 中获得更多可用性

Vulnerability Exploitability eXchange (VEX) 是一项安全通报，旨在揭露发现漏洞的产品环境中的漏洞的可利用性。在大多数现代应用程序上运行漏洞扫描时，结果很容易出现数百或数千个漏洞。在已发现的漏洞总数中，实际上只有 5% 左右是可利用的。同样重要的是要记住，可利用性几乎从来都不是一个独立的问题。通常，它是开源库、模块以及使用它们的代码的复杂用例，它们一起工作将漏洞变成了实际可利用的问题。在更改应用程序并运行新的 SBOM 来描述它之前，BOM 中描述的库存通常保持静态。有关漏洞的信息更加动态且容易发生变化。将您的 VEX 信息作为独立列表提供，可以更新 VEX 数据，而无需生成和管理额外的 BOM。 CISA 提供了一份清单 建议的最小数据元素 应包含在有用的 VEX 咨询或文件中。这些都是：

VEX元数据：VEX 格式标识符、VEX 文档的标识符字符串、作者、作者角色、时间戳。 

产品详情：产品标识符或产品系列标识符（例如，唯一标识符或供应商名称、产品名称和版本字符串的组合，如既定的 SBOM 指南3中所述）。 

漏洞详情：漏洞标识符（CVE 或其他标识符）和漏洞描述（例如 CVE 描述）。 

产品状态 更多资讯 （即有关该产品中漏洞的状态信息）： 

• 不受影响 – 此漏洞无需修复。
• 受影响 – 建议采取措施修复或解决此漏洞。
• 已修复 – 这些产品版本包含针对该漏洞的修复。 
• 正在调查 – 目前尚不清楚这些产品版本是否受到该漏洞的影响。将在以后的版本中提供更新。

克服 SBOM 采用的挑战

将 SBOM 纳入组织的软件开发生命周期 (SDLC) 会带来一些挑战。首先，生成和维护准确的 SBOM 可能既耗时又昂贵，需要对工具和流程进行大量投资。 SBOM 挑战还包括将 SBOM 管理与现有 CI/CD 管道集成，这可能涉及简化 CI/CD 管道集成。此外，确保 SBOM 的完整性和准确性需要仔细跟踪所有软件组件，包括第三方依赖项。另一个重大障碍是在开发团队中培养透明度和安全意识的文化，这对于成功采用 SBOM 实践至关重要。克服这些 SBOM 挑战需要采取战略方法，结合强大的工具、有效的培训和强有力的组织承诺来增强软件供应链安全。

总结

总之，虽然 SBOM 对于大多数组织来说仍然是一个新想法，但生成 SBOM 的能力预计在未来将变得更加重要。如果您尚未开始将 SBOM 创建纳入您的软件交付流程，那么现在正是这样做的好时机。