5.1 安全开发生命周期

5.1 安全开发生命周期

本节摘要：安全开发生命周期（SDL）不是一套文档，是一份日历——它规定在软件交付的每个阶段该做什么安全动作、产出什么、谁来签字。本节从"修一个缺陷的两个价钱"讲起，走完各阶段活动，重点示范威胁建模的操作方法，最后给出小团队也能落地的轻量版 SDL。

修一个缺陷的两个价钱

行业里有个反复被验证的观察：同一个设计缺陷，在图纸阶段改，一次评审会的事；上线后改，可能是一轮紧急发版加一次数据迁移加一份用户通告。价钱差出两个数量级的根源是依赖——设计阶段缺陷只是图纸上的一条线，上线后它的周围已经长满了依赖它的代码、数据与流程，改动牵一发动全身。

SDL 的全部逻辑就建立在这条成本曲线上：把安全动作前置到依赖最少的阶段。它不是要开发人员变成安全专家，而是让安全专家的知识在正确的时点进入流程——需求阶段问对问题，设计阶段建好模，编码阶段给对工具，测试阶段用对靶子，上线后留好退路。

各阶段的安全活动

需求阶段：安全需求与业务需求同场提出。问三个问题：这个功能处理什么级别的数据（接第三章分类分级）、谁有权用它、被滥用时最坏会怎样。产出是带安全需求的需求文档——"必须支持导出"旁边就要写上"导出权限仅限角色 X 且需二次确认"。

设计阶段：威胁建模的主场，下一小节展开。产出是威胁清单与缓解设计，评审时与架构评审（第二章）合并进行。

编码阶段：给开发递工具而非递说教——安全编码规范的检查器、默认开启的静态分析、框架级的防注入能力。让安全写法成为最省力的写法，规范才有生命力。

测试阶段：靶子要对。动态测试打的是运行中的真实应用，依赖组件扫描查的是"借来的代码"（开源依赖的已知漏洞），两者与静态分析互为补充——静态看代码，动态看行为，依赖看生态。测试用例里要有负向用例：无权限访问、越权遍历、畸形输入。

发布与运行阶段：上线检查单（配置基线、密钥就位、日志接通）与回滚预案。安全不是发布检查单的旁听者，而是签字方之一——上线评审里安全有一票，这一票的标准应当事先写明而不是临场发挥。

图 5-1：SDL 各阶段活动与成本曲线

威胁建模：一次完整示范

威胁建模是 SDL 里最能体现"设计阶段便宜"的动作。操作四步：画图、找边界、列威胁、定缓解。拿一个"用户上传发票并申请报销"的功能做一遍。

画图：把数据流画出来——用户浏览器到上传接口，接口到对象存储，处理服务从存储取件，结果写进报销数据库。找边界：信任边界画在"用户与系统之间"与"处理服务与用户上传内容之间"——后者常被漏掉：上传内容是不可信输入，处理服务解析它时要当敌情处理。列威胁：沿每条数据流与每个边界问四类问题——假冒（伪造他人身份提交报销）、篡改（改包替换金额）、抵赖（事后否认提交过）、信息泄露（遍历他人的发票）。定缓解：逐条对号——身份用会话强校验，金额以服务端计算为准不信客户端，提交记录带操作留痕，文件访问做对象级授权防遍历。

这场建模的产出是一张威胁清单表，每条威胁挂一个缓解措施与责任人，进设计评审一起过。它的价值不在形式，在"把安全问题提前变成设计问题"——上面四条缓解若是上线后被渗透测试发现，每一个都是一次事故通报。

轻量版 SDL 与常见误区

小团队照搬大厂全套 SDL 会窒息，裁剪的原则是"保产出物、删仪式感"：需求安全三问并进需求评审；威胁建模保住新功能必做、复杂变更必做两条硬线；编码阶段静态分析默认开；测试阶段依赖扫描与动态测试进流水线自动跑（5.4 展开）；上线检查单一页纸。五个产出物，够了。

