openai-security-threat-model

威胁模型：源代码仓库

交付一份可执行、达到应用安全级别的威胁模型，针对特定仓库或项目路径，而非通用检查清单。每项架构描述都应以仓库中的证据为依据，并明确列出假设。优先关注现实的攻击者目标和具体影响，而非通用检查清单。

快速开始

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

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

工作流

1) 确定范围并提取系统模型

• 根据仓库摘要识别主要组件、数据存储和外部集成。
• 确定系统的运行方式（服务、命令行、库、工作进程）及其入口点。
• 将运行时行为与 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

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

适用场景

不适用场景