lidge-jun/security-threat-model

Threat Model Source Code Repo

Deliver an actionable, repo-specific threat model. Anchor every architectural claim to evidence in the repo, keep assumptions explicit, and prioritize realistic attacker goals over generic checklists.

Quick start

1. Collect or infer inputs:

• Repo root path and in-scope paths
• Usage, deployment model, internet exposure, auth expectations (if known)
• Existing repo summary or architecture spec
• Use references/prompt-template.md for repo summary prompts and the required output contract

Workflow

1) Scope and extract the system model

• 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.

2) Derive boundaries, assets, and entry points

• 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

• List risk-driving assets (credentials, PII, integrity-critical state, availability-critical components, build artifacts)
• Describe realistic attacker capabilities based on exposure and usage
• Note non-capabilities explicitly to avoid inflated severity

4) Enumerate threats as abuse paths

• Map attacker goals to assets and boundaries (exfiltration, privilege escalation, integrity compromise, DoS)
• Classify each threat and tie it to impacted assets
• Prefer fewer, higher-quality threats over exhaustive lists

5) Prioritize with explicit likelihood and impact reasoning

• 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

• 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.

7) Recommend mitigations and focus paths

• 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.

8) Quality check before finalizing

• Verify all entrypoints, trust boundaries, and runtime vs CI/dev separation are covered
• Verify user clarifications (or explicit non-responses) are reflected
• Verify assumptions and open questions are explicit
• Match the output format from references/prompt-template.md
• Write to <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.

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.