Threat Modeling skill for Codex

A threat model answers four questions: what are we building, what can go wrong, what are we doing about it, and did we do a good enough job. The output is a living document a team can argue with and act on — a DFD, a per-element threat list, and ranked mitigations with owners. Model the design, not an abstract system.

When to model

• A new feature touching auth, payments, PII, or crossing a trust boundary.
• A design change that adds an integration, data store, or external input.
• Before a security review, so the reviewer knows where to look hardest.

Keep scope tight: one feature or flow per model is more useful than a whole-system model that no one finishes.

Workflow

- [ ] 1. Define scope and assets (what we protect, what "bad" means)
- [ ] 2. Draw the data flow diagram with trust boundaries
- [ ] 3. Enumerate threats per element with STRIDE
- [ ] 4. Decide a response for each (mitigate / accept / transfer / eliminate)
- [ ] 5. Rank by risk and assign owners
- [ ] 6. Record assumptions and revisit triggers

1. Scope and assets

Read AGENTS.md and the design doc. List the assets worth protecting (user data, credentials, money, availability, integrity of records) and what an attacker would want. Name the actors: end users, admins, other tenants, the service’s own components, third-party integrations, and the anonymous internet.

2. Data flow diagram

Draw the system as elements and flows. Use four node types and mark every trust boundary (where data crosses from less-trusted to more-trusted, e.g. internet → API, app → DB, tenant A → tenant B). Trust boundaries are where threats concentrate.

[External Entity] --request--> (Process) --query--> [Data Store]
        |  trust boundary: internet | service  |      | trust boundary: service | DB |

• External entities: users, third-party services (no control over them).
• Processes: your services, functions, handlers.
• Data stores: DBs, caches, queues, files, secrets.
• Data flows: the arrows, each labeled with protocol and what it carries.

A simple Mermaid flowchart with subgraph for each trust zone is enough; keep it legible.

3. STRIDE per element

For each element and flow, walk STRIDE. Not every threat applies to every element — the table says which to focus on.

STRIDE	Property violated	Applies most to	Example
Spoofing	Authentication	Entities, processes	Forged token passes as another user
Tampering	Integrity	Flows, stores, processes	Request body modified; DB row altered
Repudiation	Non-repudiation	Processes, stores	Action with no audit trail, deniable
Information disclosure	Confidentiality	Flows, stores	PII over HTTP; error leaks internals
Denial of service	Availability	Processes, flows	Unbounded request exhausts the service
Elevation of privilege	Authorization	Processes	User reaches admin function

Write each threat as a concrete sentence tied to the DFD element: “A standard user calls the admin export endpoint (Process P2) because the role check is only in the UI (EoP).”

4. Response per threat

For each threat pick one: mitigate (add a control), eliminate (remove the feature/ flow), transfer (push to a provider/contract), or accept (document the residual risk and who signed off). Prefer eliminating unnecessary attack surface over bolting on controls. Map each mitigation to a concrete control:

• Spoofing → strong auth, MFA, signed/verified tokens.
• Tampering → TLS, integrity checks, parameterized queries, authorization.
• Repudiation → audit logging with user + action + timestamp.
• Info disclosure → encryption in transit/at rest, least-privilege, careful errors.
• DoS → rate limits, quotas, timeouts, input size caps.
• EoP → server-side authorization on every privileged path, least privilege.

5. Rank and own

Rank by likelihood × impact (High/Medium/Low is enough; use DREAD only if the team wants numbers). Assign each mitigation an owner and a target. The model is only useful if the High items become tickets.

Output contract

## Threat model — <feature> (<date>, <authors>)
Scope: <what's in>. Out of scope: <what's not>. Assets: <list>.

### Data flow diagram
<diagram + trust boundaries listed>

### Threats
| ID | Element | STRIDE | Threat | Risk | Response | Mitigation | Owner |
|----|---------|--------|--------|------|----------|-----------|-------|
| T1 | P2 export | EoP | user reaches admin export | High | mitigate | server-side role check | @x |

### Assumptions
- <e.g. TLS terminates at the LB; DB not reachable from internet>

### Revisit when
- <new integration added / data classification changes / before GA>

Hard rules

• Tie every threat to a specific DFD element; “SQL injection is possible” without a flow is not a threat, it is a worry.
• Do not list threats you have no intention of resolving without an explicit accept + owner.
• A model with no diagram is a checklist, not a threat model. Draw the boundaries.
• Keep it updated: a stale model that claims coverage is worse than none. Record revisit triggers.