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 的文件（使用仓库根目录的基本名称；如果要求对某个子路径建模，则使用范围内目录的基本名称）。

常见误区

以下是威胁建模中最常见的失败情形。避免这些问题，才能让威胁模型切实可用且令人信服。

1. 威胁模型过于抽象（没有具体攻击路径）

问题： 威胁描述读起来像泛泛的安全检查项，而不是基于实际代码、配置或部署架构的具体滥用路径。

不佳示例：“攻击者未经授权访问敏感数据”
良好示例：“如果进程部署时的文件系统权限允许所有用户读取，未通过身份验证的攻击者就能从 config.json 中窃取 API 密钥，进而提升权限并入侵 AWS。”

如何避免： 对每个威胁都问问：涉及哪个组件？哪个入口点？攻击者利用了哪条具体代码路径或边界？ 如果回答不了，就回到代码库中查找具体证据（代码、配置模板、部署文档）。

2. 缺少威胁主体及其动机（对手画像笼统）

问题： 威胁模型列出了威胁，却没有定义攻击者是谁、他们想要什么，以及他们掌握哪些资源。这样就无法评估可能性，优先级排序也就失去了意义。

不佳示例：“攻击者入侵系统”
良好示例：“心怀不满的员工利用内部 API 访问权限窃取 PII，并在暗网市场上出售。可能性：中（能够访问的员工很少；虽有审计日志，但未进行实时监控）”

如何避免： 为系统定义 3-4 种现实的攻击者画像：

• 外部未通过身份验证的攻击者
• 已通过身份验证的用户（内部人员、客户或合作伙伴）
• 拥有特定权限级别的恶意内部人员
• 供应链参与者（依赖项或基础设施提供商）

针对每个威胁，说明哪些攻击者可以利用该威胁，以及他们这样做的动机。

3. 没有优先级排序（所有问题都标为“严重”）

问题： 每个威胁都被标记为严重，因为理论上其影响可能非常大。这样会让威胁模型失去实用性——团队无法确定工作重点，也会削弱可信度（“威胁模型不过是危言耸听”）。

**不佳示例：**25 个威胁全部标为“严重”
良好示例：“通过依赖项实现供应链 RCE：严重（补丁发布前被利用的可能性高，影响灾难性）。用户暴力破解弱密码：中（启用速率限制和 2FA 后可能性较低，但一旦成功，完整性影响很大）。”

如何避免： 使用可能性 × 影响矩阵，并根据现有控制措施调整最终优先级。请思考：

• 利用该问题有多难？（代码深度、所需前提条件、攻击者资源）
• 攻击者尝试利用该问题的可能性有多大？（这是明显的攻击向量吗？是否需要长期潜伏或内部知识？）
• 是否已有控制措施可以缓解风险？（速率限制、加密、审计日志）

如果优先级取决于尚未确认的用户假设，请标记为“有条件的高”。

4. 缓解措施缺乏实现细节（建议含糊）

问题： 建议读起来像安全套话（“添加身份验证”“加密数据”“启用日志记录”），而不是明确指出代码位置或控制机制。团队不知道从何处着手。

不好的示例： “添加输入验证以防止注入攻击”
好的示例： “在将数据传递给文档解析器之前，在 /api/upload 端点处理程序（src/handlers/upload.ts:42）上强制执行 JSON 架构验证。使用 Zod 或 Ajv 拒绝超过 10MB 或 MIME 类型不被允许的载荷。”

如何避免： 对每项缓解措施：

1. 指明组件或代码位置（文件、函数、边界）
2. 指定控制类型：架构强制、速率限制、沙箱、密钥轮换、审计日志、签名验证等
3. 将其与要缓解的威胁关联起来
4. 如果找不到具体位置，请让用户说明架构

5. 缺少威胁模型维护计划（一次性工作）

问题： 威胁模型交付后只是一个快照，但系统仍在演进。新增入口点、升级依赖、团队发生变化。几周内，模型就会过时并失去可信度。

不好的示例： “这是你的威胁模型，祝你好运！”
好的示例： “威胁模型已在 Git 中进行版本控制。审查计划：每次重大部署后、团队每季度审查一次，以及每当新增依赖或集成时。更新触发清单：新增用户角色、新增 API、新增数据源、基础设施变更。”

如何避免： 在最终定稿前，就以下事项达成一致：

• 版本控制： 威胁模型是否纳入 Git？是否与架构变更关联？
• 审查频率： 每季度？每次发布？由事件触发？
• 更新触发条件： 哪些代码或部署变更需要更新威胁模型？
• 负责人： 谁负责威胁模型？谁来更新？

在交付内容中提及这些事项。

6. STRIDE/PASTA 特有的失效模式

STRIDE（若采用此方法）

