编程开发 编辑复核
功能威胁建模与防护清单
按资产、信任边界、攻击路径和影响评估新功能的安全风险，明确哪些结论需要安全人员复核。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名应用安全工程师。请从资产和信任边界出发分析威胁，不声称“绝对安全”，也不输出可直接用于攻击真实系统的操作细节。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 列出资产、角色、入口、信任边界和数据流
2. 按欺骗、篡改、抵赖、信息泄露、拒绝服务和权限提升分类风险
3. 评估影响、可能性、现有控制和剩余风险
4. 给出安全测试、监控、负责人和上线阻断条件
输入变量：
- 功能（{{feature}}）：说明要新增或审查的功能。
- 数据流（{{data_flow}}）：描述浏览器、API、数据库和第三方之间的流转。
- 角色（{{actors}}）：列出匿名用户、登录用户、管理员和服务账号。
- 已有控制（{{controls}}）：提供认证、授权、校验和监控现状。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 只在脱敏架构和测试环境上讨论，生产凭据不得放入输入。
- 高风险结论交给安全负责人和专业测试人员复核。
WHEN IT FITS
适用判断
适合这些情况
- 功能涉及用户数据、支付或权限，需要提前想清楚攻击面。
- 你能描述清楚数据流：谁输入、经过哪些环节、存到哪里。
- 要给开发一份具体的防护要求，而不是笼统的安全提醒。
换个做法更好
- 你要评估的是业务逻辑被滥用的场景：用《安全滥用场景评审》。
- 功能不接触任何用户数据或外部输入：威胁面很小。
- 需要的是渗透测试结论：建模是设计阶段的工作，替代不了实测。
FAILURE MODES
常见翻车与修正
- 列出的威胁都是通用清单（SQL 注入、XSS），没结合你的功能。
要求按你描述的数据流逐个环节分析：这个环节接收什么、信任边界在哪、被绕过会发生什么。
- 防护措施写成「做好输入校验」，没有具体要求。
要求每条防护写明校验什么字段、用什么规则、失败时怎么处理，以及在哪一层实施。
- 把建模结论当成安全保证。
明确标注：建模只覆盖已识别的威胁，不能替代代码审计和实际测试，并列出建议补充的验证手段。
ACCEPTANCE
怎么判断输出合格
- 威胁都对应到你功能里的具体环节，不是通用清单。
- 每条防护措施具体到字段、规则和实施层次。
- 标明了信任边界在哪，哪些输入不可信。
- 说明了建模的局限和需要补充的验证方式。
SAFETY BOUNDARY
使用边界
- 威胁建模的输出是待验证清单，不是安全结论；关键系统需要专业安全评审。
- 识别出的漏洞在修复前不要写入公开文档或工单，处理范围要控制在必要人员内。