SBOM 落地实践：用软件物料清单构建可追溯安全基线
摘要：软件物料清单（SBOM）已成为供应链透明化的核心抓手。本文结合 CycloneDX 与 SPDX 标准，分享企业从生成、管理到与漏洞联动的落地路径。
软件物料清单（Software Bill of Materials, SBOM）如同食品的配料表，它完整记录一款软件由哪些组件、库、模块构成，以及它们的版本与来源关系。当出现新漏洞（如某开源库被曝 0day）时，拥有 SBOM 的团队可在分钟级定位“我是否受影响、影响哪些产品”，而不必逐项目人工排查。
它把“看不见的依赖”变成“可检索的资产”，是供应链透明化与快速响应的前提。
当前国际主流的 SBOM 标准主要有两类：CycloneDX 由 OWASP 主导，结构轻量、对漏洞与组件关系表达友好，生态工具链成熟；SPDX 由 Linux 基金会维护，偏重许可证合规表达，深受合规场景青睐。两者均支持 JSON、XML 等格式，企业可按侧重点选择，也可并行产出。
选型建议：以安全响应为主选 CycloneDX，以许可证治理为主选 SPDX，二者并非互斥。
第一步，在构建阶段自动生成 SBOM，以 CycloneDX 为例可借助主流构建插件直接产出。第二步，集中存储并建立组件词典，打通各产品线。第三步，建立版本与来源台账，标注自研、第三方与传递依赖。第四步，将 SBOM 纳入发布物，随制品一并交付与归档。
关键不是“生成一次”，而是“每次构建都生成、每次发布都携带”。
SBOM 的真正价值在于联动。将 SBOM 接入漏洞情报源后，一旦某组件曝出 CVE，系统即可自动回查受影响产品并触发修复工单。这让“被动应急”转为“主动可见”。当 SBOM 成为研发的默认产物，安全团队才真正拥有供应链的全局视野。
— OWASP 中国（开放 Web 应用安全项目） —