Four frameworks that make threat modeling actually work
DREAD, Trike, OCTAVE and PASTA each solve a different problem. Together they give you something most security programmes lack: a threat model your engineers, your CISO and your board all find credible.
Every security team has a version of the same conversation. Engineering says "we've threat-modeled this." The CISO asks "what does that mean, exactly?" And somewhere between a DFD on a whiteboard and a JIRA ticket marked "security risk," the threat model — the one that was supposed to drive priorities — quietly stops influencing anything. The root cause is almost always the same: one framework trying to answer all the wrong questions at once.
STRIDE tells you what type of threat you're facing. That's useful, but it doesn't tell the CEO why they should care or tell the dev team which of the thirty flagged issues to fix on Monday. DREAD, Trike, OCTAVE Allegro and PASTA each exist because STRIDE alone — or any single framework alone — leaves a gap. Understanding what each one is actually for is the difference between a threat model that fills a slide and one that drives a remediation backlog.
The four frameworks — and what each one actually answers
DREAD — Which threat do we fix first?
DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is a scoring rubric, not a discovery method. You use it after you've identified threats — to turn a flat list of twenty issues into an ordered backlog with a defensible rationale behind it.
Each dimension is scored 0–10, summed and divided by 5. The result is a priority number that any engineer, product manager or auditor can interrogate. When a developer asks "why is this SQL injection higher priority than the session token issue?", you have an answer grounded in five measurable dimensions — not gut feel.
The most common mistake: applying DREAD too early, before the threat inventory is stable. Use it as the final gate before you write tickets, not as a discovery exercise. Pair it with STRIDE or pytm for the upstream identification step, then score in DREAD.
Trike — Who is allowed to do what, and what happens when they aren't?
Trike approaches security from the perspective of permissions, not vulnerabilities. The core artefact is a matrix: actors on one axis, assets on the other, and for each intersection a set of allowed actions (Read, Write, Delete, Execute). A threat, in Trike's language, is simply a case where an actor can perform an action they shouldn't be permitted to perform.
This makes Trike uniquely suited to systems where access-control complexity is the dominant risk: multi-tenant SaaS, financial APIs with role hierarchies, healthcare platforms with consent flows. When you find an IDOR vulnerability in an API that should enforce per-tenant isolation, the Trike matrix makes it immediately visible: Actor "API consumer" has Read on Asset "all user records" — should be scoped to own tenant only.
The matrix also becomes a living contract. When a new feature adds a permission, the team updates the matrix first. Anything that doesn't fit cleanly into the existing permission model becomes a conversation before it becomes a vulnerability.
Best for: access-control-heavy systems · multi-tenant SaaS · RBAC audits · privilege escalation analysisOCTAVE Allegro — What does the business actually stand to lose?
OCTAVE Allegro (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is the only framework on this list that starts with the business, not the technology. Its eight steps are structured as workshops, not technical reviews: the first people in the room are business owners, not engineers.
The output is a prioritised set of information assets with their threat scenarios scored against five impact areas that the organisation itself defines upfront: reputation, financial, productivity, safety and regulatory. The scoring is not CVSS — it's "what does this organisation care about most?" before anything technical is examined.
This matters more than it sounds. A healthcare startup and a retail chain might face the same technical vulnerability, but the business impact differs by an order of magnitude. OCTAVE forces that conversation to happen before the threat model is drawn, not after the findings come in. The result is a risk prioritisation that a CFO or a board can actually review — and challenge.
Best for: boardroom risk presentations · organisations without a security team · GDPR/NIS2 impact assessments · pre-pentest scopingPASTA — What would a real attacker actually do?
PASTA (Process for Attack Simulation and Threat Analysis) is the most complete framework here and the most demanding. Its seven stages move from business objectives all the way through to simulated attack paths and residual risk — but the differentiating stage is Stage VI: attack modeling. This is where PASTA diverges from every other framework by asking not "what could go wrong?" but "how would an attacker actually chain these vulnerabilities to reach their objective?"
The practical output is an attack tree: a structured diagram showing the sequence of steps a threat actor takes from initial access to impact. Combined with threat intelligence about the TTPs relevant to your sector and tech stack, it produces something clients find far more compelling than a list of CVEs: a narrative. "Here is the path an attacker takes to exfiltrate your customer data. Here are the three places where a control would break that chain."
PASTA is most effective when applied to a specific system that processes high-value data — payment flows, PII stores, authentication services. Running a full seven-stage PASTA across an entire organisation is usually a multi-week engagement. Running it on a single critical microservice is a powerful two-day exercise.
Best for: high-value targets (payments, PII, auth) · compliance contexts (PCI-DSS, GDPR) · executive-level risk reporting · pre-launch security gatesChoosing the right framework — or the right combination
The choice isn't always one framework. In a full engagement we typically stack them: OCTAVE Allegro to anchor the business risk conversation first, STRIDE or pytm to enumerate technical threats systematically, DREAD to score and prioritise what we find, and PASTA to build the attack narrative for the two or three scenarios that matter most. Trike enters when access control is the dominant concern.
| Situation | Framework | Why |
|---|---|---|
| No security team; need to brief the board | OCTAVE Allegro | Business-first, no technical prerequisite |
| 20+ threats to triage before the sprint | DREAD | Turns a flat list into a scored backlog in under two hours |
| Multi-tenant SaaS with complex RBAC | Trike | Makes permission violations structurally visible |
| Payment flow or PII store before launch | PASTA | Produces a real attack chain, not a checkbox |
| Full security audit, compliance context | All four, in sequence | Each layer covers what the previous one leaves out |
What a combined engagement looks like in practice
A practical four-week engagement that we run for clients preparing for a security audit or a high-stakes launch typically unfolds like this:
- Week 1 — OCTAVE Allegro workshops. Two half-day sessions with business and IT stakeholders to identify critical information assets, their containers and the impact areas that matter most to the organisation. Output: a ranked list of assets and the five highest-risk scenarios to examine in depth.
- Week 2 — Technical threat enumeration. Architecture review, DFD construction, STRIDE analysis with Threat Dragon or pytm in the CI pipeline. Output: a complete threat inventory, typically 15–40 findings depending on system complexity.
- Week 3 — DREAD scoring + Trike matrix. Score every finding in DREAD to produce a prioritised remediation backlog. If access control is a material concern, build the Trike actor–asset matrix and audit the permission model against it. Output: a prioritised backlog with owner assignments and a clean permission model.
- Week 4 — PASTA attack simulation. Run PASTA Stages IV–VII on the top two or three scenarios from Week 1. Build attack trees for each, map to MITRE ATT&CK, and calculate residual risk after proposed controls. Output: an executive report with attack narratives, a technical remediation plan and evidence for any compliance audit.
The failure mode to avoid
The pattern we see most often in organisations that have tried threat modeling and abandoned it: they ran a single framework, produced a report that nobody read and concluded that threat modeling "doesn't work here." It usually wasn't the framework that failed — it was the scope. PASTA applied to an entire enterprise is an unmanageable exercise. DREAD applied without a prior threat inventory is noise. OCTAVE without technical follow-through stays theoretical.
Threat modeling works when it is scoped tightly enough to produce decisions, and sequenced correctly so that each framework's output feeds the next. The goal is not comprehensive documentation. The goal is to change what gets built, and in what order.
This article reflects NexusFinLabs' own view based on publicly available framework documentation and our engagement experience. It is general guidance, not legal or compliance advice.