软件物料清单（SBOM）

软件物料清单（SBOM）是软件中每个组件的正式、机器可读清单，包括库、库的版本、许可证和供应商信息。

正如食品标签会列出配料一样，SBOM 让您可以在几秒钟内回答：该产品是否包含 X 的易受攻击版本？没有 SBOM，这个问题可能需要数天的人工考查。

当一个严重漏洞出现时，运营层面的第一个问题就是暴露情况：我们的哪些产品交付了受影响的组件？

在 Log4Shell 事件期间，拥有 SBOM 的组织可以查询其清单，并在数小时内完成分诊。没有 SBOM 的组织则花费数周搜索构建目录。监管机构和大型采购方越来越多地将 SBOM 作为采购条件。

• 快速分析漏洞影响
• 许可证合规与义务跟踪
• 为客户和审计人员提供供应链透明度

目前有两种开放标准占据主导地位。工具通常可以在两者之间进行转换。

• SPDX——Linux 基金会标准，在许可证方面功能强大，并得到监管机构广泛认可
• CycloneDX——OWASP 标准，专注于安全性，支持漏洞和依赖关系数据

请避免自行发明格式；使用者和扫描工具都期待这些标准。

每个组件条目都应包含足够的身份信息，以便与漏洞信息源进行匹配。关键字段包括：

• 名称和版本——必须精确，而不是范围
• PURL（软件包地址）——一种通用标识符，例如 pkg:npm/lodash@4.17.21
• 哈希值——用于验证完整性
• 许可证——SPDX 许可证标识符
• 供应商——组件的生产者

可以从源代码或构建产物中自动生成 SBOM。Syft 是一种常用的跨生态系统生成工具，可以输出这两种标准。

在不同阶段生成的 SBOM 记录的是不同层面的事实。

• 源代码 SBOM——清单声明的内容；可能遗漏打包或内置的代码
• 构建 SBOM——构建实际引入的内容；对发布版本而言最准确
• 运行时/已部署 SBOM——运行中映像实际包含的内容，包括 OS 软件包

为了保证供应链安全，应在构建时从真实构建产物生成 SBOM，并扫描最终容器中的 OS 级软件包。

将 SBOM 提供给能把组件映射到已知 CVE 的匹配工具后，它才会真正发挥作用。这样可以将生成与分析解耦：在新的 CVE 发布当天扫描旧的 SBOM。

SBOM 可能显示某个易受攻击的组件，但该组件在您的产品中实际上无法被利用（因为易受攻击的函数从未被调用）。VEX（漏洞可利用性 eXchange）文档会记录这项评估。

VEX 可以减少噪声：您不必让每位客户都因列出的 CVE 而恐慌，而是可以发布带有理由的 not_affected 声明，或发布带有补救措施的 affected 声明。它将原始清单转化为可采取行动的分诊依据。

只有在 SBOM 真实可信，并且与其描述的确切构建产物绑定时，它才值得信任。请对其进行签名，并将其作为证明声明附加，而不是作为单独文件存放。

手动维护的 SBOM 会立即过时。请将生成过程接入流水线，使每个发布版本都生成并存储一个 SBOM，最好在同一作业中完成签名和扫描。

• 从构建产物生成，而不只是从代码库生成
• 将 SBOM 存储在可查询的注册表中，并以版本作为键
• 按计划根据最新的 CVE 信息源重新扫描已存储的 SBOM
• 根据漏洞扫描结果控制发布

如果把 SBOM 当成打勾即可完成的事项，它就会在不知不觉中失效。

• 过时——只生成一次，之后从未重新生成
• 不完整——遗漏 OS 软件包、静态链接的代码或内置代码
• 未验证——没有将其与已部署构建产物关联起来的哈希值
• 未使用——已经生成，却从未扫描或查询

目标是获得准确、重新生成、已签名并持续扫描的 SBOM，而不是一次性的 JSON 文件。

现在，您可以清点软件包含的内容，并据此采取行动。

• SBOM 是一份机器可读的组件清单，格式为 SPDX 或 CycloneDX
• 使用PURL、版本、哈希值和许可证识别组件
• 在构建时生成，然后将其提供给匹配工具（grype、osv-scanner）以查找 CVE
• 使用VEX声明实际可利用性，减少误报
• 在持续集成中签名并自动化；根据新的信息源重新扫描已存储的 SBOM

下一步：通过签名证明构建产物的来源。