Threat Modeling

A practical workflow to answer four questions (Shostack's framing): 1) What are we building? 2) What can go wrong? 3) What are we going to do about it? 4) Did we do a good job?

Use early in design, then keep it live as the system changes. Pairs with api-secure-design and llm-app-defense for concrete fixes.

Step 1 — Model the system (what are we building?)

• Inventory assets: data (by classification), credentials, functionality, availability, reputation.
• Draw a data-flow diagram (DFD): external entities, processes, data stores, and data flows.
• Mark trust boundaries — every point where data crosses from less-trusted to more-trusted (internet→API, user input→parser, untrusted text→LLM context, tenant→shared store).
• List entry points and the privilege at each.

Step 2 — Find threats (what can go wrong?)

STRIDE (per element / per boundary)

Apply STRIDE to each process, store, flow, and boundary in the DFD.

PASTA (when you need risk-centric, business-aligned depth)

Seven stages: define objectives → define technical scope → decompose the application → analyze threats → analyze vulnerabilities → model attacks (attack trees) → analyze risk & impact. Use for higher-stakes systems needing business risk alignment.

Attack trees

For a critical asset, put the attacker goal at the root and enumerate AND/OR paths to it. Useful for prioritizing which boundaries matter most.

Step 3 — Decide mitigations (what will we do?)

For each credible threat choose: mitigate / eliminate / transfer / accept (with an owner and rationale for accepts). Map mitigations to controls in:

• api-secure-design for API/auth/input/rate-limit/crypto controls.
• llm-app-defense for LLM-specific injection/agency/output controls.
• Standards: OWASP ASVS, NIST controls, MITRE ATLAS (for AI).

Prioritize by likelihood × impact; track as issues with owners and due dates.

Step 4 — Validate (did we do a good job?)

• Confirm each high/critical threat has a mitigation and a test.
• Feed offensive validation from api-security-audit / llm-redteam back into the model.
• Re-review on architecture changes, new integrations, or new data types.

AI/LLM systems — extra elements to model

• Untrusted text reaching the model (direct + indirect via RAG/tools/files/web) is a trust boundary.
• Tools/agents = new entry points for elevation-of-privilege and tampering.
• Model/plugin/dataset supply chain and RAG corpus as assets and tampering targets.

Deliverable

Fill references/threat-model-template.md. Keep it in the repo next to the design docs so it evolves with the system.

<sub>© 2026 noahfranklin · Part of the Gideon security suite · MIT License · Original work.</sub>