01Introduction
The most expensive vulnerabilities are design decisions: a service that trusts internal traffic, a tenant ID taken from the request, an admin API on the same host as the public one. Threat modeling is how teams catch those before code exists.
02What is Threat modeling?
Threat modeling is a structured way to identify what can go wrong in a system, who might cause it and what to do about it. Common frameworks include STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), PASTA and attack trees.
It is the earliest form of shift left security, informs what penetration testing should focus on and is expected by frameworks such as SOC 2 and PCI DSS for secure development.
03How Threat modeling works
Most threat models answer four questions.
- 1.
What are we building?
Draw the system: components, data flows, trust boundaries and where sensitive data lives.
- 2.
What can go wrong?
Walk each flow and boundary with STRIDE or attack trees to list threats.
- 3.
What will we do?
Decide to mitigate, accept or transfer each threat, and record the controls.
- 4.
Did we do a good job?
Validate mitigations with review and testing, and revisit the model when the design changes.
04Threats and risks
Threat models fail when they drift from reality.
Stale diagrams
The model describes last year's architecture, not what is deployed.
Unvalidated assumptions
A mitigation marked done was never tested.
Workshop-only
Models built once in a meeting and never connected to code review or testing.
Missed trust boundaries
Internal services and third-party integrations assumed to be safe.
05How Parameter helps
Parameter turns threat model assumptions into tested facts.
Guided testing
Tell AI Pentesting agents what matters, such as tenant isolation or payment flows, and they focus there.
Design drift in review
Sentinel flags pull requests that cross a trust boundary or remove a control.
Proof of mitigation
Retesting confirms that the controls in your model actually hold.
