1. SDL到底在解决什么问题从一次线上事故说起有段时间我所在的团队上线了一个面向外部用户的文件上传功能。功能本身不复杂前后端联调也算顺利产品验收也通过了。然而上线两周后的某天凌晨监控平台突然报警——某个存储桶里出现了大量不属于业务范畴的陌生文件。排查后发现有人利用上传接口的扩展名校验漏洞直接塞进了一个可执行脚本然后通过CDN域名把它当作静态资源成功访问到了。那件事真正让人后背发凉的不是被塞进了什么文件而是整个研发过程中没有任何一个环节提示过这里可能有风险。需求评审聊的是交互细节技术评审聊的是接口设计测试用例覆盖的是正常路径和常见异常路径唯独没有人认真想过这个功能如果被恶意使用最坏会怎样。这就是SDL——安全开发生命周期Security Development Lifecycle——存在的意义。它不是一套高深莫测的理论而是把安全这件事从上线前的安全测试提前到需求分析、架构设计、编码实现、测试验证的每一个环节里变成一套可执行、可度量、可裁剪的过程规范。简单说SDL要解决的根本问题不是出了事怎么快速修复而是怎么让漏洞在到达生产环境之前就被发现和拦截。SDL适合谁来参考我的答案是所有正经做软件研发的团队。无论你们是二十人的创业小团队还是上千人的成熟研发组织SDL的原则都能用——只是落地姿势和裁剪程度不同罢了。下面我会结合自己的实践经历把SDL的核心思想、六个阶段的具体做法、不同团队的裁剪方案以及我们踩过的真实坑一五一十讲清楚。1.1 一个典型的安全事故复盘先把刚才那个上传漏洞拆开复盘一下。这个功能的需求描述只有一句话支持用户上传图片文件并在页面展示。开发同学接到需求后常规操作是写一个上传接口校验一下文件扩展名是不是.jpg、.png然后存到对象存储返回URL。问题出在哪第一扩展名校验本身就是最弱的安全防线。攻击者完全可以上传一个内容为PHP代码、后缀为.jpg的文件只要服务器端没有把文件内容和执行环境彻底隔离就有办法利用解析漏洞或包含漏洞让它运行起来。第二文件存到CDN之后CDN并不会区分这个文件是图片还是脚本它只会按URL路径直接返回内容。只要攻击者构造一个指向该脚本的URL就能实现远程代码执行。第三整个研发流程中没有任何一个checkpoint来拦截这个问题——安全测试是上线前几天才做的那时候修改代码、重新走发布流程的成本已经很高了测试同学也只能记录在案后续优化。同类问题在业内实在太常见了。为什么常见因为大多数团队对安全的认知还停留在安全是安全团队的事是上线前测试的事。但安全漏洞的根因往往在需求阶段就已经埋下了——如果当初需求里明确写了文件需要服务端内容检测、需要与执行环境隔离存储、需要防盗链策略开发同学的设计思路会完全不同。1.2 SDL的核心思想把安全左移左移这个词在质量管理领域叫预防为主在DevOps领域叫尽早反馈在SDL里则是它的灵魂。我举个例子你马上就懂了。假设一个漏洞在编码阶段被发现修复成本是1到了测试阶段被发现因为要重新走提测、回归流程成本变成了5到了生产环境被利用、造成数据泄露再被通报成本就是100甚至更多。SDL做的所有事情本质上都是在想尽办法把发现漏洞的时机往左挪——越早发现修复越便宜。这个思想听起来简单真正做到却非常难。难在三点一是意识问题。大多数开发者没有接受过系统的安全编码培训他们不是故意写出漏洞而是根本不知道这样写会出问题。SDL里的安全培训环节解决的就是这个认知盲区。二是流程问题。传统研发流程里安全是一个体外环节。产品经理写需求不写安全需求架构师画架构图不画信任边界开发写代码不做安全自测测试只测功能不测安全。SDL要求把这些活动全部内嵌到现有研发流程里每个阶段都有明确的安全交付物和检查点。三是度量问题。不度量就无法管理。SDL强调用漏洞密度、修复时长、绕过率等指标让团队直观看到安全投入带来的变化这样才可持续发展而不是靠一腔热血。1.3 SDL不是流程枷锁而是成本控制工具很多人一听到安全开发生命周期第一反应是又要多写一堆文档又要被安全团队卡脖子。这个印象可以理解因为确实有一些团队把SDL做成了形式主义——需求文档里复制一段安全要求设计文档里画一张威胁数据流图然后就没人看了。但真正的SDL本质是一套成本控制工具。再说得直白一点SDL让你在早期用较低的成本把问题拦住避免在后期用高昂的代价去补洞。这和质检不是生产线的敌人而是帮生产线省钱的伙伴是一个道理。如果你发现自己团队的SDL流程只增加了负担、没降低风险那一定是落地方式出了问题而不是SDL这个理念有问题。2. SDL的六个核心阶段每个阶段到底该做什么接下来进入正题。SDL通常被划分为六个阶段我按实际落地顺序逐个拆解需求阶段、设计阶段、开发阶段、测试阶段、发布阶段、响应阶段。每个阶段我都会说清楚要做哪些事、产出什么、由谁负责、怎么判断做得好不好。这个框架不是我凭空发明的它脱胎于业内成熟的软件安全保障实践后来在各行各业的软件研发团队里被反复验证和裁剪。我结合自己在多个项目里的落地经验重新整理成了下面这套相对完整的版本。2.1 需求与设计阶段威胁建模才是重头戏需求阶段的SDL活动在国内很多团队里是空白。大家总觉得需求就是业务功能跟安全有什么关系。但恰恰是需求阶段决定了后续所有安全工作的方向和力度。先说说需求阶段具体该做什么。第一件事识别安全需求。每一个功能需求都应该附带回答几个问题这个功能是否涉及用户隐私数据是否涉及资金交易是否会被未授权的人访问是否需要审计日志我和团队的做法是在需求模板里增加一个安全需求栏目不填不许过评审。不用填得很复杂就两三句话比如该功能需要登录后访问用户上传文件需做类型校验和内容检测所有删除操作需记录操作人。这样做的好处是开发在写代码时至少有一个安全层面的验收标准可以对照。第二件事做风险定级。不是所有功能都值得做全套安全设计。一个纯展示类的资讯页面和一个绑定支付功能的下单页面安全投入应该完全不一样。我们内部参考了通用的风险分级思路把需求划分为高、中、低三个风险等级。高风险功能必须在设计阶段做完整的威胁建模和专项安全评审中风险功能至少做威胁建模的轻量版低风险功能则可简单登记处理。这个分级机制很重要它决定了你的安全资源会不会被琐碎事务消耗光。设计阶段的SDL活动核心只有一个词威胁建模。威胁建模这个词听起来很唬人其实说白了就是一件事——在设计阶段系统性地想一想我这个系统会被谁攻击通过什么方式攻击攻击成功后会有什么后果然后针对想出来的每种攻击方式在设计上预先布置防线。我见过很多团队做威胁建模就是画一张数据流图标几个攻击者箭头然后就交差了。这是典型的走形式。真正有效的威胁建模应该至少回答这四个问题信任边界在哪里系统内部哪些模块互相信任哪些不能比如用户输入的数据从进入系统那一刻起就应该被当作不可信。攻击面有多大攻击者可以触及哪些接口、协议、入口每多一个入口就多一份需要防护的责任。最坏情况是什么如果某个模块被攻破能影响到什么系统、什么数据这决定了你在哪个点必须做最严格的控制。我们的技术栈里有哪些已知的坑比如某个版本的框架有已知反序列化问题比如某种存储方案默认配置不安全这些在设计阶段就要避开。威胁建模的产出物是一份威胁清单每一项至少包含威胁描述、受影响资产、攻击难度、潜在影响、缓解措施。这份清单不是说写完就扔的它要作为设计文档的一部分后续的开发和测试阶段随时对照。我们团队曾经接过一个第三方登录集成需求。一开始业务方只想直接跳转OAuth授权拿回用户信息就完事。做威胁建模时我们问了一个问题如果回调地址被恶意拼接允许攻击者指定任意redirect_uri会怎样这一问就引出了开放重定向和授权码劫持的问题。于是设计里加了固定回调地址白名单、state参数校验、以及授权码一次性使用等机制。你看如果没有威胁建模这个环节这些问题大概率要等上线后被人利用才会发现。2.2 开发与测试阶段工具只是助手人才是关键开发阶段SDL的落地抓手是三个安全编码规范、静态分析工具、同行评审。安全编码规范不需要自己从零写一份业内有很多现成的资源可以参考。不过规范不是拿来装样子的关键是让开发能真正用上。我们的做法是把规范里最常见的几十条整理成一张红牌清单比如SQL查询必须使用参数化查询文件上传时必须校验MIME类型且重命名存储日志里不得打印完整密钥和用户身份证号。开发在提交代码前先对照清单自查一遍成本很低效果却很实在。静态分析工具SAST这块市面上可选的产品不少开源的和商业的都有。工具好不好用不只看检出率还要看误报率。我见过有团队上了一个扫描工具每次提交代码跑出两三百条告警开发看一眼头就大了直接把工具报告忽略等于白装。我们的经验是工具刚上线时可以先关掉告警里的低危项和部分误报项优先把中高危、误报低的规则打开跑一段时间稳定了再逐步放开。宁可先少报也不要让开发对工具失去信任。同行评审这个环节很多团队其实一直在做只是没把它定位为SDL活动。代码评审时建议增加一个安全视角的checklist这个改动涉及用户输入吗输入有没有做校验错误信息有没有泄露敏感信息这次改动的数据流向是什么有没有经过权限校验评审人不需要是安全专家只需带着这几条基本问题去看代码就能拦下一大批低级问题。到了测试阶段SDL的标配动作是动态分析DAST、安全回归测试和渗透测试。DAST和SAST的区别简单说SAST是静态地读源码找漏洞DAST是把系统跑起来从外面模拟攻击者的输入看系统会不会异常。前者适合在开发阶段用后者适合在测试阶段用。很多商业DAST工具可以录制定单场景、回放并自动变换攻击载荷跑起来挺省事的。渗透测试这件事很多团队纠结要不要请外部团队做。我的建议是高风险功能、涉及资金的系统在上线前至少做一次由外部团队执行的黑盒渗透测试。内部自己做也可以但有个天然的短板——自己看自己容易有熟悉感带来的盲区。请外部团队相当于是换了一双不认识你的眼睛来看你的系统往往能找到你想都没想过的路径。安全回归测试指的是把历史漏洞整理成一个自动化测试用例集。每修完一个漏洞就把触发它的payload固化进回归测试集里确保这个漏洞不会被改代码时改回来。这一点我们一开始没重视结果吃过亏——某个目录穿越漏洞修好半年后因为一次重构又复现了而且是因为同一个原因非常尴尬。2.3 发布与响应阶段别忽略最后一公里发布阶段的SDL活动很多人以为就是上线前安全测试通过。其实不够。至少还有三件事要做一是配置安全审查。很多时候代码本身没漏洞但部署配置是裸奔的。比如存储桶的读写权限设成了公共读写比如数据库端口直接暴露在公网比如管理后台用默认口令。这些属于运行时环境的配置问题光看代码发现不了必须在发布前核对一遍部署清单。二是上线前应急预案。这个功能上线后如果被人攻击了你怎么发现怎么止血响应联系人是谁有的团队会说我们系统有监控出事了会告警。但告警之后呢有没有应急手册有没有人知道第一时间登录哪台机器、执行哪个命令、做哪个操作这些如果没定义好即使发现攻击也大概率会因为慌乱而耽误最佳处置时机。三是安全发布记录。这次发布包含哪些安全变更修复了哪些漏洞有没有引入新的组件记录起来一方面是为了追溯另一方面也是为后续的安全审计和合规检查提供依据。响应阶段就是SDL闭环的最后一环。这部分重点是建立一套漏洞响应机制包括漏洞接收渠道比如安全联系人邮箱或平台工单、漏洞定级标准、漏洞修复SLA、漏洞披露流程。说实话大部分团队在响应阶段的建设是最薄弱的通常就是被动地在等外部白帽子发邮件。我建议至少把内部漏洞报告渠道打通——让测试同事、运维同事发现问题后知道往哪里报、按什么模板报、多久会被处理。这个看似简单的机制能极大减少漏洞烂在私人聊天记录里的情况。3. 落地SDL的团队裁剪实践不同规模团队怎么选这一章我想聊点实战的东西不同规模的团队到底应该怎么裁剪SDL。说实话全套SDL在业界被执行的完整度并不高大部分团队执行的是裁剪版。裁剪是合理的因为SDL本质上是成本投入小团队承担不起大团队那种复杂的流程。但裁剪不是乱裁要注意一个原则核心控制点不能丢可以减形式不能减效果。我按团队规模给你三个参考方案。3.1 轻量级裁剪小团队也能跑起来的SDL如果你是二十人以内的小团队没有专职安全人员开发就是测试就是运维那你的SDL级别应该追求极简但关键。我们给这类团队的推荐配置是需求阶段只在模板里加一个安全自检栏目不问安全需求只要求开发自己勾选并简单说明。设计阶段仅对高危功能做一次口头版威胁建模大概花半天时间拉上研发负责人一起过一遍就能散会。开发阶段SAST工具必须有选开源免费方案就行接入CI/CD每次提交自动扫。代码评审时增加三条安全checklist。测试阶段高危功能上线前做一次手工安全用例测试。这个用例集可以提前准备好比如越权访问非法输入接口频率限制这些通用场景直接套用。发布响应配置审查用部署清单模板应急响应至少定义一个人作为联系人并留一次演练。这个方案的好处是几乎不增加多少流程负担但把最危险的功能兜住了。我见过不少小团队用这套方案跑了大半年虽然没有专职安全人员但高危漏洞的引入率明显下降——因为SAST工具在编码阶段就拦掉了一大批低级问题威胁建模让设计阶段就排掉了一堆结构性风险。3.2 中等规模团队的SDL补齐过程证据当团队规模到了五十到两百人有独立的测试团队也有可能在筹建安全团队时SDL的裁剪就要比小团队严格一些了。这个阶段的团队最大的痛点是人多之后口头沟通跟不上了很多安全决策没有沉淀。中等规模团队的SDL升级点主要是三层第一层是文档化。威胁建模的产出物从口头讨论升级为简短的结构化文档安全需求从勾选变成必须填写具体的安全验收标准漏洞回归测试集也纳入测试用例管理平台统一管理。这些文档不需要长但一定要能追溯。第二层是角色化。引入一个安全责任人概念。不是说要有专职安全工程师而是每个产品或模块指定一个人负责安全需求的传递、威胁建模的组织、安全测试结果的跟进。这个人可以由研发骨干兼任但要有明确的职责定义。第三层是流程化。安全测试从上线前突击一次变成每个迭代固定执行。比如每个迭代的安全测试时间点在提测后、发布前两天高危功能必须测试通过才能发布中危问题可以有条件发布并记录跟踪低危问题可以发布后修复。这个阶段还需要开始积累安全数据每个迭代发现了多少漏洞、修复时长多久、漏洞集中在哪个模块、哪类漏洞最多。积累两三个迭代之后你就能看到规律从而把安全工作聚焦在最疼的地方。3.3 成熟团队的SDL迈向平台化与自动化两三百人以上的团队或者安全团队已经独立运作的团队SDL的落地方式会再上一个台阶核心特征是平台化和自动化。具体来说在这个阶段你会看到这些实践统一的安全网关。所有代码仓库接入统一的SAST、DAST、依赖扫描、容器镜像扫描平台扫描结果自动汇总到同一个安全看板。威胁建模工具化。用在线白板或专门的威胁建模工具模板来引导研讨输出结果自动关联到需求条目。安全门禁。高风险模块的扫描结果必须全部清零才能合并中危漏洞有明确修复期限超时自动升级依赖扫描发现高危漏洞时CI流水线直接阻断。安全数据度量。用漏洞逃逸率——即流转到生产环境才被发现的漏洞占比——作为核心指标。通过这个指标反推前面哪个阶段存在薄弱环节针对性改进。说实话成熟团队的SDL已经不只是流程了更像是一套安全质量基础设施。但我要提醒一句平台化最大的风险是把工具当流程就是一切看起来很自动化、很完善实际上团队完全不理解每一项检查是在防什么。自动化流程的价值应该建立在每个参与者都理解它、相信它的基础上。否则团队会在紧急发布时找各种理由绕过门禁而门禁一旦绕过整套体系就会像多米诺骨牌一样垮掉。4. SDL落地中最容易踩的四个坑讲完理论框架和裁剪方案这一章来点真正有嚼劲的——我们在实践过程中踩过的坑以及我看到的同行们踩过的坑。每一条背后都有真金白银的教训希望能帮你绕过去。4.1 坑一威胁建模流于形式画完图就算完事这是最普遍、也最要命的一个坑。很多团队听到威胁建模四个字第一反应是我们画一个架构图吧。于是架构师在图上画了几个方框、几个箭头标注了用户应用服务器数据库然后……就没了。既没有分析攻击路径也没有形成威胁清单更没有设计缓解方案。严格说这不是威胁建模这只是画了张架构图。为什么会这样因为威胁建模是一个反人性的思考过程——它要求你在系统还没建好的时候去深入思考它怎么被搞坏。这和大多数人建设性思维的习惯是冲突的。再加上没有执行引导大家自然就选择了最简单的形式交差。我们后来的改进是引入STRIDE模型作为思考引导。STRIDE把威胁类型分成六类仿冒Spoofing、篡改Tampering、否认Repudiation、信息泄露Information Disclosure、拒绝服务Denial of Service、权限提升Elevation of Privilege。针对每一个信任边界按这六个维度逐个问一遍这里能不能被仿冒能不能篡改数据操作能不能被否认会不会泄露信息能不能打DoS能不能提权有这样一个检查框架在手里讨论才不会跑偏。另外一个很关键的做法是威胁建模会议必须有记录员并且必须产出缓解措施行动项。每个行动项要落到具体的人、具体的截止日期、具体的验证方式。如果一个威胁建模会议开完没有产出行动项那基本等于白开。4.2 坑二安全工具告警一堆但没人真正处理这是几乎所有团队在引入SAST/DAST之后遇到的第一个大难题——告警过剩处理疲劳。想象一下这个场景你满怀期待地给CI/CD里接了一个代码扫描工具第一次全量扫描跑出了800多条告警。开发一看头都大了这里面有好多是误报有好多是历史遗留代码的问题还有好多是低优先级问题。他们不知道从哪里下手也不知道怎么和工具和解——于是干脆忽略整个报告。从此这个工具就变成了一个只会发邮件骚然大家的摆设。这个问题的解法我们的经验是渐进式治理分三步走第一步基线化。第一次扫描结果不要求清零而是全部记录为历史存量问题基线。从这一天开始新提交代码出现的增量告警才被纳入考核。这能避免团队在历史债务里挣扎集中精力看新增问题。第二步规则分级。把告警规则按严重程度和误报率两个维度分成三个等级。第一等级是严重且误报低的规则强制修复第二等级是严重但误报中等的规则人工确认第三等级是低危或误报高的规则先关闭不看。第三步告警分流。每次提交的增量告警直接通过机器人推送到代码提交者的IM消息里并附带修复建议链接。有的告警是规则能自动理解的比如参数化查询工具可以给出具体的修复示例开发照着改就行有的告警则需要上下文理解比如越权问题这类要靠人工分析。分流之后真正需要人工介入的告警大概只剩两成负担小很多。你别小看这渐进式治理我们实践下来工具的接受度提高了不止一个档次从没人理变成了每次提交后主动看告警。这个转变是整个SDL体系能持续运行的重要基础。4.3 坑三SDL流程与迭代节奏冲突逼得团队绕流程走另一个高频坑是SDL流程设计的节奏和团队的迭代节奏脱节导致流程被绕过。举个最常见的例子有的团队规定所有上线必须经过安全测试工程师审批。但安全测试资源有限每个迭代的发布窗口就那么多一旦安全测试排队发布就得等。业务压力一大团队就会想尽办法绕过这个审批——比如走紧急发布通道、先上线后补流程。只要发生过一次绕过SDL的公信力就没了后面再想严格执行就难了。这个问题的本质是SDL的设计没有融入团队的既有工作节奏而是作为一个外部卡点强硬插入。解决思路有两个一是分级审批高危功能和核心链路才需要人工安全审批低中危功能自动化检查通过即可上线。把有限的人工安全资源用在刀刃上。二是把安全活动嵌入到现有的会议节奏里。比如团队每周一开迭代计划会那就把安全需求讨论放进这个会的固定议程里不是另开一个安全会。团队每周三做代码评审安全的checklist就在这个评审会里一起过。SDL活动不应该是一个个新增的额外动作而应该是在已有活动里面加上安全视角。这个思路我们称之为附着力原则——让安全附着在既有流程之上而不是悬浮在流程之外。4.4 坑四重文档、轻文化SDL只剩一堆模板最后一个坑其实前面已经几次提到过就是形式化大于实质。我见过一些团队SDL文档写得非常完善——几十页的安全规范、详细到每个角色职责的流程图、各种模板和checklist、定期的安全审计报告。但你去问一线开发你知道你们团队的安全规范里文件上传有哪些具体要求吗大概率是一片沉默。这就是文档和文化的脱节。SDL落地到最后最难的不是把流程规定下来而是让每个参与研发的人从内心深处真正认同安全是我工作的一部分。这不是靠制度压出来的而是靠一件件小事慢慢养成的当开发因为威胁建模的原因改了一份本来够用的设计并且事后真的避免了一个漏洞时他会真正认同威胁建模的价值。当测试因为安全回归用例而拦住了一个旧漏洞复发时他会真正认同安全回归测试的价值。当团队领导在复盘时不是追责谁写了漏洞而是分析流程哪个环节没拦住大家才会愿意暴露问题而不是隐藏问题。所以我的建议是你在推进SDL时可以把文化建设的优先级提到所有具体活动之上。不要急着一次把SDL的全部六阶段都落地而是先从一两个最有价值的活动做起把它做好做扎实让团队看到实际效果再逐步扩展。一次只改一点每一次改变都让团队感受到安全投入是值得的。5. SDL与DevSecOps的关系它俩不是二选一现在技术圈最火的词是DevSecOps很多人会问SDL是不是已经被DevSecOps取代了我的回答很明确没有它们根本不是同一维度的东西而是互相成就的关系。5.1 从SDL到DevSecOps演进逻辑是什么简而言之DevSecOps可以理解为SDL在敏捷和DevOps文化下的一种演进形态。SDL诞生的时候软件研发的主流模式还是瀑布式或重流程的。SDL的六阶段像一条装配线每个阶段有明确的出入口安全活动按顺序插入。这套方法在重流程的时代可行而且行之有效。但到了敏捷和DevOps时代迭代周期缩短到两周甚至一周每天可能发布好几次如果还按每个迭代先做威胁建模、再做安全设计、再做安全测试这种串行方式流程根本跑不过来。DevSecOps的思路则是把安全能力揉进流水线把SAST、依赖扫描、容器扫描等都作为流水线中的一个自动化步骤每次代码提交自动执行规则可配置结果可联动阻断安全不再是阶段性活动而是持续过程。这么一看就明白了——DevSecOps的精髓在于自动化和持续而SDL的精髓在于结构化和全面。最理想的体系是以SDL的六阶段框架作为思考骨架以DevSecOps式的自动化工具体系作为执行肌肉。5.2 在CI/CD流水线里落地SDL活动最后分享一个我们目前在用的、比较实用的CI/CD集成方案作为整篇内容的落地参考。先说流水线里的安全节点从代码提交到上线我们挂了八个动作提交前开发者本地用IDE安全插件自查主要做高危API的即时提示。这一步有最好不强制作为开发者习惯的一部分。代码推送后触发SAST扫描和依赖扫描。SAST跑增量代码依赖扫描检查新增依赖是否存在已知漏洞。这一步会阻止合并请求除非高危清零。代码合并后触发镜像扫描。因为我们用容器化部署镜像打包之后、推送仓库之前会自动扫基础镜像和依赖包。高危漏洞阻断中危告警人审。测试环境部署后DAST工具对测试环境做自动扫描主要扫常见Web漏洞。测试环境是内网扫描不产生真实风险。发布前审批高危功能人工审批一个轻量级的审批页面引导审批人逐项对照安全checklist确认。生产环境上线后开启RASP运行时应用自我保护监控。RASP像是在应用内部装了一个安全哨兵能够实时检测到利用漏洞的攻击流量并拦截。定期巡检web漏洞扫描器对生产系统做定期巡检发现配置漂移或新出现的风险。应急响应漏洞报告入口、响应SLA、修复验证流程全部纳入工单系统。你看这套体系里SAST、DAST、依赖扫描、镜像扫描、RASP这些工具层面的东西是DevSecOps化的——自动化、持续化、嵌入流水线而威胁建模、安全需求评审、安全回归测试这些思维层面的东西还是SDL式的——需要人参与、需要结构化思考、需要在设计阶段提前介入。这两者并不矛盾。用SDL的框架去规划什么时候需要人介入做什么判断用DevSecOps的方式去解决哪些重复劳动可以交给机器自动执行这才是现代软件团队落地安全体系的正确姿势。从个人实操看我一直觉得推进SDL落地最有效的套路不是从某份教科书上搬来全部活动而是先静下心盘点自己团队最痛的三个安全问题然后把SDL的工具箱里对应的那几件工具拿出来用最轻量的方式放进现有流程里跑起来、见效了、再扩。安全建设永远不会一步到位但它值得一步一步做扎实。
