很多企业做了 SBOM，为什么依然管不住依赖？

上一篇聊到，很多企业做了 DevOps，开源依赖还是管不好。根本原因之一：不知道自己的系统里到底有什么。

所以很多人想到的第一步是：生成 SBOM。

但 SBOM 这东西，选错生成方式，比不生成更麻烦。

我见过太多"没用的 SBOM"

有个客户，花了大价钱买了 SCA 工具，每个项目都生成了 SBOM。合规审计的时候拿出来，格式标准、字段齐全，看起来很漂亮。

但后来 Log4j 的问题又来了，安全团队拿着 SBOM 去查，发现：

• 三个核心服务的 SBOM 是半年前生成的，依赖已经变了
• 有两个服务根本没生成过 SBOM，因为构建流程没接入工具
• 还有一个服务的 SBOM 里，间接依赖只列了一层，深层依赖完全没覆盖

SBOM 是有了，但跟没有差不多。

还有个客户，比上面这个走得更远——他们已经接入了 SBOM 平台，每个构建都自动生成，看起来流程健全。

但有一次漏洞爆发，安全团队想查"哪些生产服务受影响"，对着平台里的 SBOM 查了半天，发现：

• 三个核心服务的 SBOM 是三个月前生成的
• 中间发过五次版，镜像更新了，SBOM 没重新生成
• 运维那边打的新镜像，跟平台里记录的根本对不上

最后的结果是：平台里的 SBOM 是"正确"的，但系统里跑的已经不是那一份了。

平台说"你没风险"，实际上只是"没更新"。

很多人把 SBOM 当成了一个"交付物"——生成了就完事了。但 SBOM 不是体检报告，做一次就完了。它是心电图，得持续监测，而且得测得准。

问题是：生成 SBOM 的方式有好几种，每种都有自己的局限。不了解这些局限，你拿到的 SBOM 可能从一开始就有问题。

SBOM 的三种生成方式

本质上都是在回答同一个问题：你从哪里获取软件成分信息？

方式一：构建时生成——"出厂质检单"

原理很简单：在软件构建的时候（比如 Maven 编译、npm install、Docker build），通过插件拦截构建过程，自动解析依赖关系，生成 SBOM。

就像工厂生产产品，在流水线上就把所有原材料的批次、供应商、规格记录下来。

优点： 准确。因为它基于实际构建产物，你用了什么就记录什么，直接依赖、间接依赖都能捕获。

缺点： 前提是你的项目得有标准化的构建流程。没有构建流程的老系统？覆盖不了。不同语言、不同构建工具需要配不同的插件，得一个个搞。

关键判断： 构建时生成是最靠谱的方式，但它对基础设施有要求——需要有标准化的构建流水线。如果你的团队连 CI/CD 都没跑起来，这条路走不通。

适用场景： 新项目、有标准化构建流程的团队。

方式二：扫描生成——"事后审计"

原理：软件已经构建好了（JAR 包、Docker 镜像、二进制文件），你拿工具去扫描它，通过文件特征、包名、版本号等信息，反推里面用了什么组件。

就像产品已经出厂了，你拆开看看里面用了什么材料。

优点： 不需要改构建流程，非侵入式。特别适合两种场景：一是没有构建流程的存量系统，二是第三方采购的闭源软件——你拿不到源码，但可以扫描产物。

缺点： 准确性是个问题。

我见过一个案例：某客户用扫描工具去扫 C 语言编译的固件，结果 73% 的组件识别失败。为什么？因为 C 语言编译时经常做静态链接，把所有依赖库合并进一个二进制文件，再加上符号表被剥离（strip），扫描工具根本认不出里面有什么。

还有混淆过的代码、加密过的包，扫描工具一样抓瞎。

关键判断： 扫描生成的 SBOM，准确性取决于特征库的覆盖度。漏识别、误识别都是常态。拿它做合规交差可以，拿它做安全排查，得留个心眼。

方式三：运行时分析——"实时监控"

原理：在应用运行的时候，通过 Agent 或 eBPF 等技术，监控实际加载和调用的依赖库，记录真实的软件成分。

就像不是看设计图纸，而是看实际运转中哪些零件在工作。

