为什么做了 DevOps，你还是管不好开源依赖？

为什么做了 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 没给你。你得自己建。