Back to Details

security-threat-model

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Threat Model Source Code Repo

代码仓库威胁建模

Deliver an actionable AppSec-grade threat model that is specific to the repository or a project path, not a generic checklist. Anchor every architectural claim to evidence in the repo and keep assumptions explicit. Prioritizing realistic attacker goals and concrete impacts over generic checklists.
生成可落地的AppSec级威胁模型，该模型针对特定代码仓库或项目路径，而非通用检查清单。所有架构相关结论均需以仓库中的证据为依据，并明确说明假设条件。优先考虑真实可行的攻击者目标和具体影响，而非通用检查清单。

Quick start

快速入门

  1. Collect (or infer) inputs:
  • Repo root path and any in-scope paths.
  • Intended usage, deployment model, internet exposure, and auth expectations (if known).
  • Any existing repository summary or architecture spec.
  • Use prompts in 
    references/prompt-template.md
    to generate a repository summary.
  • Follow the required output contract in 
    references/prompt-template.md
    . Use it verbatim when possible.
  1. 收集（或推断）输入信息：
  • 仓库根路径及所有纳入范围的路径。
  • 预期用途、部署模型、互联网暴露情况及身份验证要求（若已知）。
  • 任何已有的仓库总结或架构规范。
  • 使用
    references/prompt-template.md
    中的提示生成仓库总结。
  • 遵循
    references/prompt-template.md
    中的输出规范，尽可能直接使用该模板。

Workflow

工作流程

1) Scope and extract the system model

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

  • Identify primary components, data stores, and external integrations from the repo summary.
  • Identify how the system runs (server, CLI, library, worker) and its entrypoints.
  • Separate runtime behavior from CI/build/dev tooling and from tests/examples.
  • Map the in-scope locations to those components and exclude out-of-scope items explicitly.
  • Do not claim components, flows, or controls without evidence.
  • 从仓库总结中识别核心组件、数据存储及外部集成。
  • 确定系统运行方式（服务器、CLI、库、工作进程）及其入口点。
  • 将运行时行为与CI/构建/开发工具、测试/示例代码区分开。
  • 将纳入范围的位置映射到对应组件，并明确排除超出范围的内容。
  • 若无证据支撑，不得随意断言组件、流程或控制措施。

2) Derive boundaries, assets, and entry points

2) 推导边界、资产与入口点

  • Enumerate trust boundaries as concrete edges between components, noting protocol, auth, encryption, validation, and rate limiting.
  • List assets that drive risk (data, credentials, models, config, compute resources, audit logs).
  • Identify entry points (endpoints, upload surfaces, parsers/decoders, job triggers, admin tooling, logging/error sinks).
  • 将信任边界枚举为组件间的具体连接，注明协议、身份验证、加密、验证及限流措施。
  • 列出具有风险的资产（数据、凭据、模型、配置、计算资源、审计日志）。
  • 识别入口点（端点、上传接口、解析器/解码器、任务触发器、管理工具、日志/错误收集点）。

3) Calibrate assets and attacker capabilities

3) 评估资产与攻击者能力

  • List the assets that drive risk (credentials, PII, integrity-critical state, availability-critical components, build artifacts).
  • Describe realistic attacker capabilities based on exposure and intended usage.
  • Explicitly note non-capabilities to avoid inflated severity.
  • 列出具有风险的资产（凭据、PII、完整性关键状态、可用性关键组件、构建产物）。
  • 根据暴露情况和预期用途描述真实可行的攻击者能力。
  • 明确说明攻击者不具备的能力，避免高估风险等级。

4) Enumerate threats as abuse paths

4) 将威胁枚举为滥用路径

  • Prefer attacker goals that map to assets and boundaries (exfiltration, privilege escalation, integrity compromise, denial of service).
  • Classify each threat and tie it to impacted assets.
  • Keep the number of threats small but high quality.
  • 优先选择与资产和边界相关的攻击者目标（数据泄露、权限提升、完整性破坏、拒绝服务）。
  • 对每个威胁进行分类，并关联受影响的资产。
  • 控制威胁数量，确保质量而非数量。

5) Prioritize with explicit likelihood and impact reasoning

5) 通过明确的可能性与影响分析进行优先级排序

  • Use qualitative likelihood and impact (low/medium/high) with short justifications.
  • Set overall priority (critical/high/medium/low) using likelihood x impact, adjusted for existing controls.
  • State which assumptions most influence the ranking.
  • 使用定性的可能性和影响等级（低/中/高），并附上简短理由。
  • 结合现有控制措施，通过可能性×影响计算得出总体优先级（关键/高/中/低）。
  • 说明哪些假设对优先级排名影响最大。

