SBOM 不止是合规清单：从“我用了什么”到“我能承受什么”

监管和客户开始要求交付 SBOM（软件物料清单），于是很多团队把它当成一份“交差文档”——生成、归档、应付审计。这浪费了 SBOM 真正的价值。一份好的 SBOM 不是终点，而是治理的起点。

一份清单，三个层次

同样是 SBOM，深度差别很大。

1. 有什么：列出组件与版本。这是最低要求，也是大多数工具止步的地方。
2. 风险如何：把每个组件关联到 CVE / CNVD / CNNVD / EUVD 等多源漏洞库，标注许可证。
3. 怎么办：结合可达性与可利用性，告诉你先修哪个——而不是甩给你一份 500 条的待办。

片段级，而不是包级

声明式的依赖解析会漏掉两类东西：被复制粘贴进项目的开源片段，以及被改名、裁剪、篡改的组件。片段级指纹比对直接对代码本身生成指纹，比对海量组件库，因此能识别“换了马甲”的开源代码，也能发现许可证被悄悄改动的情况。

SBOM 的价值不在于“完整列出”，而在于“准确关联”。列得再全，如果关联不到风险，也只是一张纸。

让清单驱动行动

把 SBOM 接进 CI/CD，它就从静态文档变成动态防线：新引入的高危组件即时拦截、许可证冲突自动告警、漏洞情报变化实时回流。合规只是副产品，真正的收益是可治理。

这是 CleanSource SCA 的设计哲学：不止生成清单，更让清单变成可执行的治理动作。