security-threat-model

威胁模型源代码仓库

交付一份符合应用安全（AppSec）标准、可付诸行动的威胁模型，针对具体仓库或项目路径，而非通用检查清单。每项架构描述都要以仓库中的证据为依据，并明确说明假设。优先考虑真实的攻击者目标和具体影响，而不是泛泛的检查清单。

快速开始

1. 收集（或推断）输入信息：

• 仓库根路径和任何范围内路径。
• 预期用途、部署模式、互联网暴露情况和身份验证预期（如已知）。
• 现有仓库摘要或架构规范（如有）。
• 使用 references/prompt-template.md 中的提示词生成仓库摘要。
• 遵循 references/prompt-template.md 中要求的输出规范。尽可能原样使用。

工作流

1）界定范围并提取系统模型

• 根据仓库摘要识别主要组件、数据存储和外部集成。
• 识别系统的运行方式（服务端、CLI、库、工作进程）及其入口点。
• 将运行时行为与 CI/构建/开发工具以及测试/示例区分开。
• 将范围内的位置映射到这些组件，并明确排除范围外的项目。
• 没有证据时，不要声称存在某些组件、流程或控制措施。

2）推导边界、资产和入口点

• 将信任边界列为组件之间的具体连接，并注明协议、身份验证、加密、校验和速率限制情况。
• 列出影响风险的资产（数据、凭据、模型、配置、计算资源、审计日志）。
• 识别入口点（端点、上传界面、解析器/解码器、作业触发器、管理工具、日志/错误接收端）。

3）评估资产和攻击者能力

• 列出影响风险的资产（凭据、PII、影响完整性的关键状态、影响可用性的关键组件、构建产物）。
• 根据暴露情况和预期用途，描述现实的攻击者能力。
• 明确说明攻击者不具备的能力，避免夸大严重性。

4）将威胁列为滥用路径

• 优先考虑与资产和边界相关的攻击者目标（数据外泄、权限提升、完整性受损、拒绝服务）。
• 对每项威胁进行分类，并关联受影响的资产。
• 威胁数量应少而精。

5）明确说明可能性和影响的理由，并据此确定优先级

• 使用定性等级评估可能性和影响（低/中/高），并简要说明理由。
• 根据可能性 × 影响确定总体优先级（严重/高/中/低），并结合现有控制措施进行调整。
• 说明最影响排名的假设。

6）与用户确认服务背景和假设

• 总结会实质影响威胁排名或范围的关键假设，然后请用户确认或纠正。
• 提出 1–3 个有针对性的问题，以补充缺失背景（服务负责人和环境、规模/用户、部署模式、身份验证/授权、互联网暴露、数据敏感性、多租户）。
• 暂停并等待用户反馈，再生成最终报告。
• 如果用户拒绝回答或无法回答，说明仍未确认的假设及其对优先级的影响。

7）提出缓解措施并明确关注路径

• 区分已有缓解措施（提供证据）和建议的缓解措施。
• 将缓解措施关联到具体位置（组件、边界或入口点）和控制类型（授权检查、输入校验、模式约束、沙箱、速率限制、机密隔离、审计日志）。
• 与其给出泛泛建议，不如提供具体实施提示（例如：“在网关处强制校验上传负载的模式”，而不是“校验输入”）。
• 根据已确认的用户背景提出建议；如果假设仍未确认，则将建议标记为有条件建议。

8) 定稿前进行质量检查

• 确认所有已发现的入口点都已涵盖。
• 确认威胁中体现了每个信任边界。
• 确认已区分运行时与 CI/开发环境。
• 确认已反映用户的澄清（或明确未回复的情况）。
• 确认已明确列出假设和未决问题。
• 确认报告格式与提示词模板中定义的必需输出格式尽可能一致：references/prompt-template.md
• 将最终 Markdown 写入名为 <repo-or-dir-name>-threat-model.md 的文件（使用仓库根目录的基本名称；如果要求对某个子路径建模，则使用范围内目录的基本名称）。

风险优先级指导（仅供参考，并非详尽无遗）

• 高：未认证 RCE、认证绕过、跨租户访问、敏感数据外泄、密钥或令牌窃取、模型或配置完整性受损、逃逸沙箱。
• 中：针对关键组件的定向 DoS、部分数据泄露、造成可衡量影响的速率限制绕过、影响检测的日志/指标投毒。
• 低：低敏感度信息泄露、易于缓解的嘈杂 DoS、需要不太可能出现的前置条件的问题。

参考资料

• 输出约定和完整提示词模板：references/prompt-template.md
• 可选的控制措施/资产列表：references/security-controls-and-assets.md

仅加载所需的参考文件。保持最终结果简洁、可靠且便于审查。