6) Validate service context and assumptions with the user

6) 与用户验证服务上下文及假设

  • Summarize key assumptions that materially affect threat ranking or scope, then ask the user to confirm or correct them.
  • Ask 1–3 targeted questions to resolve missing context (service owner and environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
  • Pause and wait for user feedback before producing the final report.
  • If the user declines or can’t answer, state which assumptions remain and how they influence priority.
  • 总结对威胁排名或范围有重大影响的关键假设，然后请用户确认或纠正。
  • 提出1-3个针对性问题，以补充缺失的上下文（服务所有者与环境、规模/用户量、部署模型、身份认证/授权、互联网暴露情况、数据敏感度、多租户特性）。
  • 在生成最终报告前，暂停并等待用户反馈。
  • 若用户拒绝回答或无法回答，需说明仍存在的假设及其对优先级的影响。

7) Recommend mitigations and focus paths

7) 推荐缓解措施与重点方向

  • Distinguish existing mitigations (with evidence) from recommended mitigations.
  • Tie mitigations to concrete locations (component, boundary, or entry point) and control types (authZ checks, input validation, schema enforcement, sandboxing, rate limits, secrets isolation, audit logging).
  • Prefer specific implementation hints over generic advice (e.g., "enforce schema at gateway for upload payloads" vs "validate inputs").
  • Base recommendations on validated user context; if assumptions remain unresolved, mark recommendations as conditional.
  • 区分已有的缓解措施（需有证据支撑）与推荐的缓解措施。
  • 将缓解措施关联到具体位置（组件、边界或入口点）及控制类型（授权检查、输入验证、schema强制、沙箱隔离、限流、密钥隔离、审计日志）。
  • 优先提供具体的实现建议，而非通用建议（例如：“在网关处对上传payload强制实施schema”而非“验证输入”）。
  • 基于已验证的用户上下文给出建议；若假设未解决，需标记建议为条件性建议。

8) Run a quality check before finalizing

8) 定稿前进行质量检查

  • Confirm all discovered entrypoints are covered.
  • Confirm each trust boundary is represented in threats.
  • Confirm runtime vs CI/dev separation.
  • Confirm user clarifications (or explicit non-responses) are reflected.
  • Confirm assumptions and open questions are explicit.
  • Confirm that the format of the report matches closely the required output format defined in prompt template: 
    references/prompt-template.md
  • Write the final Markdown to a file named 
    <repo-or-dir-name>-threat-model.md
    (use the basename of the repo root, or the in-scope directory if you were asked to model a subpath).
  • 确认所有已发现的入口点均已覆盖。
  • 确认每个信任边界均在威胁中有所体现。
  • 确认已区分运行时与CI/开发环节。
  • 确认已反映用户的澄清信息（或明确的无回应情况）。
  • 确认假设与未解决问题已明确说明。
  • 确认报告格式与
    references/prompt-template.md
    中定义的要求输出格式高度匹配。
  • 将最终的Markdown内容写入名为
    <repo-or-dir-name>-threat-model.md
    的文件（使用仓库根目录的基础名称，若仅对子路径建模则使用对应目录名称）。

Risk prioritization guidance (illustrative, not exhaustive)

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

  • High: pre-auth RCE, auth bypass, cross-tenant access, sensitive data exfiltration, key or token theft, model or config integrity compromise, sandbox escape.
  • Medium: targeted DoS of critical components, partial data exposure, rate-limit bypass with measurable impact, log/metrics poisoning that affects detection.
  • Low: low-sensitivity info leaks, noisy DoS with easy mitigation, issues requiring unlikely preconditions.
  • 高风险：预认证RCE、身份验证绕过、跨租户访问、敏感数据泄露、密钥或令牌窃取、模型或配置完整性破坏、沙箱逃逸。
  • 中风险：针对关键组件的定向DoS、部分数据暴露、可造成可衡量影响的限流绕过、影响检测能力的日志/指标篡改。
  • 低风险：低敏感度信息泄露、易缓解的干扰性DoS、需要极不可能前提条件的问题。

References

参考资料

  • Output contract and full prompt template: 
    references/prompt-template.md
  • Optional controls/asset list: 
    references/security-controls-and-assets.md
Only load the reference files you need. Keep the final result concise, grounded, and reviewable.
  • 输出规范及完整提示模板：
    references/prompt-template.md
  • 可选控制措施/资产列表：
    references/security-controls-and-assets.md
仅加载所需的参考文件。最终结果需简洁、有依据且便于审查。