上一篇提到，很多企业在漏洞爆发时，甚至不知道自己系统里用了什么。
很多人会觉得："我们已经做了 DevOps，CI/CD 跑得很溜，应该没问题了吧？"
但有个问题我问过很多人："你们的安全扫描结果，有人看吗？"
对方沉默了一会儿，说："好像……没人看。"
这个对话，我经历过太多次了。
我不是来否定 DevOps 的。
过去十年，DevOps 彻底改变了软件交付的方式。代码提交到部署全自动化，环境一致性用容器解决，发布频率从"一个月一次"变成"一天好几次"。
DevOps 很擅长解决"交付效率"问题。流水线会关心：
这些它都能自动化。
但有一个问题，它天然不关心：你交付的镜像里，到底有什么组件？
流水线不会问你：
DevOps 解决的是"怎么快"，不管"交付了什么"。
我见过太多企业，CI/CD 跑得很溜，但安全团队问一句"你们系统里用了哪些开源组件"，没人答得上来。
为什么？
因为 DevOps 流水线里，根本没有"软件成分管理"这个环节。
你引入了一个新组件，流水线会帮你构建、测试、部署，但不会问你：
这些问题，DevOps 不回答。
这个错觉最普遍。
很多企业的做法是：在流水线里加一个安全扫描步骤，每次构建自动扫描，发现问题就报警。听起来很完美对吧？
现实是什么？
我见过一个客户，每次构建扫描出来 200 多个漏洞。开发团队看了一眼，觉得"太多了，根本处理不过来"，然后做了什么？把通知关了。
工具还在跑，但没人看结果。形同虚设。
开发本来就忙，扫描结果又多又杂，你让他去分辨哪些是真漏洞、哪些是误报？他只会做一件事：忽略全部。
工具 ≠ 方案。没有流程设计的扫描，只会制造噪音。
容器化确实解决了很多问题，但也带来了新的盲区。
我见过一个真实案例：某企业用 node:14 作为基础镜像，跑了半年都没事。后来安全扫描发现镜像里有个 OpenSSL 高危漏洞，不得不临时停服修复，业务损失不小。
问题在哪？
容器只是把问题打包了，没有解决问题。
"我们用 npm / Maven / go mod，依赖都记在 package.json / pom.xml / go.mod 里，有什么问题？"
问题是：这些文件只记录了直接依赖。
间接依赖呢？依赖的依赖呢？
一个典型的 Node.js 应用可能包含 几百个间接依赖，它们被你的直接依赖带进来，你根本不知道它们的存在。而这些间接依赖，往往是漏洞的重灾区。
更关键的是，包管理工具不会告诉你：
你知道自己安装了什么包，但不知道这些包最终把哪些东西带进了系统。
如果把这三个错觉抽象一下，会发现一个共同点：
DevOps 很擅长提高交付效率，但它天然不负责软件成分治理。
你的 CI/CD 可以做到一天发布十次，但如果没人知道这十次发布引入了什么组件、有什么风险，你的系统依然是失控的。
说一个我亲身经历过的场景。
某银行项目接受合规审计，审计人员问了一个问题："你们怎么保证第三方组件的安全？有没有清单？"
开发团队面面相觑。CI/CD 跑了好几年，代码也一直在迭代，但从来没有人系统地记录过"用了哪些组件、什么版本、有没有风险"。
最后怎么办？临时抱佛脚，几个人花了三天时间手动整理了一份清单。还不一定全。
合规不是"做了就行"，是要"能证明你做了"。
回到开头那个问题：为什么做了 DevOps，开源依赖还是管不好？
答案很简单：DevOps 给了你"效率"，没给你"控制力"。
上一篇我说过，开源治理至少需要三层能力：
SBOM 解决的是第一层。但光有可见性不够，你还需要控制力。
什么是控制力？就是一套流程，让开源组件的引入、使用、退出都有规矩可循。
这个，DevOps 没给你。你得自己建。
很多人以为 SBOM 就是"列个清单"，其实没那么简单。不同的生成方式，准确性、覆盖范围、适用场景都不一样。选错了方式，可能比没有 SBOM 还糟糕。
因为很多企业的问题，从来不是"发现不了漏洞"，而是：
根本不知道，自己的系统里到底有什么。
下一篇，我们来聊聊SBOM 。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。