在传统研发流程里，安全测试通常被安排在上线前的最后一周：安全团队拿到一个近乎完成的系统，扫一遍、渗透一轮，然后甩出一份漏洞清单。开发团队面对发布窗口的压力，往往只能挑高危的临时补一补，剩下的记入技术债。这种模式的根本缺陷在于，缺陷发现得越晚，修复成本越高——架构层面的安全设计问题，在编码完成后几乎没有回旋余地。 安全左移的核心，是把安全检查拆解成若干轻量动作，均匀分布到研发全流程中。第一道防线在需求与设计阶段。安全工程师提前介入需求评审和架构设计，用威胁建模的方法识别信任边界、数据流向和潜在攻击面。这个阶段的产出不是漏洞列表，而是一组必须满足的安全需求，比如敏感字段必须加密存储、外部输入必须经过统一校验层。 第二道防线在编码阶段，由 SAST（静态应用安全测试）和 IDE 插件承担。开发者写完一段代码，工具立刻提示这里存在 SQL 拼接风险、那里的加密算法已被弃用。反馈越即时，修复成本越低——在开发者还记得上下文的时候修 bug，和三周后翻代码回忆当时逻辑，完全是两件事。 第三道防线是软件供应链。现代应用中开发者自写代码往往不足两成，其余全部来自开源组件。SCA（软件成分分析）工具会解析依赖树，比对已知漏洞库，识别出存在风险的间接依赖，同时检查许可证合规性。近年频发的供应链投毒事件已经证明，这道防线的优先级不亚于业务代码本身的安全。 第四道防线在部署与运行阶段，由 DAST 动态扫描、容器镜像扫描、基础设施即代码（IaC）配置检查共同构成。它们负责捕捉那些只有在真实运行环境中才会暴露的问题：错误的存储桶权限、暴露的管理端口、未加固的容器基线。 要让这四道防线真正跑起来，关键在于把安全检查嵌入 CI/CD 流水线并设定合理的阻断策略。全部漏洞一律阻断会让流水线频繁失败、开发者产生抵触；完全不阻断则形同虚设。较务实的做法是分级处理：高危漏洞直接阻断合并，中危记录并限期整改，低危仅做提示。同时必须持续治理误报，一个误报率居高不下的扫描器，最终一定会被团队集体忽略。 安全不是某个团队的专属职责，而是研发流程的内建属性。当安全检查像单元测试一样成为提交代码的默认动作，DevSecOps 才算真正落地。