当需要基于代码仓库做 AppSec 威胁建模时…

在用户明确要求对代码库或某路径做威胁建模、枚举威胁/滥用路径或进行 AppSec 威胁建模时，产出有仓库证据支撑的简洁 Markdown 威胁模型。

适用场景

解决思路

1. 收集或推断输入：仓库根路径与范围内路径；预期用途、部署模型、互联网暴露面与认证预期（若已知）；已有的仓库摘要或架构说明；使用 references/prompt-template.md 中的提示生成仓库摘要；遵循 references/prompt-template.md 中要求的输出契约，尽量逐字使用。
2. 范围界定并提取系统模型：从仓库摘要中识别主要组件、数据存储与外部集成；识别系统运行方式（server、CLI、library、worker）及其入口点；将运行时行为与 CI/构建/开发工具以及测试/示例分离；把范围内位置映射到这些组件并显式排除范围外项；没有证据不要声称组件、流程或控制措施。
3. 推导边界、资产与入口点：把信任边界枚举为组件之间的具体边，注明协议、认证、加密、校验与限流；列出驱动风险的资产（数据、凭据、模型、配置、计算资源、审计日志）；识别入口点（端点、上传面、解析器/解码器、任务触发器、管理工具、日志/错误汇聚点）。
4. 校准资产与攻击者能力：列出驱动风险的资产（凭据、PII、完整性关键状态、可用性关键组件、构建产物）；基于暴露面与预期用途描述现实攻击者能力；显式注明非能力以避免夸大严重性。
5. 以滥用路径枚举威胁：优先选择映射到资产与边界的攻击者目标（数据外泄、权限提升、完整性破坏、拒绝服务）；对每个威胁分类并关联受影响资产；威胁数量保持少而高质量。
6. 用显式的可能性与影响推理排优先级：使用定性可能性与影响（低/中/高）并给出简短理由；按可能性×影响并结合现有控制措施调整，设定总体优先级（critical/high/medium/low）；说明哪些假设对排名影响最大。
7. 与用户验证服务上下文与假设：总结对威胁排名或范围有实质影响的关键假设，然后请用户确认或纠正；提出 1–3 个针对性问题以补齐缺失上下文（服务负责人与环境、规模/用户、部署模型、认证/授权、互联网暴露、数据敏感性、多租户）；暂停并等待用户反馈后再产出最终报告；若用户拒绝或无法回答，说明仍保留哪些假设及其如何影响优先级。
8. 推荐缓解措施与重点路径：区分现有缓解措施（附证据）与建议缓解措施；把缓解措施绑定到具体位置（组件、边界或入口点）与控制类型（授权检查、输入校验、schema 强制、沙箱、限流、密钥隔离、审计日志）；优先给出具体实现提示而非泛泛建议（例如“在网关对上传载荷强制 schema”而非“校验输入”）；建议基于已验证的用户上下文；若假设仍未解决，把建议标记为有条件。
9. 最终定稿前做质量检查：确认所有发现的入口点都被覆盖；确认每个信任边界都在威胁中体现；确认运行时与 CI/开发已分离；确认用户澄清（或明确未回应）已反映；确认假设与开放问题已显式列出；确认报告格式与 prompt template 中要求的输出格式高度一致：references/prompt-template.md；把最终 Markdown 写入名为 <repo-or-dir-name>-threat-model.md 的文件（使用仓库根目录的 basename，或若被要求建模子路径则使用范围内目录）。
10. 风险优先级参考（示例性，非穷尽）：High：预认证 RCE、认证绕过、跨租户访问、敏感数据外泄、密钥或令牌窃取、模型或配置完整性破坏、沙箱逃逸；Medium：关键组件的定向 DoS、部分数据暴露、有可衡量影响的限流绕过、影响检测的日志/指标投毒；Low：低敏感信息泄露、易缓解的噪声型 DoS、需要不太可能前置条件的问题。
11. 参考文件：输出契约与完整 prompt 模板：references/prompt-template.md；可选控制措施/资产清单：references/security-controls-and-assets.md；只加载需要的参考文件；保持最终结果简洁、有依据、可评审。

适用边界 · 注意事项

• 不要用于一般架构总结、代码审查或非安全设计工作。
• 不要在用户未明确要求对代码库或路径做威胁建模、枚举威胁/滥用路径或 AppSec 威胁建模时触发。
• 不要在没有仓库证据的情况下声称组件、流程或控制措施。