为什么做了 DevOps你还是管不好开源依赖上一篇提到很多企业在漏洞爆发时甚至不知道自己系统里用了什么。很多人会觉得我们已经做了 DevOpsCI/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 没给你。你得自己建。