For most teams, rate each threat High, Medium or Low using two questions: how easy is it to exploit, and how bad is the impact. The OWASP community page prefers qualitative ratings over numeric models because numbers can look precise while hiding guesswork and subjectivity.
Why numeric scores mislead in a threat model
A threat model happens before the code exists. You do not have a measured exploit rate or a known user count. Asking a room to score five factors from one to ten produces arguments about the number, not about the threat.
The OWASP Threat Modeling Process page mentions DREAD only in passing, as a numeric risk model, and says qualitative ratings are preferred to limit subjectivity. That is the practical reason to keep the rating simple.
The two questions to ask
The same OWASP page uses two factors.
- Ease of exploitation: is the attack remote, does it need authentication, can it be automated?
- Impact: how much damage could it cause, from full takeover or admin access to a crash or a data exposure, and how many components are affected?
Combine them in a small grid.
| Low impact | Medium impact | High impact | |
|---|---|---|---|
| Easy to exploit | Medium | High | High |
| Moderate effort | Low | Medium | High |
| Hard to exploit | Low | Low | Medium |
The grid is a convention for conversation, not a standard. Adjust the cells to match your own risk appetite, and write the choice down.
Track mitigation status too
The OWASP page places each threat in a profile of non-mitigated, partially mitigated or fully mitigated. Sorting by rating first and status second gives a clear work queue: High and non-mitigated first.
Cost of the fix is a legitimate input
The OWASP Threat Modeling Cheat Sheet says to rank by likelihood and impact while noting that the effort to fix a problem may also factor in. A Medium threat with a ten minute fix often beats a High threat that needs a quarter of work. Record the fix effort next to the rating so the trade is visible.
When numbers still help
Numbers are fine for ranking vulnerabilities after they are found, where a scanner supplies a severity and an exploit signal. They are weaker for design-time threats. Keep the two ideas apart: the threat model rates design risks, and the vulnerability queue rates concrete findings.
Try it yourself
Click through it at your own pace, or open it full screen. Click through it and watch how reachability changes which findings matter, a useful contrast with design-time ratings.
Quick check
Is DREAD wrong to use?
It is not forbidden. OWASP simply prefers qualitative ratings to reduce subjectivity. If your team already uses a numeric model consistently, the bigger risk is inconsistent use, not the model itself.
Who decides the rating?
The group, with the security voice and the feature owner both heard. Record the reason for any threat you accept, so a later reader can challenge it.
A note on tooling
Design ratings and scanner severities answer different questions. Safeguard covers the second one with dependency scanning and reachability analysis, which shows whether a vulnerable function is actually called. A free scan is a quick way to see that side of the picture.
Sources
Last reviewed: 19 October 2026.
