目标
在设计期问一句“别人会怎么滥用这个”，安全就从上线后打补丁的纪律变成设计输入。走查很短——资产、入口、边界、滥用——但每个可信的滥用场景都会转成带验收标准的跟踪需求，评审时逐条验证缓解确实存在。
步骤要点
- 枚举资产与入口：列出特性触碰的攻击者想要的东西（数据、资金、配额、可用性），以及它接受输入的每个途径（API、上传、webhook、URL 参数）。
- 走查信任边界：追踪每个入口跨过哪些边界（客户端到服务器、匿名到登录、服务到服务），问什么在跨界、谁在验证。
- 按入口头脑风暴滥用：重放、枚举、注入、越权混淆、资源耗尽、被诱骗的代理，按资产损害排序。
- 转成设计需求：把可信滥用转成具体需求（限流、幂等键、鉴权检查、输入校验），与功能需求同等跟踪。
- 评审验证缓解：设计与代码评审逐条核验需求已实现且可测，拒绝聪明但无对冲的路径。
排错提示
错误信息差异让攻击者枚举有效码是最常见的特性级漏洞，设计期统一错误文案只花一行；威胁模型列了风险却没转需求等于白做，每个滥用都要落进设计文档带验收标准；评审只看功能不看滥用清单是流程退化，把安全需求与功能需求同列同查。
适用边界
特性级威胁建模不替代系统级架构评审，跨特性的信任边界变化要上升到架构层；滥用场景的想象力有上限，上线后的漏洞赏金与监控是必要补充。
代码示例
feature: gift-code redemption
assets: promo budget, code exhaustion, account takeover?
entries: POST /redeem {code}, code entry rate
boundaries: client->server, anon->authed, api->ledger
abuse cases:
brute-force codes (enumeration)
-> req: rate limit 5/h + lockout + code entropy 2^40
replay redemption (double spend)
-> req: idempotency key per account+code
transfer codes between accounts (enumeration via
error difference)
-> req: uniform error, no code validity leak
ledger race (concurrent redeem)
-> req: atomic decrement (transactional)
verified: 4/4 mitigations in tests; residual: none