DevSecOps 落地失败最常见的样子不是工具没买是卡点设成了必须清零才能上线。第一周安全团队很兴奋SCA、SAST、镜像扫描全接进流水线门禁设成高危必须修完。第二周研发发现一个项目要修 200 个依赖漏洞才能发版直接找领导投诉安全在卡业务。第三周门禁被改成仅告警从此再没人看。第四周项目正式宣告已完成 DevSecOps 建设实际上什么都没拦住。这篇讲的是怎么避免走到第四周。核心是三件事卡点插在哪、门禁分几档、误报怎么治。工具选型只占一小节因为那是最不重要的部分。如果你更关心漏洞从发现到修完的流程和度量可以看 漏洞管理闭环怎么建这篇讲的是怎么在代码交上去的那一刻就拦住。一、DevSecOps 先算一笔账你要挡的是哪一类问题在设卡点之前先看历史数据过去一年出过的线上安全问题分别是什么类型、在哪一环节能拦住。大部分团队的答案是这三类占大头问题类型典型例子能在哪拦住依赖组件漏洞Log4j、Fastjson、老旧版本的 Spring构建时SCA凭据泄漏代码里硬编码的 AK/SK、数据库口令提交时密钥扫描配置错误镜像用 latest、容器 root 运行、安全组开 0.0.0.0/0构建/部署时IaC 与镜像扫描这三类的共同点是能用工具明确判定误报低所以适合做硬门禁。而 SQL 注入、越权这类业务逻辑漏洞SAST 误报率高只适合做提示。这个区分很关键门禁只设在你敢让它阻断发布的地方。设一个你自己都不敢强推的规则最后一定是整条门禁被关掉。二、五个卡点插在哪里流水线的前后顺序是固定提交 → 构建 → 镜像 → 部署 → 上线后。每段能查的东西不一样成本也不一样——越靠左越便宜越靠右越贵。卡点查什么耗时建议动作1. 提交前pre-commit / pre-receive密钥、证书、私钥、大文件秒级阻断2. 构建时依赖组件漏洞SCA、IaC 配置1~3 分钟分级阻断3. 镜像构建后基础镜像漏洞、是否 root、是否 latest1~2 分钟分级阻断4. 部署前DAST 对预发环境扫一遍、配置基线10~30 分钟仅高危阻断5. 上线后运行时检测、RASP、日志告警持续告警2.1 卡点一提交前挡密钥这是投入产出比最高的一个。凭据一旦进了 Git 历史即使后来删掉历史里还在必须 rewrite 历史或者轮换密钥。用 gitleaks 或 trufflehog在 pre-receive hook 或 CI 的第一秒跑# GitLab CI密钥扫描任何命中都阻断这类误报极少可以硬挡 secret-scan: stage: .pre image: zricethezav/gitleaks:latest script: - gitleaks detect --source . --verbose --redact --exit-code 1 allow_failure: false rules: - if: $CI_PIPELINE_SOURCE merge_request_event - if: $CI_COMMIT_BRANCH $CI_DEFAULT_BRANCH注意--redact不要把扫出来的密钥原文打到日志里那等于二次泄露。这一档可以设成硬阻断因为真正的密钥格式很明确AK 长度、前缀、私钥头误报很少。配合一份.gitleaksignore放测试用的假密钥就能稳定运行。2.2 卡点二构建时挡依赖漏洞SCA 是 DevSecOps 的核心也是误报最多的地方。策略必须分级有公开 EXP 且 CVSS ≥ 7阻断CVSS ≥ 7 但需要特定条件告警 要求登记例外CVSS 7只记录进月度报告不要按存在任何高危就阻断。一个正常的企业 Java 项目依赖树里躺着几十个高危是常态——大部分是传递依赖、不在实际调用路径上。# 依赖扫描只对可利用性高的等级阻断其余出报告 sca-scan: stage: build image: aquasec/trivy:latest script: - trivy fs --scanners vuln --severity CRITICAL,HIGH --exit-code 1 --ignore-unfixed --format table --output sca-report.txt . artifacts: when: always paths: [sca-report.txt] allow_failure: true # 先设 true稳定两周后再按情况改--ignore-unfixed这个参数很重要没有修复版本的漏洞挡了也没用只会让研发去研究怎么绕过门禁。这类漏洞应该进接受风险清单靠别的手段缓解WAF 规则、网络隔离。allow_failure: true是我建议的起步姿势先跑两周只看不挡把误报摸清楚再挑最稳的规则改成false。一次只收紧一条规则出问题能立刻定位。2.3 卡点三镜像构建后容器场景下这一档比 SCA 更容易见效因为基础镜像的问题是确定的image-scan: stage: package script: # 三件事一起查漏洞、是否 root、是否用了 latest - trivy image --severity CRITICAL --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA - | USER_LINE$(docker inspect $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA \ --format {{.Config.User}}) if [ -z $USER_LINE ] || [ $USER_LINE root ] || [ $USER_LINE 0 ]; then echo 镜像以 root 运行阻断; exit 1 fi allow_failure: false镜像以 root 运行这一条误报几乎为零、修起来也简单Dockerfile 加一行USER非常适合做硬门禁。基础镜像漏洞则要分级——用一个打满补丁的基础镜像如 distroless 或定期重建的 alpine可以让这一档的噪音降一个数量级。2.4 卡点四部署前 DASTDAST 的问题是慢扫一遍几十分钟而且需要可用环境。建议只在两个时机跑预发环境部署后、上线前的 MR 里且只对高危阻断。一个实用技巧只扫这次变更涉及的接口。全量扫一遍的价值低于持续扫描而增量扫能把时间压到几分钟研发才愿意等。2.5 卡点五上线后这一档不是门禁是兜底。运行时检测RASP、EDR、WAF 日志能发现前四档漏掉的东西尤其是逻辑漏洞和业务欺诈。关键是把线上发现的真实问题反哺回卡点如果一类问题反复从线上冒出来说明前面的卡点没覆盖要么补规则要么补卡点。三、CI/CD 门禁三档策略从仅告警到真阻断这是整套方案能不能落地的核心。我的做法是三档按项目类型分开档位适用范围策略什么时候升级观察档所有存量项目第一周只记录出报告不阻断跑满两周、误报摸清后分级阻断存量项目稳定后、新项目高危可利用 阻断其余告警误报率 10% 后严格阻断核心系统、对外业务高危全阻断中危需登记例外团队已习惯后存量项目和新项目必须分开这是最多人忽略的一点。存量项目一上来就阻断等于让业务停摆——它的依赖可能三年前的、镜像可能是 alpine:3.8。正确做法是先做一次全量扫描把结果整理成欠账清单给三个月清理期期间只告警三个月后再启用阻断。新项目可以直接上分级阻断因为从第一行代码开始就没有历史包袱修起来也便宜。这个区分要写进制度并且明确告诉业务方老系统给三个月新系统从今天起——这句话比任何技术方案都重要因为它决定了研发是配合你还是绕过你。四、和研发怎么谈先把卡字去掉技术方案做得再好研发不配合就是零。而研发抵触的根因通常不是不想安全是你增加了他的工作量但没有减少他的风险。谈的时候有三句话要说到位第一句我不在发版当天拦你。承诺上线窗口内不新增阻断规则这一句能消掉大部分对抗。发版当天加规则是安全团队最容易犯的错——它把安全和延期直接绑在一起之后所有沟通都会变成博弈。第二句这些问题你改起来比线上修便宜。举具体例子一个依赖升级在提交时改是十分钟上线后发现要重新走发布流程是两天。这个对比要说数字不说概念。第三句我给的是可执行的修复建议不是一份报告。告警里带升级到 2.17.1 即可该版本无破坏性变更研发会愿意改只写CVE-2021-44228他会去搜搜完发现要改一堆东西就搁置了。反过来有三件事不要做不要在群里公开点名某个项目漏洞多会让人想办法隐藏而不是修、不要拿等保要求当唯一理由研发对合规无感、不要承诺以后就不会再扫出问题做不到。五、误报推行失败的头号原因工具误报率高研发就会开始怀疑所有告警最后连真的也不看了。治理误报有三个动作缺一不可。动作一每个误报都要有出口。不能只有修和忽略两个选项。要有第三种登记例外——记录原因、责任人、复查日期进例外清单到期自动重扫。# 例外文件示例sca-exceptions.yml放在仓库里随代码评审 exceptions: - id: CVE-2023-12345 component: log4j-core:2.14.1 reason: 该模块未被调用仅作日志格式化使用已确认无 JNDI 解析路径 owner: 张三 expires: 2027-01-31放在仓库里、随代码评审有两个好处例外是被审过的不是安全团队一个人偷偷放过而且有到期日不会永久留着。动作二定期看误报率最高的规则。每月统计一次哪条规则产生的告警最多、其中多少是真问题。占比低于 20% 的规则要么调参、要么降级为提示。动作三让研发能自己判断是不是真问题。告警信息里必须带三样位置哪个文件哪一行/哪个依赖、复现方式、影响说明。只写CVE-2023-12345 高危研发的第一反应就是又来了。这三件事里最容易被跳过的是第三件。它不需要写代码只需要在工具配置里把模板改一下但它对研发的观感影响最大——一份能看懂的报告和一份看不懂的报告处理意愿差好几倍。六、工具链四个必需其余可选不要一开始就上全套。四个必需的工具覆盖了 80% 的实际收益工具类型作用开源可选项密钥扫描挡凭据进仓库gitleaks、trufflehogSCA依赖挡组件漏洞Trivy、Dependency-Check、SyftGrype镜像扫描挡基础镜像问题Trivy、ClairIaC 扫描挡配置错误Checkov、tfsec、kube-linter其余的先不上SAST误报高需要专人调规则、DAST慢需要环境、RASP要改运行时。这些等前四个稳定运行三个月、团队有余力再考虑。工具链有一个隐性成本经常被低估结果要汇总到一处。四个工具四份报告没人会看。至少要让它们输出统一格式SARIF 是通用格式汇总到同一个地方才能看到这个项目现在一共几个待修。七、度量三个数就够DevSecOps 的度量容易做成扫了多少次、发现了多少问题这类数字只证明工具在跑不证明有效。真正有意义的是三个指标定义说明逃逸率上线后发现的问题数 / 上线前发现的问题数低于 10% 说明卡点有效门禁通过率首次提交就通过门禁的比例逐步提升说明研发在改习惯而不是在绕过例外清偿率到期例外已关闭的比例低于 80% 说明例外在变成永久豁免逃逸率是最硬的一个。它直接回答你的卡点到底拦住了没有。统计方法是从线上事件和漏扫结果里反查这个问题本来应该在哪一档被拦住、为什么没拦住。门禁通过率是过程指标。如果它长期低于 50%说明门禁设得太严或者提示不清楚如果它一直是 100%说明门禁形同虚设。八、推进节奏三个季度阶段时间做什么验收一期Q1密钥扫描 SCA 接入全部观察档覆盖全部活跃仓库误报清单成型二期Q2核心项目转分级阻断镜像扫描接入核心项目逃逸率有基线数据三期Q3存量项目清理期结束转阻断例外机制运转例外清偿率 ≥80%一期只做接入不做阻断这一点要顶住压力。很多项目死在一期就想见效结果门禁被投诉到关掉后面再想推就难了。九、几个具体的坑坑一只接新项目。新项目只占代码量的一小部分风险最大的是那些跑了五年的老系统。老项目可以用观察档 欠账清单的方式先覆盖不阻断但要看得见。坑二把 SAST 设成阻断。SAST 误报率高是行业共识设成阻断一定会被绕过。它应该只做提示配合人工审计。坑三门禁信息不落到研发日常用的地方。报告放在安全平台没人看。要把结果推到 MR 评论、Jira 工单里研发在自己的工作流里就能看到。坑四不处理历史欠账。一上来几千个问题研发直接放弃。正确做法是只对新增代码生效增量扫描历史问题单独列清单排期。这一条能让落地难度下降一个数量级。坑五安全团队自己调规则不问研发。规则调得对不对研发最有发言权——他们知道哪些告警是误报。让他们参与调规则接受度会完全不同。十、写在最后DevSecOps 的本质不是在流水线上加几步扫描是把安全的判断标准变成研发能自己执行的规则。衡量成功的标志不是工具接了几个是研发在提交代码前会自己想这段会不会被扫出密钥上线前会自己看一眼依赖报告。到这一步安全才真正左移了——不是把安全团队移到左边是把判断能力交给写代码的人。 
长河君 · 2026/10/29 1:37:26 · 阅读 1.2k DevSecOps 落地怎么不挡发布？五个卡点 + 门禁三档 + 误报治理
DevSecOps 落地失败最常见的样子不是工具没买是卡点设成了必须清零才能上线。第一周安全团队很兴奋SCA、SAST、镜像扫描全接进流水线门禁设成高危必须修完。第二周研发发现一个项目要修 200 个依赖漏洞才能发版直接找领导投诉安全在卡业务。第三周门禁被改成仅告警从此再没人看。第四周项目正式宣告已完成 DevSecOps 建设实际上什么都没拦住。这篇讲的是怎么避免走到第四周。核心是三件事卡点插在哪、门禁分几档、误报怎么治。工具选型只占一小节因为那是最不重要的部分。如果你更关心漏洞从发现到修完的流程和度量可以看 漏洞管理闭环怎么建这篇讲的是怎么在代码交上去的那一刻就拦住。一、DevSecOps 先算一笔账你要挡的是哪一类问题在设卡点之前先看历史数据过去一年出过的线上安全问题分别是什么类型、在哪一环节能拦住。大部分团队的答案是这三类占大头问题类型典型例子能在哪拦住依赖组件漏洞Log4j、Fastjson、老旧版本的 Spring构建时SCA凭据泄漏代码里硬编码的 AK/SK、数据库口令提交时密钥扫描配置错误镜像用 latest、容器 root 运行、安全组开 0.0.0.0/0构建/部署时IaC 与镜像扫描这三类的共同点是能用工具明确判定误报低所以适合做硬门禁。而 SQL 注入、越权这类业务逻辑漏洞SAST 误报率高只适合做提示。这个区分很关键门禁只设在你敢让它阻断发布的地方。设一个你自己都不敢强推的规则最后一定是整条门禁被关掉。二、五个卡点插在哪里流水线的前后顺序是固定提交 → 构建 → 镜像 → 部署 → 上线后。每段能查的东西不一样成本也不一样——越靠左越便宜越靠右越贵。卡点查什么耗时建议动作1. 提交前pre-commit / pre-receive密钥、证书、私钥、大文件秒级阻断2. 构建时依赖组件漏洞SCA、IaC 配置1~3 分钟分级阻断3. 镜像构建后基础镜像漏洞、是否 root、是否 latest1~2 分钟分级阻断4. 部署前DAST 对预发环境扫一遍、配置基线10~30 分钟仅高危阻断5. 上线后运行时检测、RASP、日志告警持续告警2.1 卡点一提交前挡密钥这是投入产出比最高的一个。凭据一旦进了 Git 历史即使后来删掉历史里还在必须 rewrite 历史或者轮换密钥。用 gitleaks 或 trufflehog在 pre-receive hook 或 CI 的第一秒跑# GitLab CI密钥扫描任何命中都阻断这类误报极少可以硬挡 secret-scan: stage: .pre image: zricethezav/gitleaks:latest script: - gitleaks detect --source . --verbose --redact --exit-code 1 allow_failure: false rules: - if: $CI_PIPELINE_SOURCE merge_request_event - if: $CI_COMMIT_BRANCH $CI_DEFAULT_BRANCH注意--redact不要把扫出来的密钥原文打到日志里那等于二次泄露。这一档可以设成硬阻断因为真正的密钥格式很明确AK 长度、前缀、私钥头误报很少。配合一份.gitleaksignore放测试用的假密钥就能稳定运行。2.2 卡点二构建时挡依赖漏洞SCA 是 DevSecOps 的核心也是误报最多的地方。策略必须分级有公开 EXP 且 CVSS ≥ 7阻断CVSS ≥ 7 但需要特定条件告警 要求登记例外CVSS 7只记录进月度报告不要按存在任何高危就阻断。一个正常的企业 Java 项目依赖树里躺着几十个高危是常态——大部分是传递依赖、不在实际调用路径上。# 依赖扫描只对可利用性高的等级阻断其余出报告 sca-scan: stage: build image: aquasec/trivy:latest script: - trivy fs --scanners vuln --severity CRITICAL,HIGH --exit-code 1 --ignore-unfixed --format table --output sca-report.txt . artifacts: when: always paths: [sca-report.txt] allow_failure: true # 先设 true稳定两周后再按情况改--ignore-unfixed这个参数很重要没有修复版本的漏洞挡了也没用只会让研发去研究怎么绕过门禁。这类漏洞应该进接受风险清单靠别的手段缓解WAF 规则、网络隔离。allow_failure: true是我建议的起步姿势先跑两周只看不挡把误报摸清楚再挑最稳的规则改成false。一次只收紧一条规则出问题能立刻定位。2.3 卡点三镜像构建后容器场景下这一档比 SCA 更容易见效因为基础镜像的问题是确定的image-scan: stage: package script: # 三件事一起查漏洞、是否 root、是否用了 latest - trivy image --severity CRITICAL --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA - | USER_LINE$(docker inspect $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA \ --format {{.Config.User}}) if [ -z $USER_LINE ] || [ $USER_LINE root ] || [ $USER_LINE 0 ]; then echo 镜像以 root 运行阻断; exit 1 fi allow_failure: false镜像以 root 运行这一条误报几乎为零、修起来也简单Dockerfile 加一行USER非常适合做硬门禁。基础镜像漏洞则要分级——用一个打满补丁的基础镜像如 distroless 或定期重建的 alpine可以让这一档的噪音降一个数量级。2.4 卡点四部署前 DASTDAST 的问题是慢扫一遍几十分钟而且需要可用环境。建议只在两个时机跑预发环境部署后、上线前的 MR 里且只对高危阻断。一个实用技巧只扫这次变更涉及的接口。全量扫一遍的价值低于持续扫描而增量扫能把时间压到几分钟研发才愿意等。2.5 卡点五上线后这一档不是门禁是兜底。运行时检测RASP、EDR、WAF 日志能发现前四档漏掉的东西尤其是逻辑漏洞和业务欺诈。关键是把线上发现的真实问题反哺回卡点如果一类问题反复从线上冒出来说明前面的卡点没覆盖要么补规则要么补卡点。三、CI/CD 门禁三档策略从仅告警到真阻断这是整套方案能不能落地的核心。我的做法是三档按项目类型分开档位适用范围策略什么时候升级观察档所有存量项目第一周只记录出报告不阻断跑满两周、误报摸清后分级阻断存量项目稳定后、新项目高危可利用 阻断其余告警误报率 10% 后严格阻断核心系统、对外业务高危全阻断中危需登记例外团队已习惯后存量项目和新项目必须分开这是最多人忽略的一点。存量项目一上来就阻断等于让业务停摆——它的依赖可能三年前的、镜像可能是 alpine:3.8。正确做法是先做一次全量扫描把结果整理成欠账清单给三个月清理期期间只告警三个月后再启用阻断。新项目可以直接上分级阻断因为从第一行代码开始就没有历史包袱修起来也便宜。这个区分要写进制度并且明确告诉业务方老系统给三个月新系统从今天起——这句话比任何技术方案都重要因为它决定了研发是配合你还是绕过你。四、和研发怎么谈先把卡字去掉技术方案做得再好研发不配合就是零。而研发抵触的根因通常不是不想安全是你增加了他的工作量但没有减少他的风险。谈的时候有三句话要说到位第一句我不在发版当天拦你。承诺上线窗口内不新增阻断规则这一句能消掉大部分对抗。发版当天加规则是安全团队最容易犯的错——它把安全和延期直接绑在一起之后所有沟通都会变成博弈。第二句这些问题你改起来比线上修便宜。举具体例子一个依赖升级在提交时改是十分钟上线后发现要重新走发布流程是两天。这个对比要说数字不说概念。第三句我给的是可执行的修复建议不是一份报告。告警里带升级到 2.17.1 即可该版本无破坏性变更研发会愿意改只写CVE-2021-44228他会去搜搜完发现要改一堆东西就搁置了。反过来有三件事不要做不要在群里公开点名某个项目漏洞多会让人想办法隐藏而不是修、不要拿等保要求当唯一理由研发对合规无感、不要承诺以后就不会再扫出问题做不到。五、误报推行失败的头号原因工具误报率高研发就会开始怀疑所有告警最后连真的也不看了。治理误报有三个动作缺一不可。动作一每个误报都要有出口。不能只有修和忽略两个选项。要有第三种登记例外——记录原因、责任人、复查日期进例外清单到期自动重扫。# 例外文件示例sca-exceptions.yml放在仓库里随代码评审 exceptions: - id: CVE-2023-12345 component: log4j-core:2.14.1 reason: 该模块未被调用仅作日志格式化使用已确认无 JNDI 解析路径 owner: 张三 expires: 2027-01-31放在仓库里、随代码评审有两个好处例外是被审过的不是安全团队一个人偷偷放过而且有到期日不会永久留着。动作二定期看误报率最高的规则。每月统计一次哪条规则产生的告警最多、其中多少是真问题。占比低于 20% 的规则要么调参、要么降级为提示。动作三让研发能自己判断是不是真问题。告警信息里必须带三样位置哪个文件哪一行/哪个依赖、复现方式、影响说明。只写CVE-2023-12345 高危研发的第一反应就是又来了。这三件事里最容易被跳过的是第三件。它不需要写代码只需要在工具配置里把模板改一下但它对研发的观感影响最大——一份能看懂的报告和一份看不懂的报告处理意愿差好几倍。六、工具链四个必需其余可选不要一开始就上全套。四个必需的工具覆盖了 80% 的实际收益工具类型作用开源可选项密钥扫描挡凭据进仓库gitleaks、trufflehogSCA依赖挡组件漏洞Trivy、Dependency-Check、SyftGrype镜像扫描挡基础镜像问题Trivy、ClairIaC 扫描挡配置错误Checkov、tfsec、kube-linter其余的先不上SAST误报高需要专人调规则、DAST慢需要环境、RASP要改运行时。这些等前四个稳定运行三个月、团队有余力再考虑。工具链有一个隐性成本经常被低估结果要汇总到一处。四个工具四份报告没人会看。至少要让它们输出统一格式SARIF 是通用格式汇总到同一个地方才能看到这个项目现在一共几个待修。七、度量三个数就够DevSecOps 的度量容易做成扫了多少次、发现了多少问题这类数字只证明工具在跑不证明有效。真正有意义的是三个指标定义说明逃逸率上线后发现的问题数 / 上线前发现的问题数低于 10% 说明卡点有效门禁通过率首次提交就通过门禁的比例逐步提升说明研发在改习惯而不是在绕过例外清偿率到期例外已关闭的比例低于 80% 说明例外在变成永久豁免逃逸率是最硬的一个。它直接回答你的卡点到底拦住了没有。统计方法是从线上事件和漏扫结果里反查这个问题本来应该在哪一档被拦住、为什么没拦住。门禁通过率是过程指标。如果它长期低于 50%说明门禁设得太严或者提示不清楚如果它一直是 100%说明门禁形同虚设。八、推进节奏三个季度阶段时间做什么验收一期Q1密钥扫描 SCA 接入全部观察档覆盖全部活跃仓库误报清单成型二期Q2核心项目转分级阻断镜像扫描接入核心项目逃逸率有基线数据三期Q3存量项目清理期结束转阻断例外机制运转例外清偿率 ≥80%一期只做接入不做阻断这一点要顶住压力。很多项目死在一期就想见效结果门禁被投诉到关掉后面再想推就难了。九、几个具体的坑坑一只接新项目。新项目只占代码量的一小部分风险最大的是那些跑了五年的老系统。老项目可以用观察档 欠账清单的方式先覆盖不阻断但要看得见。坑二把 SAST 设成阻断。SAST 误报率高是行业共识设成阻断一定会被绕过。它应该只做提示配合人工审计。坑三门禁信息不落到研发日常用的地方。报告放在安全平台没人看。要把结果推到 MR 评论、Jira 工单里研发在自己的工作流里就能看到。坑四不处理历史欠账。一上来几千个问题研发直接放弃。正确做法是只对新增代码生效增量扫描历史问题单独列清单排期。这一条能让落地难度下降一个数量级。坑五安全团队自己调规则不问研发。规则调得对不对研发最有发言权——他们知道哪些告警是误报。让他们参与调规则接受度会完全不同。十、写在最后DevSecOps 的本质不是在流水线上加几步扫描是把安全的判断标准变成研发能自己执行的规则。衡量成功的标志不是工具接了几个是研发在提交代码前会自己想这段会不会被扫出密钥上线前会自己看一眼依赖报告。到这一步安全才真正左移了——不是把安全团队移到左边是把判断能力交给写代码的人。