是什么

SBOM（Software Bill of Materials，软件物料清单）：一份软件中包含的所有组件的结构化清单。

类比：食品的配料表、制造业的 BOM（物料清单）。

通常包含：

  • 每个组件的名称、版本；
  • 供应商/作者；
  • 依赖关系（谁依赖谁）；
  • 许可证信息；
  • 唯一标识符（便于跨系统比对）。

为什么重要

一、漏洞响应

当一个新漏洞公布时（如 Log4Shell），最关键的问题是：

"我们哪些系统用了这个组件？"

没有 SBOM，这个问题可能需要数天到数周去排查——逐个检查代码仓库、构建产物、部署环境。

有了 SBOM，答案可以在几分钟内得到——只需查询清单。

在紧急漏洞响应的时间窗口内，这个差异至关重要。

二、合规要求

越来越多的法规和采购要求 SBOM：

  • 美国行政令 14028（2021）要求向联邦政府供应的软件提供 SBOM；
  • 欧盟《网络韧性法案》（CRA）包含相关要求；
  • 多个行业的采购标准开始纳入。

三、许可证合规

SBOM 中包含许可证信息，便于管理开源许可证的合规风险（如 GPL 的传染性）。

四、供应链透明度

了解你的软件到底由什么构成——包括间接依赖（依赖的依赖）。

主要格式

SPDX（Software Package Data Exchange）：

  • 由 Linux 基金会主导，已成为国际标准（ISO/IEC 5962）；
  • 格式丰富，支持 JSON、YAML、RDF、tag-value 等；
  • 包含许可证信息的标准化表达（SPDX License Identifiers 被广泛使用）。

CycloneDX：

  • 由 OWASP 社区发起；
  • 设计轻量，对安全和供应链用例有良好支持；
  • 支持 JSON、XML；
  • 有 VEX（漏洞可利用性交换）的配套能力。

SWID Tags（ISO/IEC 19770-2）：较老的标准，多用于软件资产管理。

SPDX 和 CycloneDX 是目前的主流，两者可以互相转换。

怎么生成

构建时（推荐）：

  • 从构建系统和依赖清单中直接生成——最准确，因为它反映的是实际的构建产物；
  • 工具：Syft、CycloneDX 的各语言插件、spdx-sbom-generator、以及各包管理器的原生命令（如 npm sbom、pip-licenses）。

从产物扫描：

  • 对容器镜像、二进制文件扫描；
  • 工具：Syft、Trivy、Grype。
  • 优势：能发现构建时清单看不到的内容（如操作系统包、静态链接的库）。

实践建议：两者结合——构建时生成（准确覆盖应用依赖）+ 镜像扫描（覆盖系统层）。

关键实践

一、SBOM 需要更新

软件在演进，SBOM 必须随之更新——否则它只是一份过时的快照。

做法：在 CI/CD 中自动生成，随产物一起存储和分发。

二、SBOM 需要被使用

生成了但没人用，等于没有。

关键：把它接入漏洞管理流程——当新漏洞公布时，自动比对 SBOM，定位受影响的系统。

三、配合 VEX

VEX（Vulnerability Exploitability Exchange，漏洞可利用性交换）：

SBOM 告诉你"有哪些组件"，但一个组件存在漏洞不等于你的系统可被利用（可能该漏洞的代码路径从未被调用）。

VEX 就是用来说明："这个已知的 CVE 在我们的产品中不受影响 / 已修复 / 正在调查 / 受影响"。

这能大幅减少误报噪音——是 SBOM 的重要补充。

现实挑战

一、覆盖率

间接依赖、静态链接的库、容器基础镜像中的包——完整覆盖不容易。

二、准确性

版本信息可能缺失或被混淆（尤其在 JS 的打包产物中）。

三、生态割裂

不同语言、不同工具生成的 SBOM 格式和质量不一。

四、它是"清单"不是"证明"

SBOM 说明你用了什么，但不证明这些组件是安全的——还需要漏洞扫描、来源验证（如签名）等措施。

一句话

SBOM 不是安全工具，而是"安全的地图"——它让你在危机来临时，知道该去哪里救火。

说明：本文为供应链安全的知识整理。