Threat Modeling

• Draw a data-flow diagram and enumerate trust boundaries
• Apply STRIDE to each component and DREAD to prioritize
• Turn findings into concrete controls before code ships

• The most expensive security bugs are architectural — authentication confusion, insecure trust boundaries — and only visible on the drawing.
• Prevent-by-design beats detect-after-deploy by orders of magnitude.
• A threat model is shareable documentation: reviewers, auditors and attackers all read the same map.
• STRIDE gives names to what might otherwise be a vague 'this feels unsafe'.

You find the ladder leading to the skylight while it's still a drawing, cheap. Same for software: threat modeling looks at a data-flow diagram and asks where the wrong people can get in before a single server is built.

• 1. Build a data-flow diagram (DFD): entities, processes, data stores, trust boundaries.
• 2. Enumerate per component with STRIDE: Spoofing, Tampering, Repudiation, Info disclosure, Denial of service, Elevation of privilege.
• 3. Prioritize with DREAD or likelihood x impact scoring.
• 4. Assign mitigations and owners, and track them like bugs.
• 5. Re-run the model when the architecture changes — modeling is a practice, not a one-shot report.

• A payments team models the transfer flow; STRIDE flags 'spoof another user's transfer' → they add object-level authZ and CSRF tokens.
• An SRE team models the observability pipeline; they find 'repudiation: no audit trail of who deleted the alert' → they add signed audit logs.
• A multi-tenant SaaS models tenant boundaries and finds elevation-of-privilege via shared service accounts → they tighten RBAC per tenant.

• Model early and incrementally; a DFD per sprint-sized feature beats a giant retrospective document.
• Include a 'who is the attacker and what do they profit from?' assumption section — it keeps priority honest.
• Score threats (DREAD or risk matrix) and only fix the top decile; polish every detail helps no one.
• Record mitigations in the SAME issue tracker as bugs so they're owned and reviewed.

• Modeling the happy-path only; attackers don't walk the happy path.
• A wall of DFDs with no prioritized actions — modeling without decisions is theater.
• Treating every element as equally trusted and missing the trust-boundary questions.
• One-and-done: the model goes stale the day the architecture changes.

• When a finding 'feels important but vague', force it through STRIDE to name the risk ('it's spoofing, specifically the session token').
• Trace one user-A request through the whole DFD — trust boundaries you crossed are where controls and flaws both live.
• Compare the DFD against the real deployed topology; drift means the model missed a new boundary.

• Threat modeling is only as good as the assumptions; document who can do what at each step.
• Prioritization must consider business impact and attacker economics, not just exploitability.