优点： 最真实。它能发现两种"异常"：一是"声明了但没用"的依赖，二是"用了但没声明"的依赖。构建时生成和扫描都发现不了这些问题。

缺点： 实现复杂度最高。你得在生产或测试环境部署 Agent，有性能开销，而且只能覆盖"被触发"的代码路径——某些冷门功能如果没被调用，相关的依赖就监测不到。

关键判断： 运行时分析最接近真相，但代价也最大。适合做抽样验证，不适合大规模铺开。

适用场景： 对安全性要求极高的关键系统，或者用来验证其他方式生成的 SBOM 是否准确。

一个更隐蔽的坑：不准的 SBOM，比没有更危险

为什么？

因为如果你知道"我没有 SBOM"，你至少会保持警惕，知道自己的系统是"看不见"的。

但如果你有一份 SBOM，你觉得"我有了"，但实际上这份 SBOM 不全、不准、已经过时——你反而会陷入一种虚假的安全感。

有个真实的例子：

一个客户用扫描工具生成了 SBOM，审计时被问到"你们有没有用 Log4j"。客户翻了 SBOM，说"没有"。

结果后来深入排查发现，Log4j 是被一个间接依赖带进来的，但扫描工具只识别了两层依赖，第三层以下完全没覆盖。

SBOM 说"没有"，实际上是"没扫到"。

这种"没扫到"和"确实没有"，在后果上是一样的——你都会漏掉风险。但前者更可怕，因为它让你以为你已经排查过了。

所以回到一开始的问题：选哪种生成方式，不只是技术决策。 如果你选了扫描方式来做主力，你得清楚它的盲区在哪里，然后在盲区上做补位。否则你拿到一份看似完整的 SBOM，实际上满是大洞。

三种方式怎么选？

不要只选一种，要组合用。

我的建议是：

• 主力：构建时生成。 覆盖所有有构建流程的项目，准确性最高。
• 补充：扫描生成。 覆盖存量系统和第三方软件，构建时生成触达不到的地方。
• 验证：运行时分析。 对关键系统抽样验证，确保 SBOM 真实反映实际情况。

真正要解决的是什么？

回到这个系列的主线。我说过，开源治理需要三层能力：

• 第一层：可见性——你知道系统里用了什么
• 第二层：控制力——你能管住怎么用
• 第三层：决策能力——你知道该不该用

SBOM 解决的是第一层。但"生成 SBOM"只是可见性的起点，不是终点。

真正的可见性，不是"生没生成"，而是三个层面都做到了才算：

先看全。你可能有十个服务，但只给八个生成了 SBOM，剩下两个是手动部署的老系统。那缺的那两个，就是盲区。很多企业的漏洞排查，漏的就是这种"不在流程里的系统"。

再看准。SBOM 里写的东西，和实际跑的到底一不一样？一个扫描工具只认两层依赖，第三层以下没覆盖，那它说"你没用 Log4j"，你敢信吗？前面说的案例，问题就出在这里。

最后看新。今天的依赖和三个月前一样吗？中间发了五次版，依赖升过两次，但 SBOM 还是三个月前那一份。平台里写的是 A，实际跑的是 B，那这份 SBOM 还有什么用？

全、准、新，缺任何一个，你的"可见性"都是有盲区的。

而要做到这三点，光靠工具不够。

你会发现，上面这三个问题，没有一个是"换一个更好的扫描工具"能解决的。它们都是流程问题。

全，需要规范——所有项目必须通过统一流水线构建，不能有"漏网之鱼"。

准，需要验证——不能假设工具扫出来就是对的，要对关键系统做交叉验证。

新，需要绑定——SBOM 的生成必须跟构建、发版绑在一起，不能靠人记得去触发。

这就是从"生成 SBOM"到"治理依赖"之间的那个坎。

很多人跨不过去，是因为他们把 SBOM 当成安全团队的事。但实际上，它应该嵌在开发流程里。

所以真正困难的问题，从来不是"怎么生成一份 SBOM"。

而是：当开发引入一个高风险组件时，企业有没有能力阻止它进入生产环境。

这个"有没有能力"，取决于流程，不取决于工具。

下一篇开源治理全生命周期设计，我会讲怎么设计一套"引入 → 使用 → 退出"的全生命周期治理流程，让开源组件真正管得住。