Building a real threat model

Why this matters

Threat modelling is the engineering discipline of doing all of the above (mindset + STRIDE + attack trees + ATT&CK + OWASP) for a specific system before you ship it. The artefact is a short document; the value is the conversation that produces it. Done right, it surfaces 80% of the security work a feature needs before any code is written.

Demo

A useful threat model fits on two pages: (1) what is this system, drawn as boxes and arrows; (2) what's the trust boundary at each arrow; (3) what could go wrong at each boundary (STRIDE); (4) what controls handle each; (5) what residual risk remains.

Try it yourself

1. Pick a small feature in your product. Draw the dataflow with trust boundaries marked.
2. At each boundary, write one threat per STRIDE letter that applies.
3. For each, note the control (existing or planned) and any residual risk. Review with a teammate.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain what a threat model artefact looks like in practice.

2. Why it works (the mechanism)

Walk me through threat-modelling a specific feature step by step — what's drawn, what's discussed, what's written down.

3. Advanced — application & what's next

How do you keep a threat model alive as the system evolves? When does it stop being useful?

References

• OWASP — Threat Modeling Cheat Sheet
• Microsoft Threat Modeling Tool