Risk based vulnerability management ranks findings by how likely they are to hurt you, not by severity score alone. It combines evidence of exploitation, whether the vulnerable code is actually reachable, how exposed the system is and what it protects. The aim is a short list your team can finish.
Why does severity alone fail?
A scanner on a mid-sized application can return hundreds of findings. If the plan is "fix every High and Critical", the queue never empties and the work stops matching the real danger.
CVSS describes how bad a flaw could be in general. It does not say whether anyone is exploiting it, whether your build even loads the vulnerable function, or whether the service faces the internet. Two findings with the same score can deserve very different urgency.
Which signals do you add?
Four inputs carry most of the weight.
Known exploitation. CISA maintains the Known Exploited Vulnerabilities catalog, a list of flaws exploited in the wild. For each entry it shows a due date, and it tells users to apply mitigations, evaluate internet exposure and stop using the product if no mitigation exists. A KEV match moves a finding to the top of the queue.
Probability of exploitation. FIRST publishes EPSS, a model that estimates the chance a published CVE is exploited in the next 30 days, as a score from 0 to 1 updated daily. FIRST recommends using it alongside CVSS and KEV, not instead of them.
Reachability. A vulnerable library function that your code never calls is a lower priority than one on a request path. This is the signal that most changes application findings, because dependencies bring in far more code than an app uses.
Context. Internet facing or internal, holds customer data or not, runs with broad credentials or narrow ones. Only your team knows these.
What does it look like on a real queue?
Constructed example: a scan of one web service returns 140 findings in third party packages.
- 6 are on the KEV list. Of those, 2 sit in code the service actually calls.
- 18 have a high EPSS percentile but no reachable path.
- The remaining 116 are theoretical or in development only code.
A severity-only plan assigns 140 tickets. A risk based plan assigns 2 emergency fixes, 4 scheduled upgrades, a watch on the 18, and a documented decision on the rest. The numbers are invented, but the shape is typical: exploitation evidence plus reachability shrinks the urgent list by an order of magnitude.
Where does the secure development framework fit?
NIST SP 800-218, the Secure Software Development Framework, asks organizations to identify and confirm vulnerabilities on an ongoing basis, analyze each to find its root cause and plan remediation. It treats this as a repeatable process, not a one time audit. Risk ranking is how you decide the order inside that process.
What goes wrong?
Teams often stop at score arithmetic and forget the human step. A ranking is a proposal. Someone with ownership of the service has to accept the risk of what is deferred and write down why, with a review date.
Another trap is trusting a single feed. KEV is authoritative but intentionally narrow. EPSS is a probability, not a verdict. Use them together and let reachability and context break ties.
Safeguard applies reachability analysis to dependency findings so the list reflects code that can actually run, and its policies and gates can block merges on the findings you decide matter. The ranking logic above still applies whichever tool produces the data.
How to check or apply this
- Inventory the applications and services that matter, with an owner for each.
- Pull every finding into one list, including dependency, code and container results.
- Tag each finding with KEV status and an EPSS score.
- Mark whether the vulnerable code is reachable, and whether the service is exposed.
- Set service levels by tier, for example days for reachable KEV items, weeks for reachable high EPSS, quarterly for the rest.
- Record every deferral with an owner, a reason and a review date.
- Review the rules every quarter against what was exploited.
Quick check
Is a high CVSS score enough to justify an emergency fix?
No. It shows potential severity. Add exploitation evidence, reachability and exposure before deciding how fast to move.
Does a low EPSS score mean you can ignore a finding?
Not automatically. EPSS is a probability for the next 30 days. A finding that is on the KEV list or sits on an exposed, reachable path still deserves attention.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System (EPSS)
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
