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