哪里出了问题？
没有什么戏剧性的事，这正是要点。安全在每次发布的最后由人工审查。发现在代码写完之后才到，于是发布在等，同样的返工一个冲刺接一个冲刺地回来。延误只是看得见的部分。在它底下，审计发现堆积，旧代码背着没人有时间偿还的债务，第三方组件未经检查就进了生产，一支小小的安全团队永远落在后面。每个人都在做自己的工作。只是工作放错了地方。 红色标记是出口关卡。路下方的点是度量每个阶段的位置。
我做了什么？
我从人开始，而不是工具。一位高管同意为这次改变背书，一个 DevSecOps 论坛开始定期碰面，每个开发团队指定一位安全倡导者，一个把问题双向传递的人。然后我才画路线图：指南、标准、要接入流水线的工具，用 OWASP DevSecOps 成熟度模型来度量。目标很朴素：十二个月内全部达到二级，在最重要的两处，构建与部署、测试与验证，达到三级。
这一年被切成四个阶段，每个阶段都有一道必须通过才能离开的关卡。前三个月是打基础：一次评估、一份策略，在一两个试点应用里做代码和依赖扫描，仅此而已。第三到第六个月是自动化：策略门禁、密钥扫描、动态测试。第六到第十二个月是扩展：让新团队一开始就安全的流水线模板，基础设施和容器扫描。第十二个月之后是优化，它永远不会结束：运行时监控，每个季度看一次数字。
生命周期的每一步都有了自己的控制。计划时做威胁建模。编码时扫描密钥。构建时扫描代码、依赖和物料清单。测试时做动态测试。发布时用签名制品和策略门禁。部署时用带密钥保险库的基础设施和容器扫描。运行时做监控。而且因为没有主人的工具会腐烂，我把责任规则重写成一份覆盖策略、流水线运营、修复和分诊的 RACI，对应到 NIST SSDF、OWASP SAMM 和 ISO/IEC 27001:2022，让审计人员要的证据自己累积起来。
什么改变了？
安全不再是一个事件，而成了一种习惯。四个数字说明这个习惯是否守住了，每个都在第一阶段取了基线：严重漏洞多快修好，发布前拦下的发现占多少，多少应用走过了安全流水线，一次发布要多久。每项控制先试点，再自动化，等团队信任了才成为发布门禁。这个顺序让拖垮此类项目的两个风险，开发者的抵触和告警疲劳，从未扎根。