SBOM 完全指南：格式、法规与企业落地路径

SBOM（Software Bill of Materials，软件物料清单）是软件的“配料表”：列出一个软件产品由哪些组件构成、各是什么版本、来自哪里、以什么许可证分发。Log4Shell（CVE-2021-44228）爆发那一夜，有 SBOM 的企业用查询回答“我们哪里用了 log4j”，没有的企业用两周的人肉排查回答——这就是它的价值。

三种标准格式怎么选

• SPDX：Linux 基金会主导，已成为国际标准 ISO/IEC 5962，许可证与合规表达能力最强，是开源合规场景的事实标准。
• CycloneDX：OWASP 出品，2024 年成为 Ecma 国际标准，面向安全场景设计，原生支持漏洞可利用性交换（VEX），在 DevSecOps 工具链中集成最广。
• SWID：ISO/IEC 19770-2 软件标识标签，主要用于资产管理，新建体系一般不作首选。

实务建议：工具必须同时支持 SPDX 与 CycloneDX 导出——不同甲方、不同法规会点名不同格式，格式之争不值得站队。内容上应至少覆盖 NTIA 提出的七个最小元素：供应商、组件名、版本、唯一标识、依赖关系、SBOM 作者与时间戳。

全球法规都在要 SBOM

美国：2021 年第 14028 号行政令启动联邦软件采购的 SBOM 要求；FDA 自 2023 年起对含网络功能的医疗器械实施“无 SBOM 不受理”的上市前审查。欧盟：CRA 把机器可读 SBOM 写入法定义务，2027 年底全面适用（详见 CRA 合规时间线）。中国：人民银行等五部门 2021 年《关于规范金融业开源技术应用与发展的意见》要求金融机构掌握开源使用状况，信通院牵头的 SBOM 标准体系与试点持续推进，汽车、医疗等行业的甲方已普遍把 SBOM 写进交付验收条款。

四步落地路径

第一步：生成。用 SCA 工具对代码库与制品自动生成 SBOM。关键决策是检测深度——清单级还是片段级，直接决定 SBOM 是“声明的成分”还是“真实的成分”，差异分析见这篇选型指南；无源码的外购件与固件用二进制成分分析补齐。

第二步：丰富。裸清单价值有限，把组件关联到漏洞情报（CVE/CNVD/CNNVD/EUVD）与许可证义务，并用 VEX 标注“存在但不可利用”的项，才能从文档变成决策依据。

第三步：交付。按客户与法规要求的格式导出、签名、随版本归档，让每个发布版本都有对应的 SBOM 快照。

第四步：运营。SBOM 是活文档：新漏洞披露时反查受影响产品与版本，应答“我们受不受 XX 漏洞影响”应该是分钟级查询而非专项行动。这一步最考验工具的持续监测能力，也是 CleanSource SCA 这类平台与一次性生成脚本的分界线。

怎么判断一份 SBOM 的质量

不同工具生成的 SBOM，纸面格式一样，含金量可以差一个数量级。三个可量化的指标：

• 覆盖深度：只有直接依赖，还是解析到传递依赖？对静态链接、vendored 代码、复制片段是否可见？清单级工具生成的 SBOM 只反映“声明的成分”，与真实成分的偏差可能高达数成。
• 准确率：组件名与版本的识别错误会向下游放大——版本错一位，关联的漏洞列表就整个失真。
• 新鲜度：SBOM 是否随每次构建自动再生成？滞后于版本的清单，在应急响应时反而制造错误的安全感。

另一个常被忽略的配套是 VEX（漏洞可利用性交换）。SBOM 回答“有哪些组件”，VEX 回答“其中的漏洞在我的产品里是否真的可被利用”，状态包括 not_affected、affected、fixed、under_investigation。给客户交付 SBOM 而不附 VEX，等于把数千条 CVE 的研判工作原样转嫁给对方——成熟的交付是两者同行。

常见误区最后提醒三条：SBOM 不是越细越好，先把顶层与直接依赖做准；不要手工维护，人肉清单的保鲜期以周计；不要等法规落到头上才启动——体系建设需要的时间，比合规截止日给你的时间长。