The frameworks we use to find what can go wrong.
Threat modeling answers one question early, while it's still cheap to fix: "what can go wrong here?" These are the established frameworks we apply to audit our clients' systems and AI — from a single application to an organisation-wide security programme. Each has a focus and a moment where it fits best.
Why threat modeling, and why frameworks
Security defects are cheapest to fix at design time and most expensive in production. Threat modeling maps a system — its components, data stores, data flows and trust boundaries — and reasons systematically about how an attacker could abuse it, before the attacker does. A framework keeps that reasoning structured, repeatable and auditable instead of ad-hoc.
No single framework is "best". STRIDE excels at discovering technical threats in a design; DREAD ranks them; PASTA and OCTAVE align them to business risk; VAST scales the practice across DevOps; Trike formalises acceptable risk; attack trees dissect a specific attacker goal. In practice we combine them — most commonly STRIDE + data-flow diagrams to find, then a risk scheme to prioritise.
The frameworks
STRIDE
Six threat categories — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — applied per element of a data-flow diagram.
What it is & how we apply it → Risk-centric · 7 stagesPASTA
Process for Attack Simulation and Threat Analysis. A seven-stage, business-aligned method that simulates real attacks against your assets.
What it is & how we apply it → Prioritisation · ScoringDREAD
Damage, Reproducibility, Exploitability, Affected users, Discoverability. A scoring scheme to decide which threats to fix first.
What it is & how we apply it → Organisational · CERT/SEIOCTAVE
Operationally Critical Threat, Asset and Vulnerability Evaluation. Risk management at the organisation level, driven by critical assets.
What it is & how we apply it → Scale · Agile / DevOpsVAST
Visual, Agile and Simple Threat modeling. Designed to scale threat modeling across large teams and CI/CD pipelines.
What it is & how we apply it → Requirements · Open sourceTrike
A requirements- and risk-management approach built on an actor–asset–action model, with explicit acceptable-risk levels.
What it is & how we apply it → Analysis · SchneierAttack Trees
Decompose a single attacker goal into the concrete steps and alternative paths that could achieve it, then analyse each path.
What it is & how we apply it → AI-specific · OWASPOWASP LLM Top 10
The threat landscape for generative-AI applications — the lens we add on top of these frameworks when the system is an LLM or agent.
See the AI threat landscape →Side by side
The same job — understanding risk — seen from different altitudes. Pick by what you need to produce:
| Framework | Primary focus | Granularity | Best when you need to… |
|---|---|---|---|
| STRIDE | Discover technical threats by category | Component & data-flow | Find what can go wrong in a design Discover |
| PASTA | Risk- and attacker-centric, business-aligned | System & business | Connect assets, impact and realistic attack scenarios |
| DREAD | Quantify and rank threat severity | Per-threat score | Decide what to fix first Prioritise |
| OCTAVE | Organisational risk, asset-driven | Organisation | Run a security programme, not just one app |
| VAST | Scalable, automation-friendly modeling | App + operational | Embed threat modeling in agile / DevSecOps |
| Trike | Requirements & acceptable-risk management | System | Formalise controls and what risk is acceptable |
| Attack Trees | Decompose a specific attacker goal | Goal & path | Analyse the routes to one high-value objective |
Categories and stage names follow each framework's published references (Microsoft, OWASP, CERT/SEI, ThreatModeler and others). This page is general guidance, not legal advice.
How we apply them in an engagement
- Map the system — components, data stores, data flows and trust boundaries, as a diagram both sides agree on.
- Discover — walk each element through the right framework (usually STRIDE) and enumerate concrete threats.
- Prioritise — score with DREAD or a risk matrix so effort goes where impact and likelihood are highest.
- Validate — red-team the live system to confirm which threats are real, not just theoretical.
- Mitigate & document — design changes and controls, mapped to OWASP, the EU AI Act and NIST so auditors recognise the evidence.