What changes after this module
Use threat modelling to shape design choices early instead of treating it as a paperwork exercise after the build.
Outcome promise
- Describe assets, actors, boundaries, and abuse paths for a simple system.
- Turn a threat observation into a design or control decision.
Core model
Use the diagram and terms below as the minimum model you should be able to explain after this module. If you cannot explain the model in plain language, pause here before you move on.
Key terms
- Abuse path
- A plausible route an attacker or careless actor could use to cause harm.
- Mitigation
- A design choice or control that reduces exposure or consequence.
Check yourself
Answer the prompt before you reveal the check. If you cannot answer it in your own words, revisit the model and the terms once more.
Quick check
Why is threat modelling more useful during design than after launch?
Reveal the answer check
Because you can still change structure, flows, and assumptions cheaply before the risky design becomes harder to unwind.
Reflection and evidence
Keep the evidence small. One honest reflection and one small artefact is enough to show that the learning changed how you describe, check, or design something.
Reflection prompt
Pick one product or workflow. What actor, asset, and entry point would you map first?
Artefact
A simple threat model with actors, assets, boundaries, and first mitigations.
Optional deeper practice
Open the workspace and build a threat model for one service or feature you know.
Move through the course
Keep the flow predictable. Stay with the stage sequence unless you have a clear reason to jump around.