CI/CD流水线安全左移别等线上出问题才补救

上个月跟某互联网公司的运维负责人吃饭，对方扒拉着外卖盒骂了二十分钟。 说刚处理完一起因为硬编码数据库密钥差点泄露核心用户数据的事故。这个漏洞本来该在上线前的安全扫描环节被拦下来，结果开发为了赶季度版本，直接跳过了流水线里的安全扫描步骤，密钥就这么跟着代码上了生产，跑了三天才被外部的公开扫描器揪出来。 他们之前的安全流程说起来也很常规：开发写完代码提测，安全团队在上线前统一扫一遍代码和镜像，没问题就放行。听起来没毛病，对吧？但开发赶进度的时候，哪管你什么安全规则，能把版本上线就完事。后来他们才咬着牙搞CI/CD流水线安全左移，折腾了小半年，才算把流程跑顺。

最先踩的坑是把扫描器塞进流水线就完事

很多团队刚开始做安全左移，第一反应就是把之前用的SAST、DAST、依赖扫描工具往流水线里一挂，觉得就算落地了。 我去年接触过一个两百人规模的研发团队，一开始就是这么干的。把全量代码扫描挂在主分支合并的节点，每次跑要二十二分钟。开发提交代码之后得等二十多分钟才能继续往下走，赶版本的时候直接给流水线开了”失败可跳过”的权限。等于花了几十万买的扫描器，最后成了个摆饰，没人当回事。

说白了，工具塞进去不代表流程跑通了。你得站在开发的角度想问题，谁受得了每次提交等半小时？换你你也嫌烦。 后来这个团队改了规则，高风险问题直接阻塞流水线，比如硬编码密钥、高危依赖漏洞，卡了就必须改，不然后续步骤走不通。中低风险的问题不卡，自动生成工单派给对应的开发，两周内改完就行。扫描也改成增量扫描，只扫本次提交的代码片段，不跑全量，整个扫描时间压到了三分钟以内。没人再去跳过步骤了。 哦对，还有个小细节，他们把扫描的结果直接推到开发的企业微信上，哪行代码有问题，点进去就能跳转到对应的提交记录，不用开发自己翻日志找问题。

别把安全左移做成安全团队的独角戏

我见过太多团队的安全左移，最后变成了安全部门的KPI。开发该怎么写代码怎么写，安全团队天天追在后面催着改漏洞，累得半死还落不到好。 之前碰到过一个更离谱的，安全团队自己定了个规则，说所有代码里不能出现长度超过32位的字符串常量，不管这个常量是密钥还是普通的配置。结果有个开发写的业务逻辑常量刚好33位，直接被流水线卡了，开发根本不知道哪里出了问题，拉着安全团队的人扯了两个半小时，最后才发现是规则写得太想当然。

安全左移不是安全团队给开发加约束，是要把安全能力嵌到开发的日常工作流里。比如给开发装个IDE的安全插件，写代码的时候刚敲完密钥，插件直接弹个提示：”这里检测到疑似硬编码密钥，建议改用环境变量注入”，改起来顺手得很。要是等代码提交到流水线，过了五分钟才报错，开发都忘了刚才那行代码是干啥的，还得翻半天提交记录。 规则也得一起定。安全团队不能上来就拍脑袋写一堆要求，得跟开发坐下来聊，哪些问题是真的会出大事的，必须卡死；哪些是规范类的问题，没必要卡流水线，放到代码评审环节提就行。比如硬编码密钥、远程命令执行漏洞，这种真能搞出生产事故的，必须卡；但变量名命名不规范这种事，没必要浪费流水线的时间。

上线前的最后一道闸别留死角

很多人对安全左移的理解，就是把安全检查挪到开发写代码的阶段，其实不对。流水线的最后一步，也就是上线前的环节，也得把安全检查嵌进去，不然就是留了个大漏洞。 我之前见过一个团队，开发把本地的测试用.env文件给打包进了容器镜像，里面存了测试环境的数据库账号密码。之前的流水线只扫代码，不扫镜像，这个带了敏感信息的镜像就这么被推到了公共镜像仓库，过了两天才被外部的安全研究者扫到，差点把测试环境的核心数据给搞没。 代价是什么？要是上线前你不扫镜像，等镜像跑起来了才发现问题，你得把所有跑这个镜像的实例全部停掉，重新构建新镜像再上线，业务中断少说几十分钟。要是真被人扫到了敏感信息，那损失根本没法估量。 所以他们后来加了容器镜像漏洞扫描的步骤，上线前自动扫一遍镜像的基础镜像有没有高危漏洞，有没有把不该打包的敏感文件塞进去，整个过程也就三分钟，不耽误上线时间。 上周跟之前那个运维负责人吃饭，他说现在他们的流水线跑下来，整个安全检查的环节加起来不到五分钟。开发没觉得麻烦，安全团队也不用天天半夜起来救火。 哦对，他们每个月还会把流水线扫出来的常见问题整理成小培训，比如这个月大家容易犯的错是把测试密钥写进代码，下次培训就讲怎么用密钥管理服务，怎么通过环境变量注入配置，不用开发硬编码。 这事没那么玄。说白了就是把之前要等线上出问题才发现的漏洞，往前挪几步，让大家在写代码、打包镜像的时候就把问题改了，不用等线上炸锅了再抱着服务器哭。