threat-modeling

• SKILL.mdcore · 7,336 bytes
• SKILL.mdcore · 7,336 bytes
• metadata.jsonasset · 1,276 bytes
• references/design-level-failures.mddoc · 6,232 bytes

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/threat-modeling/SKILL.md. -->

# Threat Modeling

Decide what a design must be true before code exists: naming assets and actors, locating trust boundaries, producing a written (asset, boundary, threat, control, owner) list, recording the assumptions the design rests on, and knowing when a change invalidates the model. Use when scaffolding a new feature, service, or endpoint, writing or reviewing a design doc, RFC, or ADR, or introducing a new trust boundary, integration, or data flow.

## ALWAYS

- Produce a **written list**, not an impression. One row per finding, in the design doc, the RFC, or the PR description: `(asset, boundary, threat, control, owner)` — what is worth taking, where it crosses, what could go wrong there, what stops it, and which component enforces it. A model that exists only in the reasoning that produced the code cannot be reviewed, disagreed with, or checked later.
- Name the **assets** and the **actors** first: data, funds, credentials, keys and compute on one side; users, tenants, services, admins and the attacker on the other. Every later row references one of each, which is what makes the list finite.
- Locate the **trust boundaries** — internet to application, tenant to shared store, service to service, user input to an interpreter, model output to anything that acts on it. A boundary is where data arrives from a party you do not control, and it is the unit the rest of the model is organised around.
- At each boundary, ask the six **STRIDE** questions and write down only the answers that matter: can the caller be **spoofed** (is there authentication), can the data be **tampered** with in flight, will there be a record if someone **repudiates** the action, what is **disclosed** if this crossing leaks, what happens under **denial of service**, and does anything here allow **elevation of privilege**. A category with no answer is not a gap; a category nobody asked about is.
- Write down the **assumptions the design depends on**: this gateway is the only ingress, this queue's producers are authenticated, this field is already validated upstream, this CDN strips that header. Assumptions are the part of a threat model that later becomes false without anyone noticing, and an unwritten one cannot be rechecked.