安全左移讲了这么多年真正把功夫下到需求阶段的团队其实比想象中少得多。大多数安全团队还停留在给开发提漏洞、给测试出用例的阶段安全活动集中在研发流程的中下游即便想改也总觉得无从下手。我自己在推动这项工作的过程中体会到需求阶段做威胁建模是性价比最高、也能最早暴露风险的一项投入它能直接改变安全在项目里的位置。先说清楚需求阶段的威胁建模不是让安全工程师替产品经理写需求也不是逼研发在开会时多填一张表。它的本质是把安全相关的决策点前置到这个系统到底要做什么的环节里——因为只有在这个环节架构还没定型、技术选型还没锁定、业务逻辑还在白板上画的时候改动成本最低、方案选择空间最大。等代码写完之后再谈威胁基本只剩妥协和补丁了。1. 先理解安全左移为什么需求阶段成了关键战场1.1 安全左移的核心逻辑安全左移Security Left Shift这件事说穿了很简单把安全活动从软件开发生命周期SDLC的右侧也就是测试、部署、运维阶段往左侧移动——需求分析、系统设计、编码阶段。越早介入漏洞修复成本越低这是所有人都认可的朴素道理。但为什么大家都在讲左移真正落地的却少我总结下来卡点不在技术而在两个认知偏差第一个偏差是安全就是找漏洞所以很多人觉得左移就等于让安全工程师提前去review代码第二个偏差是需求阶段没有技术细节觉得让安全介入需求讨论完全无从下手。这两个偏差都源于对威胁建模的理解不够——威胁建模恰恰是连接业务需求和安全隐患之间的那座桥。我见过统计数字说在需求阶段修复一个安全问题的成本是上线后修复成本的1/50甚至1/100。单看这个数字大家都会点头可一到实际操作产品经理觉得安全拖慢迭代研发觉得模型画图没时间安全团队自己也不知道从哪一步切入。这些问题不是方法论的问题是执行路径的问题。1.2 为什么选需求阶段而不是设计阶段这里有一个很实际的区别设计阶段的威胁建模输入是架构图和技术方案关注的是系统这么搭会不会出问题需求阶段的威胁建模输入是业务目标、用户故事、数据流意图关注的是系统要做这些事哪些地方天然就是风险点。这两个阶段都有价值但我更推荐把第一轮威胁建模放在需求阶段原因有三点第一需求阶段的数据流是期望中的数据流还没有被技术实现细节污染安全人员可以更纯粹地看清楚谁在什么场景下、通过什么方式、访问什么数据、期望得到什么结果。技术方案定了之后再看很多风险点已经带上了现状约束讨论空间会小很多。第二需求阶段的干系人最全。产品经理、业务方、架构师、研发负责人、测试负责人都在这张桌子上。你在这个节点提出安全约束大家会把它当成需求的一部分等你到了设计阶段再提就变成了对其他人的追加要求心理接受度完全不同。第三需求阶段可以通过威胁建模反向优化需求本身。这句话听起来有点玄但实际工作中经常发生一次建模讨论会暴露出这个需求根本不该收集用户手机号这个权限设计是有问题的这个接口必须限制频率等等。这些不是技术问题是需求问题但安全团队在需求阶段把它们挡下来了。2. 威胁建模的基本方法论别一上来就画图2.1 从STRIDE开始理解威胁分类威胁建模的理论框架有好几种STRIDE、攻击树、攻击图、LINDDUN隐私威胁建模、OCTAVE等等。作为需求阶段的切入点STRIDE绝对是最合适的第一站——它不要求你先把系统架构画到多精细而是提供了一套从威胁类型出发的找茬清单。STRIDE是六个英文单词的缩写Spoofing伪装攻击者假装成别人对应身份认证问题Tampering篡改数据在传输或存储中被修改对应完整性Repudiation抵赖用户否认自己做过某个操作对应不可否认性Information Disclosure信息泄露数据被不该看的人看到对应机密性Denial of Service拒绝服务系统资源被耗尽或不可用对应可用性Elevation of Privilege权限提升普通用户拿到了管理员权限对应授权这六类威胁几乎覆盖了安全需求的所有维度。在实际需求评审中我会带着团队把每条需求都过一遍STRIDE不需要刻意去记每个词的英文全称关键是要养成从这六个角度看事情的思维习惯。举个例子一个用户上传头像的需求。用STRIDE一套Spoofing能不能伪造某个用户上传头像——需要登录态绑定Tampering上传的头像文件能不能被篡改格式、植入脚本——需要文件类型校验和存储隔离Repudiation用户上传了违规图片后否认——需要后台记录上传者、时间、IPInformation Disclosure头像是否暴露了用户隐私比如GPS信息写在EXIF里——需要处理元数据DoS上传接口能不能被恶意刷爆——需要限流和文件大小限制Elevation of Privilege能不能上传带恶意内容的文件影响服务器——需要防病毒扫描和权限隔离一个简单的上传需求用STRIDE框架一梳理六类风险各有一到两个问题点。而这些不需要看到一行代码就能得出需求阶段完全够用。2.2 数据流图DFD的低配玩法很多讲威胁建模的资料都会强调画数据流图然后给出一堆标准和符号。在实际需求阶段我建议各位不要被这些形式化要求拖住。在需求讨论会上最有效的方式是在会议室白板上画出谁——通过什么方式——和系统交互——系统内部怎么流转——最终落到哪的粗线条图。这里不需要画到什么Level 0、Level 1、Level 2的严谨分层我只需要几样东西外部实体用户、管理员、第三方系统、定时任务核心进程登录认证、业务处理、数据存储数据存储数据库、缓存、文件存储、消息队列数据流线条谁发起什么请求、数据经过哪些节点然后围绕这张图问三组问题哪些节点是攻击者可以直接接触到的暴露面数据从进入到存储经过了多少跳转和转换数据信任边界每条数据流上有没有身份验证、权限校验、审计日志安全控制点这三组问题问完之后一个系统的安全画像基本就清楚了。需求阶段的DFD不需要精确到哪个类调用哪个方法它只需要帮大家认清数据从哪来、经过什么处理、存到哪里、谁在什么时候能碰到它。这个层面的理解对需求决策来说足够了。2.3 攻击树和攻击库的辅助用法STRIDE适合系统性地覆盖威胁类别攻击树的用途则更适合针对某个具体资产或功能往深里挖掘攻击路径。打个比方STRIDE像体检时的全科筛查攻击树像发现某项指标异常后做的专项检查。需求阶段我的建议是先用STRIDE做全科筛查筛选出两三个高风险点再用攻击树做专项分析。攻击树的画法不复杂——根节点是攻击者的目标比如获取管理员权限然后向下分叉出各种可能的攻击路径弱口令爆破、会话劫持、SQL注入获取管理员token、后台逻辑漏洞等每一条分叉都可以继续延伸。在需求评审现场攻击树不需要画得多完整核心价值在于它能帮助评审团队直观地看到同一个目标有这么多种进攻方式从而更愿意接受更严格的安全需求。3. 需求阶段威胁建模的实操流程3.1 第一步确定分析范围和资产需求阶段的威胁建模最常见的失败原因不是方法不对而是范围没定准。需求文档几十页如果企图把每个功能都过一遍会议能开一整天最后所有人都疲惫不堪结论质量也可想而知。我的操作习惯是先粗略浏览需求文档和原型图圈出三类必须做威胁建模的功能涉及敏感数据的手机号、身份证、银行卡、住址、生物特征、支付信息、聊天内容等涉及资金/权益变动的下单、支付、退款、积分、优惠券、提现、后台审批等暴露面大的无需登录可访问的接口、开放平台API、第三方对接、定时任务、文件上传这三类之外的功能需求阶段先不做深度分析留到设计阶段甚至代码评审阶段再关注。这能极大压缩会议时间也能保证精力花在刀刃上。同时资产识别这个动作也很简单把需求文档里涉及的数据类型列出来给每类数据标记敏感级别高/中/低然后标注它对标哪部合规要求比如等保、个保法、支付合规不需要逐条背诵法律条文但要意识到这类数据出了问题是什么后果。敏感级别为高的数据就是威胁建模的核心资产。3.2 第二步画数据流图和识别信任边界这一步就是把上一节说的方法落入实际操作。我建议安全工程师不要自己闷头画完再拿给大家评审而是要在会上带着大家一起画。原因很简单自己画出来的图画的是你以为的系统大家一起画出来的图才是真正的系统。过程中有几个追问特别实用这个数据从用户那里收集上来之后在系统里都经过哪些服务——画数据流这些中间服务都放在哪内网还是外网——划信任边界微服务之间调用要不要鉴权——信任边界内的控制点数据库里面有这些数据吗哪些表哪些字段——识别存储谁能通过什么渠道访问这些数据——识别暴露面现场画数据流图还有个额外效果业务团队会在画图过程中自己发现问题比如这个回调接口按理说应该加签名但好像目前没设计这个第三方推送的数据好像含了手机号得脱敏。这些收获比威胁建模报告本身的价值大得多。3.3 第三步用STRIDE逐层分析威胁数据流图画完之后就到了STRIDE登场的环节。我的做法是先把数据流图拆成几个关键节点每个节点单独过一遍STRIDE然后记录下对应的威胁场景。这里要特别注意威胁场景是如果...会怎样的描述不是要做什么的对策。很多初次做威胁建模的人容易把这两者搞混——直接写这里需要加验证码这就跳过了威胁分析。正确的记录方式应该是场景1如果攻击者绕过前端校验直接构造请求提交订单是否会生成一笔无支付凭证的订单场景2如果用户A的会话token被窃取能否直接操作用户B的订单场景3如果第三方回调接口被伪造是否会改变订单状态先记录威胁场景再讨论应对措施。这两个步骤是分开的。哪怕最终大家决定这个威胁我们选择接受比如风险级别低、发生概率小、或者有补偿措施威胁也应该被记录在案因为它代表了一个有意识的决策而不是未知的风险。3.4 第四步风险等级评估和处置决定威胁清单列出来后不能都当成大事处理那样安全团队会变成业务部门的敌人。要建立一套大家都认可的风险分级标准。我用的是一个结合行业经验调整过的简易矩阵从两个维度打分影响程度和利用难度。每个维度给1-3分乘起来就是最终分值。影响程度打分视角1分影响有限比如垃圾信息、体验性问题2分影响单个用户或单笔数据比如个人账号被篡改3分影响大规模用户或核心业务比如数据库泄露、全站瘫痪利用难度打分视角1分需要高级攻击能力比如绕过WAF拿到内网权限利用0day2分需要一定条件比如需要用户点击链接、需要低权限账号3分很容易利用比如直接构造HTTP请求即可分值在6-9分区间的属于必须解决的高危项3-4分的建议在需求阶段就提出缓解措施1-2分的可以选择接受记录但需要决策人书面确认。这个分级方法不是学术标准但胜在简单透明。产品经理、研发、测试在同一个标准下讨论威胁就不会出现安全觉得天塌了研发觉得没事的鸡同鸭讲。4. 输出物威胁建模报告应该长什么样4.1 报告的定位是决策依据不是安全论文威胁建模报告最怕写成安全论文——几页纸的威胁描述配上一堆CVSS评分最后业务方看完还是不知道怎么配合。我自己的模板比较简单围绕需求决策来组织分析范围本次分析了哪些需求、哪些功能、哪些数据核心数据流图一张图清晰展示数据流向和信任边界威胁清单按STRIDE分类每条记录——威胁场景、涉及资产、影响等级、利用难度、处置建议必须修改的需求项安全团队强烈建议在需求阶段调整的条目需要在设计阶段补充方案的控制项当前不阻塞需求评审但设计时必须有方案接受登记表经过讨论决定接受的风险记录下决策人不要把所有威胁都塞进第4部分。如果一份报告里面有10个必须修改业务方大概率一个字也不想看。抓大放小把最关键的两三个问题讲透彻效果远比罗列所有问题好。4.2 需求和验收标准的联动威胁建模报告真正起作用不是也报告发出去就完了而是要把它变成需求和验收的一部分。在我的推动下现在团队的做法是威胁建模中确认必须解决的高危威胁会直接写入需求文档的安全需求章节并且会转化为测试用例的输入。比如订单金额不能通过前端参数任意修改这条威胁对应的测试用例就是修改请求参数中的金额字段验证服务端是否做了二次校验。这一步非常关键它把安全从评审时嘴上说说变成了交付时可以验证的验收标准。测试人员在写用例时有了依据研发在开发时知道了约束条件后续想赖账也找不到机会。4.3 轻量级工具选型关于威胁建模工具我有一点经验想分享工具只是辅助思维才是核心。特别是刚起步的团队我不建议一开始就上重型工具。我自己用过微软的Threat Modeling ToolMTD也用过OWASP Threat Dragon各有优缺点可以根据团队的实际情况选择微软Threat Modeling ToolMTD模板和组件库很全适合需要严谨交付物的团队但是软件界面比较老新版本的安装和维护有成本OWASP Threat Dragon开源支持画DFD和自动生成STRIDE报告Web版和桌面版都有推荐给愿意用开源工具的团队白板和Excel如果团队还处在刚开始尝试的阶段完全够用。画图用白板威胁清单用Excel表格重点是跑通流程我不建议一上来就买企业级威胁建模平台的原因很简单需求阶段的威胁建模核心价值在于对话和共识而不是报告成品和自动化程度。流程不跑通买了工具也是吃灰。5. 推动落地的关键团队协作和流程嵌入5.1 安全团队要从警察变成队友需求阶段威胁建模能不能落地首先碰到的阻力不是方法不会而是角色的接受度问题。安全团队如果平时习惯了这个漏洞不给上线的警察角色到了需求评审会上业务方的第一反应永远是你又来找茬了。我在实践里做了一件事效果很不错在需求评审会上不说这个需求有安全风险改说这个需求在数据流上有几个坑我帮你标出来你听听看处理方式合不合理。措辞的变化背后是定位的变化。需求阶段的威胁建模本质上是帮团队在设计阶段之前发现并规避问题而不是检查你有没有安全问题。这个定位摆正之后产品经理会主动邀请安全团队参加需求评审因为他们发现安全能帮他们规避返工。5.2 流程上怎么卡最小可行的嵌入方式很多安全团队的疑问是我们没有权力强制业务走威胁建模流程怎么推我建议分三步走。第一步试点先行。找两三个有敏感数据、且在近期要立项的项目带着威胁建模的流程主动介入做出案例。第二步与研发流程负责人达成共识。把威胁建模作为需求评审的一个固定环节哪怕每次只预留30分钟也要把流程固定下来。第三步用数据说话。记录在需求阶段发现的高危问题数量和预估返工成本每季度在质量复盘会上通报一次。这个推进节奏可能不快但胜在自然。流程嵌入最怕的就是强推——行政命令下来大家开会消极配合填表应付最后走个过场以后再想推就更难了。5.3 把握介入时机和时长需求阶段威胁建模不该对每个需求都做全套。我自己设定了一个判断标准有没有新数据有没有新架构有没有新的流程协作这个标准来自一个切身经历——有一次针对一个日常迭代做了全套的威胁建模花了三个小时结果分析完发现数据流和上次几乎一样威胁清单也没有新东西整个过程的价值非常有限。后来我把流程调整成轻量分钟级评审重点项目深度建模的模式轻量模式针对日常需求迭代时长15到30分钟按模板快速问一遍改了哪些数据新增哪些接口谁新增了访问权限有没有把内部数据暴露到外部如果三个问题都没有大变化本次直接通过。深度模式针对新项目、大版本或涉及支付/隐私等重点场景时长半天到一天做完整的DFD、STRIDE、攻击树和风险分级。这样做的好处是日常需求不会因为安全评审而明显放慢节奏重点项目又能得到充分的分析覆盖推进阻力小很多。5.4 让研发负责人和测试负责人成为同盟需求阶段的威胁建模不能只有安全团队和产品经理两方在讨论。研发负责人和测试负责人的参与至关重要。研发负责人能判断某个威胁场景在现有技术架构下是否真的成立测试负责人能判断某个威胁是否可以在测试阶段通过用例去验证。我的实际体会是与其说服产品经理接受某个威胁处置方案不如先和研发负责人讨论清楚方案的可行性和成本再拉上测试负责人确认可测性——这三人达成了一致方案才真正有落地的可能。安全团队在其中不是发号施令的一方而是串联各方视角的角色。6. 常见问题和踩坑实录6.1 会议变成安全一人表演这是初做威胁建模最常遇到的尴尬局面安全工程师在投影仪前滔滔不绝地讲威胁、讲STRIDE、讲攻击场景产品经理和研发全程沉默最后问大家有没有意见所有人都说你定就行。这个状态非常不健康说明威胁建模没有真正变成团队讨论只是多了一个安全宣讲环节。我解决这个问题的办法是每个威胁场景讲完之后不直接给处置建议而是先问在你们对业务的理解里这个场景真的会发生吗如果是这样你们倾向于怎么处理把主动权交还给业务方。哪怕他们的回答不够专业也比沉默好得多因为只有对话发生了威胁分析才能真正贴合业务。6.2 愿景式需求让威胁建模无从下手需求阶段的另一个挑战是需求太模糊我们要做一个智能客服系统我们要做一个企业协同平台——这种一句话需求连功能边界都不清楚根本没法做数据流分析。遇到这种情况我不建议硬做威胁建模。先让产品经理把功能拆解成用户故事和业务流程图至少要把用户发起什么操作→系统怎么响应→数据怎么处理说清楚。威胁建模能给的是安全维度的输入补不了业务需求本身的缺失。如果需求颗粒度不够而项目本身又重要最实际的办法是建议产品经理产出一份详细SRS软件需求规格说明后再开会。6.3 威胁泛滥但全都不愿修有时候一次建模分析STRIDE一过威胁一下子列出了三四十条然后各个角色看到清单第一反应是太多了做不完干脆都先记下吧于是威胁清单从此变成了僵尸文档。这种场景我处理过一次比较成功后来总结出的方法论是威胁也必须做MVP裁剪。一共分三步第一按资产重要性排序只对敏感度为高的资产做完整分析第二按攻击面大小排序优先分析暴露面大的入口第三按业务影响排序涉及资金、权益、隐私的功能优先分析。砍完之后能进深度列表的威胁通常不超过10条这样才能真的讨论完。6.4 误把威胁建模当成漏扫提前版有一种比较危险的认知是团队觉得需求阶段做威胁建模等于在写代码之前做一次漏洞扫描。这种理解带来的后果是大家期待威胁建模能直接吐出XX功能存在SQL注入风险这样的结论然后照着修。但需求阶段根本没有SQL语句也没有具体框架威胁建模能给出的结论应该是该点位需要确认输入校验和参数化查询方案它指导的是后续设计阶段的方案而不是直接开出漏洞修复单。理解这个区别很重要。需求阶段威胁建模回答的是我们要不要在这里建一道墙这道墙建在哪、防什么人而不是这面墙用什么砖砌。等设计阶段有了架构图和接口定义才能回答后者。6.5 报告写完流程结束最后说说最常见的坑威胁建模报告写得辛苦评审会上大家也很认真但会后报告就被扔进Wiki吃灰后续设计、开发、测试各干各的。我现在会做一件相对较真的事把威胁清单里的高危项整理成一张跟踪表每个条目关联到具体的需求编号或Jira单号在发布评审的时候逐条确认。没有对应实施的关闭不掉没有决策人确认接受的也关闭不掉。另外还有个建议每隔两三个迭代把已上线项目的威胁建模报告拿出来做一次对比复盘——哪些威胁预测准了哪些威胁没预判到哪些处置方案成本过高实际没必要。这个复盘动作对提升团队的威胁建模水平非常有用比评审一百篇新报告都管用。7. 一些经验层面的思考7.1 威胁建模结果也是安全测试用例的输入有一件事我想特别强调一下需求阶段的威胁建模如果能跟后端的测试环节形成联动整个安全体系会被盘活。具体来说我在需求阶段完成威胁分析后会把高优先级的威胁场景直接转成安全测试用例的输入。以前测试团队写安全用例基本是照着网上的安全测试checklist抄一遍——SQL注入测一下、XSS测一下、越权测一下跟业务功能完全脱节。但需求阶段威胁建模提供的威胁场景是长在这个系统实际业务逻辑之上的。它生成的测试用例是订单金额接口是否做二次校验用户A的token能否访问用户B的订单第三方回调是否校验签名——这些用例的价值是通用checklist远远比不上的。7.2 从威胁建模中积累安全需求组件做威胁建模的次数多了你会发现自己不断在重复分析一些相似的问题登录接口被爆破、文件上传校验不严、越权访问缺少对象级权限校验、外部系统回调没做签名校验……这些问题在不同的项目里反复出现每次重新分析一遍效率显然是低的。我的建议是花半年到一年的时间把威胁建模中反复出现的威胁场景和对应的缓解方案沉淀成安全需求组件库。比如文件上传组件只允许指定MIME类型、重命名存储、独立域名、限制大小、做内容安全检测用户签名/加密传输组件核心数据防篡改、防重放攻击后台管理认证组件多因素认证、连续失败锁定、登录审计回调接口组件来源IP白名单、Token签名、幂等控制后续再遇到类似需求直接从组件库里引用威胁建模就从每次重复做分析变成了按需组合一次评审确认。7.3 安全团队的关键能力问对问题最后说点务虚但重要的事。威胁建模做得好不好工具和方法论都是次要的核心能力是安全工程师能不能在需求评审会上提出对的问题。什么是对的问题就是能引发团队讨论、能把模糊需求往具体方向推导、能在业务逻辑中发现安全盲区的问题。比如这个数据表存在Excel里导出里面的手机号是不是完全必要如果这个定时任务跑崩了影响是什么有没有报警通知管理后台的权限分几级权限是谁来审批的如果用户发起一笔支付需要几个服务参与中途哪个环节可能被篡改这些问题不会出现在任何威胁建模模板里但它们才是需求阶段最有价值的产出。模板给你的是框架真正让威胁建模发挥价值的是你对业务逻辑的理解和对风险点位的敏感。一个真实的落地场景回顾拿我自己最近参与的一个积分商城项目举例需求阶段做的威胁建模直接改变了三处设计第一处积分余额查询接口。原始需求是用户登录后展示剩余积分研发原本计划直接从用户表查询积分字段返回。建模分析时发现这个接口没有做额外的数据权限校验且前端频繁轮询可能被刷——最后调整为独立的积分服务增加限流和统一余额变更审计。第二处积分兑换下单。原始需求是用户点击兑换直接将积分扣除并生成订单。建模时用STRIDE套了一遍发现T篡改风险突出——攻击者可以篡改请求参数积分商品ID、兑换数量跳过前端交互逻辑直接调用后端接口。最终增加了服务端二次价格校验和幂等键控制。第三处积分过期提醒。原始需求是发短信通知用户积分即将过期。隐私分析后发现短信内容若包含积分余额和过期时间存在个人信息过度披露风险。最终脱敏后仅发送提醒文案不包含具体数据。这三处改变都不是高深的安全技术但如果不在需求阶段发现到了测试阶段再补救至少要多出三个返工迭代开发成本要翻好几倍。需求阶段威胁建模这件事不需要你一次就做到完美。哪怕从一次45分钟的评审会开始把数据流图拉一遍、把STRIDE过一遍、把高风险项记下来就已经比绝大多数团队走得远了。这门功夫的核心不在于工具和流程而在于它逼着所有人——安全、产品、研发、测试——在需求还便宜的时候把最贵的问题提前想清楚。