Threat Model

Agent Prompt Snippet

Ensure the project has a threat model identifying assets, adversaries, attack vectors, and mitigations. Use STRIDE or PASTA methodology.

Purpose

A threat model is a structured analysis of how a system can be attacked. It answers four questions: What are we protecting? Who might attack it? How could they attack it? What mitigations are in place? The result is an explicit map of the system’s attack surface, the adversaries who might exploit it, and the controls that defend against them.

Threat modeling is not a security audit—it is a design activity. The best time to model threats is during system design, before code is written, when mitigations can be built in rather than bolted on. Retrospective threat modeling (applied to an existing system) is still valuable—it surfaces gaps—but it is more expensive because fixing design flaws in a deployed system costs more than designing them out before launch.

The two most common threat modeling frameworks are STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and PASTA (Process for Attack Simulation and Threat Analysis). STRIDE is a per-component checklist—straightforward for developers to apply. PASTA is attacker-centric—more thorough but more complex. For most software projects, STRIDE applied per data flow is the right starting point.

A threat model is a living document. As the system evolves—new features, new integrations, new deployment environments—the attack surface changes. The threat model must be updated to reflect those changes before they reach production. Many significant security incidents trace to features that were added after the original threat model was written, with no corresponding security review.

Who needs this document

Persona	Why they need it	How they use it
Sam (Indie Dev)	Security intuition is insufficient for finding blind spots; systematic threat modeling catches what intuition misses	Runs a STRIDE pass over data flows before implementing each major feature
Claude Code (AI Agent)	Cannot reason about security trade-offs without knowing what threats are in scope	Reads threat model before implementing any security-affecting feature; validates that proposed controls address documented threats
Priya (Eng Lead)	Governs security review process; uses threat model as the standard for evaluating PRs	Requires threat model update as part of security-affecting PR review checklist
DevOps (CI Operator)	Infrastructure threats (cloud misconfiguration, network exposure) are in scope	Reviews network exposure and IAM policy sections; ensures infrastructure matches documented controls

What separates a good version from a bad one

Criterion 1: Assets are enumerated with their value

✓ Strong: “Protected assets: (1) User credentials — compromise enables account takeover for all users. (2) Payment tokens (Stripe customer IDs) — compromise enables unauthorized charges. (3) Session tokens — compromise enables impersonation. (4) PII database — compromise triggers regulatory notification and reputational damage. (5) API signing keys — compromise enables forged requests from the service’s identity.”

✗ Weak: “We protect user data.” (One sentence cannot inform security architecture. Which data? What value? What is the blast radius if it’s compromised?)

Criterion 2: Threat enumeration uses a consistent methodology

✓ Strong: “STRIDE analysis of the authentication data flow: S (Spoofing) — attacker creates accounts with another user’s email → mitigated by email verification. T (Tampering) — attacker modifies JWT claims → mitigated by RS256 signature verification. R (Repudiation) — user denies login action → mitigated by audit log with IP and timestamp. I (Information Disclosure) — timing attack on password hash comparison → mitigated by constant-time comparison. D (DoS) — credential stuffing attack → mitigated by rate limiting + CAPTCHA after 5 failures. E (Elevation) — user accesses admin endpoint → mitigated by RBAC with explicit role check per endpoint.”

✗ Weak: “Authentication is protected by industry-standard security measures.” (No methodology, no enumerated threats, no specific mitigations. Impossible to audit or improve.)

Criterion 3: Mitigations are testable, not aspirational

✓ Strong: “Mitigation: SQL injection prevention via parameterized queries. Test: CI pipeline runs sqlmap against the dev environment on every merge to main. Current status: 0 findings as of 2026-03-15.”

✗ Weak: “Mitigation: the system is designed to prevent SQL injection.” (How? By what mechanism? How is this verified? “Designed to prevent” is not a control—it is an intention.)

Criterion 4: Accepted risks are explicitly documented

✓ Strong: “Accepted risk: brute-force attacks against the password reset flow are rate-limited to 10 attempts per hour but not completely prevented. A sophisticated attacker with a botnet could bypass rate limiting by distributing requests. Full prevention would require device fingerprinting or CAPTCHA on every reset attempt, which we have evaluated as too high a friction cost for the current user base size. Risk owner: CEO. Review date: 2026-Q4.”

✗ Weak: Nothing. (The absence of an “accepted risks” section typically means risks were identified and quietly set aside, with no record. This creates liability and prevents informed re-evaluation.)

Common mistakes

Threat modeling only the happy path. Most threat models analyze what happens when the system works correctly and an attacker tries to exploit it. Fewer analyze what happens when the system fails—expired certificates, database outages, upstream dependency changes. Failure modes often create security vulnerabilities.

Conflating mitigations with controls. “We use HTTPS” is a mitigation; “TLS 1.3 is enforced at the load balancer, TLS 1.0/1.1 return 403, and cipher suites are restricted to forward-secret variants” is a control. Mitigations are aspirational; controls are verifiable.

One-time documents. A threat model that isn’t revisited before each major release becomes inaccurate and misleading. Establish a threat model review cadence: at minimum, before any feature that changes authentication, data access, or external-facing surfaces.

Missing the supply chain. Third-party libraries, CI/CD pipelines, and cloud provider APIs are part of the attack surface. A threat model that only analyzes first-party code misses one of the most common attack vectors in modern software.

How to use this document

When to create it

Begin threat modeling during system design, before writing implementation code. For each significant new feature, run a mini threat model (STRIDE on the new data flows) before implementation begins. Full threat model reviews at least annually and before major releases.

Who owns it

The security lead or, for smaller teams, the senior engineer with security focus. Reviewed by all engineers whose code touches the threat boundaries. Approved by the tech lead before any security-affecting feature ships.

How AI agents should reference it

get_standard_docs(type="web_app", features=["auth"])
→ threat_model in documents[]
→ agent reads threat model before implementing authentication or data access features
→ agent checks proposed implementations against documented mitigations
→ agent flags new attack surfaces introduced by proposed changes

The prompt_snippet — “Ensure the project has a threat model identifying assets, adversaries, attack vectors, and mitigations. Use STRIDE or PASTA methodology” — tells the agent to verify the threat model uses a structured methodology, not just narrative description.

How it connects to other documents

The Threat Model feeds the Security & Privacy Plan (which is the policy layer built on the threat analysis), Authentication Design (which implements the authentication threat mitigations), Network Segmentation Specification (which implements the network isolation mitigations), and all compliance checklists (which verify specific regulatory threat categories are addressed).