上一篇聊到，很多企业做了 DevOps，开源依赖还是管不好。根本原因之一：不知道自己的系统里到底有什么。
所以很多人想到的第一步是：生成 SBOM。
但 SBOM 这东西，选错生成方式，比不生成更麻烦。
有个客户，花了大价钱买了 SCA 工具，每个项目都生成了 SBOM。合规审计的时候拿出来，格式标准、字段齐全，看起来很漂亮。
但后来 Log4j 的问题又来了，安全团队拿着 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，审计时被问到"你们有没有用 Log4j"。客户翻了 SBOM，说"没有"。
结果后来深入排查发现，Log4j 是被一个间接依赖带进来的，但扫描工具只识别了两层依赖，第三层以下完全没覆盖。
SBOM 说"没有"，实际上是"没扫到"。
这种"没扫到"和"确实没有"，在后果上是一样的——你都会漏掉风险。但前者更可怕，因为它让你以为你已经排查过了。
所以回到一开始的问题：选哪种生成方式，不只是技术决策。 如果你选了扫描方式来做主力，你得清楚它的盲区在哪里，然后在盲区上做补位。否则你拿到一份看似完整的 SBOM，实际上满是大洞。
不要只选一种，要组合用。
我的建议是：
回到这个系列的主线。我说过，开源治理需要三层能力：
SBOM 解决的是第一层。但"生成 SBOM"只是可见性的起点，不是终点。
真正的可见性，不是"生没生成"，而是三个层面都做到了才算：
先看全。你可能有十个服务，但只给八个生成了 SBOM，剩下两个是手动部署的老系统。那缺的那两个，就是盲区。很多企业的漏洞排查，漏的就是这种"不在流程里的系统"。
再看准。SBOM 里写的东西，和实际跑的到底一不一样？一个扫描工具只认两层依赖，第三层以下没覆盖，那它说"你没用 Log4j"，你敢信吗？前面说的案例，问题就出在这里。
最后看新。今天的依赖和三个月前一样吗？中间发了五次版，依赖升过两次，但 SBOM 还是三个月前那一份。平台里写的是 A，实际跑的是 B，那这份 SBOM 还有什么用？
全、准、新，缺任何一个，你的"可见性"都是有盲区的。
而要做到这三点，光靠工具不够。
你会发现，上面这三个问题，没有一个是"换一个更好的扫描工具"能解决的。它们都是流程问题。
全，需要规范——所有项目必须通过统一流水线构建，不能有"漏网之鱼"。
准，需要验证——不能假设工具扫出来就是对的，要对关键系统做交叉验证。
新，需要绑定——SBOM 的生成必须跟构建、发版绑在一起，不能靠人记得去触发。
这就是从"生成 SBOM"到"治理依赖"之间的那个坎。
很多人跨不过去，是因为他们把 SBOM 当成安全团队的事。但实际上，它应该嵌在开发流程里。
所以真正困难的问题，从来不是"怎么生成一份 SBOM"。
而是：当开发引入一个高风险组件时，企业有没有能力阻止它进入生产环境。
这个"有没有能力"，取决于流程，不取决于工具。
下一篇开源治理全生命周期设计，我会讲怎么设计一套"引入 → 使用 → 退出"的全生命周期治理流程，让开源组件真正管得住。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。