三个高频误区。误区一："SDL 是安全团队的事"——SDL 的执行主体是开发团队，安全团队提供工具与评审，主体错位则 SDL 必然空转。误区二："威胁建模太费时间"——一次新功能的建模通常一小时内，一次上线后事故的处置平均远超于此，这是笔好账。误区三："有了扫描工具就不用 SDL"——工具查得出已知模式的漏洞，查不出"这个功能根本不该这么设计"，后者只有建模能拦。

安全需求的写法：从口号到验收

需求阶段的安全三问常败在落笔环节——写出来的安全需求像口号（"系统必须安全可靠"），开发无从实现、测试无从验证。合格的安全需求长什么样？拿"用户可导出自己的订单数据"这个功能做示范。口号式写法："导出功能要防止数据泄露。"可验收的写法拆成三条：其一，导出权限仅限数据本人，管理员代查需走审批并留痕；其二，导出文件含敏感字段时加密压缩，提取码另行通道发送；其三，导出接口按用户限流，单日上限明示。三条各对应一个可执行的测试用例——这就是"带验收口径的安全需求"。

写法的诀窍只有一个：把每条安全需求翻译成"谁在什么条件下能/不能做什么，怎么验证"。翻译不出来的需求要么是废话要么是目标，都进不了 SDL 的流水。给团队立一个格式约定（安全需求模板三个字段：约束、验收、责任），需求质量立刻上一个台阶。

SDL 落地的度量：怎么知道它活着

SDL 最常见的死法是无声的：没人反对、没人执行、慢慢没人提起。所以它需要两个生命体征监测。第一个是覆盖率：新功能里做了威胁建模的比例、需求文档里含可验收安全需求的比例——各团队每月一晒，覆盖率低的团队进帮扶名单而不是批评名单（低覆盖通常是能力问题不是态度问题）。第二个是逃逸率：上线后由渗透测试、赏金计划、事故复盘发现的缺陷里，多少本可以在设计阶段拦下——逃逸率逐季下降，说明左移真实发生；逃逸率居高不下，说明建模动作走了过场。

两个指标都不追求高薪汇报级别的漂亮，追求的是真实与趋势。SDL 是长跑，度量是为了让组织看见它在动，看见才会投入，投入才能形成正循环。

与云责任模型对齐：SDL 的云上增量

上了云，SDL 的活动清单要多出几项云特有的检查，它们都来自责任分界线的客户侧。设计阶段多一问：选用的托管服务配置项里哪些属于我的责任（PaaS 的鉴权配置、托管数据库的审计开关）；编码阶段多一项：密钥不进代码仓库，改走密钥服务注入（1.2 的控制面教训）；上线检查单多两行：IaC 模板过了静态基线扫描没有（2.4）、生产配置与模板有无漂移。云不改变 SDL 的骨架，改变的是检查对象——从"我写的每一行代码"扩展为"我配的每一个服务"。

本节要点回顾

• 缺陷越左越便宜：SDL 的经济逻辑是设计的缺陷设计期修，成本差以十倍计。
• 五个产出物撑起轻量版：需求三问、威胁建模两条硬线、静态分析默认开、扫描进流水线、一页纸上线单。
• 威胁建模四步：画图、找边界、列威胁、定缓解，产出是威胁清单表而非会议纪要。
• 安全需求要带验收口径：翻译成"谁在什么条件下能或不能做什么、怎么验证"，翻译不出的需求进不了流水。
• 两个生命体征：覆盖率看左移广度，逃逸率看左移实效；度量是为了让组织看见它在动。

一个延伸之问：遗留系统没有需求阶段怎么办

SDL 的活动挂在需求、设计、开发、测试、上线五个阶段上，遗留系统的维护往往只有"改 bug 加发版"，五阶段名存实亡——SDL 在这类系统上怎么落？答案是挂在变更上而不是挂在阶段上：任何进生产前，威胁建模保住"改动涉及新输入输出必做"一条硬线，静态扫描与依赖扫描照跑，上线检查单压缩到三问（动了什么数据流、新权限、新凭据）。遗留系统补不了全套流程，但每一次变更都该过最小闸门—— SDL 的精神是"变更必检"，不是"文档必全"。这一问在考试里的变体是"维护模式下的系统应当保留哪些安全活动"，答题就按最小闸门组回答。

方法有了节奏，下一节走进云时代最大的单一攻击面：API。