rgoussu.dev
rgoussu@goussu: ~/library/security
❯ ~/library/security cat threat-modeling.md

Threat modeling

# Finding what can go wrong before building it — assets, trust boundaries, STRIDE, and keeping the practice lightweight.

Conceptsaved 2026-08-08 #threat-modeling#security#design#architecture

Overview

Threat modeling is structured pessimism at design time: what are we building, what can go wrong, what will we do about it, and did we do enough (Shostack's four questions). It is the cheapest security work there is — a whiteboard hour that prevents the vulnerability classes no scanner will ever find, because they're flaws in the design, not the code.

Key points

  • Start from a data-flow diagram: components, data stores, external entities, and — the crucial part — trust boundaries (internet→edge, service→service, app→database); threats cluster at the boundaries.
  • STRIDE as the checklist: Spoofing (identity), Tampering (integrity), Repudiation (deniability), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorization) — walk each boundary asking all six.
  • Rank, don't drown: impact × likelihood (a lightweight DREAD substitute) to pick what's worth mitigating; explicitly accept the rest — an accepted risk written down beats an unexamined one.
  • Mitigations map to the catalog: each STRIDE finding points at a standard control — authn (auth), TLS/signing (TLS & certificates), audit logs, rate limits, least-privilege IAM.
  • Keep it lightweight and recurring: a session at design time for each significant feature, revisited when the architecture changes — not a one-off compliance artifact. "What's the worst thing a malicious insider / a stolen laptop / a compromised dependency could do here?" is a fine informal starter.
  • Abuse cases beat checklists for business logic: fraud, scraping, workflow abuse (buy at stale price, redeem twice) are invisible to STRIDE unless you model the incentives.
  • To explore: attack trees, LINDDUN (privacy threats), threat modeling for LLM/agent systems (prompt injection as a new trust-boundary class).

Practice

  • Elevation of Privilege card game (source) — Shostack's card game that teaches STRIDE by play; the warm-up that makes the checklist stick.
  • OWASP Threat Dragon (source) — draw a data-flow diagram of your own app, annotate trust boundaries, and generate the STRIDE threats against them.
  • OWASP Cornucopia (source) — card-driven elicitation for a web app's specific threats, including the business-logic abuse cases STRIDE misses.
  • Threat-model your own service (source) — run Shostack's four questions on a design you own, rank by impact × likelihood, and write down the risks you accept.

Related