name: security-threat-model description: 基于代码仓库的威胁建模，列举信任边界、资产、攻击者能力、滥用路径和缓解措施，并撰写简明的Markdown威胁模型。仅在用户明确要求对代码库或路径进行威胁建模、列举威胁/滥用路径或执行AppSec威胁建模时触发。不适用于一般架构摘要、代码审查或非安全设计工作。 metadata: author: github.com/openai/skills version: ‘1.0.0’
威胁模型源代码仓库
提供一个可操作的AppSec级威胁模型，具体到仓库或项目路径，而不是通用检查表。将每个架构声明锚定到仓库中的证据，并明确假设。优先考虑现实的攻击者目标和具体影响，而不是通用检查表。
快速开始
- 收集（或推断）输入：
- 仓库根路径和任何在范围内的路径。
- 预期用途、部署模型、互联网暴露和认证期望（如果已知）。
- 任何现有的仓库摘要或架构规范。
- 使用
references/prompt-template.md中的提示生成仓库摘要。 - 遵循
references/prompt-template.md中的输出合同要求。尽可能使用原文。
工作流程
1) 范围界定和提取系统模型
- 从仓库摘要中识别主要组件、数据存储和外部集成。
- 识别系统运行方式（服务器、CLI、库、工作器）及其入口点。
- 将运行时行为与CI/构建/开发工具以及测试/示例分开。
- 将范围内位置映射到这些组件，并明确排除范围外项目。
- 没有证据不要声称组件、流或控制。
2) 推导边界、资产和入口点
- 枚举信任边界作为组件之间的具体边缘，记录协议、认证、加密、验证和速率限制。
- 列出驱动风险的资产（数据、凭证、模型、配置、计算资源、审计日志）。
- 识别入口点（端点、上传表面、解析器/解码器、作业触发器、管理工具、日志/错误接收器）。
3) 校准资产和攻击者能力
- 列出驱动风险的资产（凭证、个人可识别信息、完整性关键状态、可用性关键组件、构建工件）。
- 基于暴露和预期用途描述现实攻击者能力。
- 明确标注非能力以避免严重性夸大。
4) 枚举威胁为滥用路径
- 偏好映射到资产和边界的攻击者目标（数据泄露、权限提升、完整性破坏、拒绝服务）。
- 分类每个威胁并将其连接到受影响资产。
- 保持威胁数量少但质量高。
5) 通过明确可能性和影响推理进行优先级排序
- 使用定性可能性和影响（低/中/高）并简短论证。
- 设置总体优先级（关键/高/中/低），使用可能性 x 影响，并根据现有控制调整。
- 说明哪些假设最影响排名。
6) 用用户验证服务上下文和假设
- 总结严重影响威胁排名或范围的关键假设，然后要求用户确认或更正。
- 提出1-3个针对性问题以解决缺失上下文（服务所有者和环境、规模/用户、部署模型、认证/授权、互联网暴露、数据敏感性、多租户）。
- 暂停并等待用户反馈，然后生成最终报告。
- 如果用户拒绝或无法回答，说明哪些假设仍然存在及其如何影响优先级。
7) 推荐缓解措施和关注路径
- 区分现有缓解措施（有证据）与推荐缓解措施。
- 将缓解措施连接到具体位置（组件、边界或入口点）和控制类型（授权检查、输入验证、模式强制、沙盒、速率限制、秘密隔离、审计日志）。
- 偏好具体实现提示而不是泛泛建议（例如，“在网关上对上传负载强制模式”而不是“验证输入”）。
- 基于验证的用户上下文进行推荐；如果假设未解决，将推荐标记为有条件。
8) 在最终确定前进行质量检查
- 确认所有发现的入口点已覆盖。
- 确认每个信任边界在威胁中已表示。
- 确认运行时与CI/开发分离。
- 确认用户澄清（或明确无响应）已反映。
- 确认假设和开放问题已明确。
- 确认报告格式与提示模板中定义的所需输出格式紧密匹配：
references/prompt-template.md - 将最终Markdown写入文件，命名为
<repo-or-dir-name>-threat-model.md（使用仓库根路径的基本名称，或如果建模子路径，则使用范围内目录名称）。
风险优先级指导（说明性，非详尽）
- 高：预认证远程代码执行、认证绕过、跨租户访问、敏感数据泄露、密钥或令牌盗窃、模型或配置完整性破坏、沙盒逃逸。
- 中：对关键组件的定向拒绝服务、部分数据暴露、速率限制绕过并具有可测量影响、日志/指标污染影响检测。
- 低：低敏感性信息泄露、容易缓解的嘈杂拒绝服务、需要不太可能前提条件的问题。
参考资料
- 输出合同和完整提示模板：
references/prompt-template.md - 可选控制/资产列表：
references/security-controls-and-assets.md只加载所需参考文件。保持最终结果简洁、基于事实且可审查。