先画数据流
威胁模型从系统做什么开始，而不是从攻击清单开始。画出用户、服务、数据存储、外部依赖和它们之间的信任边界。标出数据从低信任区进入高信任区的位置。每个边界上都应能看到认证、授权、加密和校验。
Browser --HTTPS--> API gateway --mTLS--> Orders service --TLS--> PostgreSQL
| |
+-- third-party payment (untrusted) +-- event bus (internal)提出结构化问题
STRIDE 是有用的检查表：伪装、篡改、否认、信息泄露、拒绝服务和权限提升。对每个边界询问：哪些威胁适用、现有控制是什么、有什么证据证明控制有效。还要考虑供应链、内部人员、错误配置和数据保留。按影响和可能性排序，并指定负责人。
把发现变成工作
不改变代码或运维的威胁模型只是文档表演。把发现转成带验收标准的工单，为控制添加测试，并在数据流或依赖变化时重新审视模型。接受的风险要记录负责人和到期日。
何时使用
在新功能、重大集成或架构变更之前，以及安全事件暴露盲区时，使用威胁建模。优点是能在设计缺陷变昂贵前发现它；代价是时间和诚实参与。与通用安全清单相比，威胁建模针对具体系统，并产出有优先级的工作。