From threats to priorities: ranking risk and choosing mitigations
A threat list is a backlog, not a plan. This lesson turns enumerated threats into priorities with likelihood x impact, explains why DREAD lost the room, and walks the four mitigation responses — mitigate, eliminate, transfer, accept — down to residual risk.
Your STRIDE pass on the checkout service produced forty-one threats. The DFD made every trust boundary visible, the attack trees showed three credible paths to a forged price, and the abuse cases read like a hostile QA suite. It is Thursday afternoon, the sprint has room for maybe two security stories, and your tech lead asks the only question that matters: which two? Forty-one threats is not a plan — it is a backlog with no order. The whole value of the model evaporates if you can’t say which threat gets the engineer-week and which one waits a quarter. Ranking is where threat modeling stops being a diagramming exercise and starts paying rent.
By the end of this lesson you’ll be able to take an enumerated threat list and turn it into a defensible, budget-aware priority order, then choose the right mitigation response for each — and know which one you’ll deliberately accept.
From a list to an order: likelihood x impact
The output of STRIDE, DFDs, and attack trees is a set — unordered by construction. Prioritization imposes an order, and the workhorse axis is risk = likelihood x impact. Likelihood is how plausible the attack is given a real adversary: does it need a nation-state and a zero-day, or a bored user editing a URL? Impact is what it costs you when it lands: a defaced marketing page is not a leaked customer table, and neither is a price-tampering bug that lets every order ship for one cent.
The reason you multiply rather than add is that risk is dominated by its weakest justification. A catastrophic impact with negligible likelihood is a low-risk cell; a trivial impact that happens constantly is also low. The threats that should keep you up are the ones high on both axes — and the multiplication makes that fall out of the arithmetic instead of out of an argument. The point of a rating is not false precision. It is to force a consistent, repeatable conversation so that two engineers scoring the same threat land in the same neighborhood, and so the ranking survives the person who built it leaving the team.
Why DREAD lost the room
For years the default scoring scheme was DREAD — Damage, Reproducibility, Exploitability, Affected users, Discoverability — each rated 1–10 and summed. It reads scientific and it isn’t. The problem is that the inputs are subjective and the scale is undefined: there is no shared rubric for what makes Damage a 6 versus a 7, so two reviewers rate the same threat differently, and the same reviewer rates it differently on Tuesday. Discoverability is actively harmful as a factor — it rewards security-through-obscurity by lowering the score of a bug just because it’s currently hard to find, which is exactly backwards from how you should reason about an adversary who has all the time in the world. Microsoft, which popularized DREAD, quietly retired it internally for these reasons. A scoring system whose output you can’t reproduce isn’t a measurement; it’s a number that looks like one, which is worse, because it launders a guess as data.
What teams reach for instead is a small ladder of better-calibrated tools, picked by what you’re scoring:
- Qualitative risk matrices for threats from a model. A 3x3 or 5x5 grid of likelihood x impact, with each band defined (“High likelihood = exploitable by an unauthenticated user with public tooling”). The defined bands are the whole point — they make the score reproducible without pretending to two decimal places.
- CVSS for known vulnerabilities — a CVE in a dependency, a finding from a scanner. CVSS gives a standardized, vendor-neutral 0–10 base score from defined metrics (attack vector, complexity, privileges required, scope, CIA impact), so “CVE-2023-xxxx is a 9.8” means the same thing across teams and tools. CVSS is for vulnerabilities you can point at; it is not built to rank design threats you reasoned out of a DFD.
- OWASP Risk Rating Methodology when you want a defined-but-flexible factor model. It splits likelihood (threat-agent + vulnerability factors like skill, motive, ease of discovery, ease of exploit) from impact (technical + business factors), scores each factor on a defined 0–9 scale, and combines them into a Low/Medium/High matrix — DREAD’s ambition with actual rubrics under it.
The senior move is to match the instrument to the input: matrix for modeled threats, CVSS for catalogued CVEs, OWASP Risk Rating when you need an auditable factor breakdown. Mixing them — scoring a design threat with CVSS, or a dependency CVE with a hand-wave — produces numbers nobody trusts.
| Likelihood ↓ / Impact → | Low impact | Medium impact | High impact |
|---|---|---|---|
| High likelihood | Medium — fix soon | High — this sprint | Critical — drop everything |
| Medium likelihood | Low — backlog | Medium — fix soon | High — this sprint |
| Low likelihood | Low — accept / monitor | Low — backlog | Medium — the trap cell |
The trap cell: low likelihood, high impact
The most expensive mistake in ranking is not over-scoring noise. It is rounding a low-likelihood, high-impact threat down to zero because “it’ll never happen.” That bottom-right cell in the matrix is where tail risk lives, and tail risk is what ends companies. A backup-restore path that has never been exercised, a cloud-metadata SSRF that needs a specific misconfiguration, a price-tampering bug that requires intercepting a request — each feels remote until the day the conditions line up, and then the impact is total. The discipline is to treat that cell as Medium, not zero: it doesn’t outrank a high-likelihood-high-impact item this sprint, but it earns a tracked decision — a compensating control, a monitor, an alert — rather than silent omission. The failure mode is specifically the silent drop: a threat that was never written down can never be reviewed, and “we decided the risk was acceptable” is a defensible position only when there’s a record that you decided it.
▸Why this works
Why not just rank everything and work top-down until the sprint is full? Because engineering budget is finite and mitigations have wildly different costs. A high-risk threat fixed by adding one server-side authorization check is cheap value; a medium-risk threat that needs a three-week re-architecture is expensive value. Senior prioritization weighs risk reduction per unit of effort, not raw risk — sometimes you knock out four medium threats with cheap fixes instead of one high threat that costs a month, because the total risk burned down is greater. Raw rank tells you what matters; cost-adjusted rank tells you what to do Thursday.
Four responses: mitigate, eliminate, transfer, accept
A ranked threat is not done until you’ve chosen a response, and there are exactly four. Mitigate (reduce) — add a control that lowers likelihood or impact: rate-limit the reset endpoint, scope the query to the owner, add a WAF rule. This is the common case, and it almost never drives risk to zero — what’s left over is residual risk, the risk that remains after the control. Eliminate (avoid) — remove the feature or asset entirely: if a “fetch arbitrary URL” feature is the SSRF, and the product can live without it, deleting it removes the threat instead of guarding it. The cheapest vulnerability to fix is the one you never shipped. Transfer — shift the financial consequence to someone else: cyber-insurance, or a payment processor that owns PCI scope so a card-data breach is contractually theirs. Transfer moves the cost, not the event — the breach still happens, the customer is still affected, and your reputation isn’t insurable. Accept — decide the residual risk is below your bar and consciously do nothing, with a recorded sign-off from someone with the authority to own that decision.
Your model flags a low-likelihood, high-impact threat: a 'fetch image from URL' feature could be turned into an SSRF against the cloud metadata endpoint. The feature is used by ~2% of customers and the product team is lukewarm on it. Which response is the strongest first move?
Closing the loop: did we do a good job?
A threat model is a living artifact, not a document you file. The honest closing question — did we do a good job? — has two halves. First, validate the model: did we cover the system (every element in the DFD, every trust boundary), did we find the threats that matter, and did the mitigations actually ship and work? A mitigation marked “done” in the model but never merged is a lie the next reviewer inherits. Second, close the loop over time: re-run the model when the architecture changes, feed real incidents and pentest findings back in to recalibrate likelihood (a threat you rated “low likelihood” that just happened is now data, not a guess), and re-rank as the system and the threat landscape move. The model that gets revisited after every breach and every major feature stays true; the one authored once and shelved is stale within a quarter.
Put the end-to-end mini threat-modeling loop in order, from raw enumeration to closing the loop:
- 1 Enumerate threats (STRIDE over the DFD, attack trees, abuse cases)
- 2 Score each threat on likelihood x impact with defined bands
- 3 Rank into a matrix and apply cost-adjusted prioritization under budget
- 4 Choose a response per threat: mitigate / eliminate / transfer / accept
- 5 Validate the model and feed incidents back in to re-rank over time
Why has DREAD fallen out of favor for ranking modeled threats?
You add cyber-insurance to cover the cost of a potential customer-data breach. Which mitigation response is this, and what does it NOT change?
- 01Why is DREAD widely critiqued, and what do teams use instead for ranking threats?
- 02Walk a single low-likelihood, high-impact threat through the four mitigation responses, and explain residual risk.
A threat list is a backlog, not a plan: prioritization imposes order, and the workhorse axis is risk = likelihood x impact (multiplied, so a threat scores high only when both axes are high). The point of a rating is a consistent, repeatable conversation — not false precision — which is exactly why DREAD lost the room: its subjective, undefined factors aren’t reproducible and its Discoverability factor rewards obscurity. Match the instrument to the input: qualitative risk matrices for modeled threats, CVSS for known CVEs, OWASP Risk Rating for an auditable factor breakdown. Under a finite budget, prioritize by risk reduced per unit of effort, not raw rank. Every threat then exits through one of four responses — mitigate (leaving residual risk), eliminate, transfer (the cost, not the event), or accept (with a recorded sign-off). The defining failure mode is silently rounding a low-likelihood, high-impact threat to zero; that tail-risk cell ends companies, so it earns a tracked decision. Finally, close the loop: validate that mitigations actually shipped, and feed real incidents back in to recalibrate likelihood and re-rank as the system moves. Now when someone hands you forty-one threats and two sprint slots, your first question is: which cells are upper-right, which fixes are cheap, and which threat are we deliberately deciding to accept on the record?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.