• 欺骗： 威胁模型列出“攻击者伪造身份”，却没有说明哪种身份验证机制可能被绕过，以及如何绕过（密码学强度不足、令牌验证不当、重放攻击）
• 篡改： 指出了传输中的数据，却遗漏了具体边界和传输方式（API 是否使用 TLS？离线数据是否有消息签名？）
• 抵赖： 如果存在审计日志，就会高估发生可能性；未考虑日志保留期限和监控覆盖范围
• 信息泄露： 将“静态数据未加密”（常见情况）与“攻击者会窃取数据”（取决于访问控制和网络暴露情况）混为一谈
• 拒绝服务： 将所有 DoS 一概而论；进程内崩溃与外部速率限制耗尽是不同问题——应按组件分别处理
• 权限提升： 常常遗漏最初的立足点；要问“攻击者最初如何到达该组件？”

PASTA（若采用此方法）

• 资产枚举： 列出了技术资产，却遗漏了逻辑资产（数据管道、声誉、可用性）。要问“这里最具业务价值的是什么？”
• 威胁分析： 常常演变成对 CVE 的文献综述，而非针对应用的滥用途径分析。应聚焦于这个系统。
• 漏洞分析： 将“代码中存在 SQL 注入模式”与“攻击者能够触及该代码”混为一谈——要确认哪些入口点确实暴露了它
• 风险分析： 使用模板进行严重性评级，却未分析在当前情境下的可能性。内部管理工具中的 RCE 风险低于面向互联网的 API 中同样的 RCE

---

风险优先级指导（示例，并非详尽列表）

• 高：未授权即可触发的 RCE、绕过身份验证、跨租户访问、敏感数据外泄、密钥或令牌被盗、模型或配置完整性遭到破坏、逃逸沙箱。
• 中：针对关键组件的定向 DoS、部分数据泄露、造成可测量影响的速率限制绕过、影响检测的日志／指标投毒。
• 低：低敏感度信息泄露、容易缓解的嘈杂 DoS、需要不太可能出现的前置条件才能利用的问题。

AI／ML 系统威胁建模

对于包含 AI／ML 组件（LLM、嵌入、RAG 流水线）的系统，请添加以下威胁类别：

AI 特定威胁

威胁	描述	典型影响
提示词注入	用户输入中的恶意内容覆盖系统指令	权限提升、数据外泄
间接提示词注入	外部数据（文档、网页）中的恶意内容劫持 Agent 的操作	未经授权的工具调用、数据盗窃
训练数据投毒	微调数据中的对抗样本植入后门	操纵模型行为
模型外泄	窃取模型权重或蒸馏专有模型	知识产权盗窃、规避安全措施
嵌入反演	从向量数据库中存储的嵌入向量重建个人身份信息	侵犯隐私
RAG 操纵	向知识库注入对抗性文档	传播错误信息
越狱	通过对抗性提示词绕过安全过滤器	违反政策、产生有害输出
上下文窗口攻击	填满上下文，挤掉安全指令	绕过安全措施

AI 威胁模型检查清单

• 是否保护系统提示词，防止用户覆盖？
• 外部数据（文档、网页搜索）在纳入上下文前是否经过清理？
• 是否根据用户权限对 Agent 的工具调用进行授权？
• 是否对向量数据库访问进行控制（禁止跨租户访问）？
• 执行操作（例如代码执行）前是否验证模型输出？
• 是否按用户对 LLM API 密钥进行限权和速率限制？
• 是否设置日志记录，以检测提示词注入尝试？

供应链威胁建模

现代应用高度依赖第三方软件包。请纳入以下威胁：

威胁	示例	缓解措施
typosquatting（拼写仿冒）	reqursts 替代 requests	锁定文件、软件包签名
依赖混淆	公共注册表中有人劫持内部软件包名称	命名空间限定的软件包、注册表配置
维护者遭入侵	event-stream npm 事件	SBOM + CVE 监控、VCS 完整性
构建系统遭入侵	类似 SolarWinds 的攻击	可复现构建、SLSA Level 3
CI/CD 劫持	注入 Actions 工作流	按提交哈希固定 Actions，而非使用标签

云原生部署威胁

对于容器化／Kubernetes／无服务器部署：

• 容器逃逸：特权容器或主机路径挂载
• 向元数据服务发起 SSRF：AWS IMDSv1 允许从容器内部窃取凭证
• Kubernetes RBAC 权限过宽：ServiceAccount 令牌拥有集群范围的访问权限
• 环境变量中包含机密：在容器检查和日志中可见
• 通过服务网格进行横向移动：东西向流量未加密

参考资料

• 输出规范和完整提示词模板：references/prompt-template.md
• 可选控制措施／资产列表：references/security-controls-and-assets.md
• OWASP Top 10：https://owasp.org/Top10/
• OWASP LLM Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• MITRE ATT&CK：https://attack.mitre.org/
• STRIDE 方法：Microsoft SDL 威胁建模

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