Prioritization
Risk-based vulnerability management: what it is and how to start
Risk-based vulnerability management ranks findings by exploitation, likelihood and asset context instead of CVSS alone. The signals to use and a simple way to start.
By Brandon Sooknanan, Founder, Varaxon Technologies · · 5 min read
Risk-based vulnerability management (often shortened to RBVM) is an approach to fixing security weaknesses in order of the real risk each one poses, rather than working down a list sorted by severity score. It accepts a simple fact: no team can fix everything at once, and most published vulnerabilities are never exploited. The aim is to spend the limited time you have on the small share that attackers actually use, on the systems where it would hurt most.
Why severity alone is not enough
CVSS, the Common Vulnerability Scoring System, describes how serious a vulnerability would be if someone exploited it. It does not say whether anyone is exploiting it, or whether it matters on your network. A large share of published CVEs score High or Critical, so a queue sorted by CVSS puts thousands of items at the top and gives no way to choose between them.
Meanwhile, the CVEs attackers actually use are a much smaller set. Some of them carry only Medium CVSS scores and sit far down a severity-sorted list. Risk-based prioritization moves those up.
The four signals that matter
| Signal | Question it answers | Where it comes from |
|---|---|---|
| Known exploitation | Is this being used in real attacks? | The CISA Known Exploited Vulnerabilities catalog, free and public |
| Likelihood | How likely is exploitation in the next 30 days? | EPSS, a free daily score from FIRST |
| Impact | How bad would a successful attack be? | CVSS base score and vector, usually from NVD or the vendor |
| Asset context | Does it matter here? | Your own inventory: internet exposure, business role, data held, compensating controls |
The first three are the same for everyone and can be looked up for any CVE, for example with the free CVE checker. The fourth only you know. A Critical finding on an isolated test machine can wait longer than a Medium one on the firewall that faces the internet.
A simple priority scheme to start with
You do not need a scoring model to begin. Four bands, applied consistently, beat a sophisticated model that nobody keeps up to date:
| Band | Rule | Suggested deadline |
|---|---|---|
| Fix now | On CISA KEV, or EPSS in the top few percent, and on an internet-facing or critical system | Days |
| Fix next | On CISA KEV or high EPSS anywhere else, or Critical CVSS on an exposed system | Within 14 days |
| Scheduled | High or Critical CVSS with low EPSS and no known exploitation | Within 30 to 90 days |
| Routine | Everything else | Normal update cycle |
Adjust the deadlines to your own remediation SLA. The CVSS vs EPSS vs CISA KEV guide explains how the three public signals relate and where each one falls short.
Decision trees: CISA's SSVC
If you want something more structured than bands, look at SSVC (Stakeholder-Specific Vulnerability Categorization), which CISA publishes as a free decision tree. Instead of a number, it asks a few questions, such as whether the vulnerability is being exploited, whether exploitation can be automated, how much of the system an attacker would control, and how important the affected system is to the mission, then gives one of four outcomes: Track, Track*, Attend or Act.
SSVC is useful when you need to explain a decision to an auditor or a client, because every outcome follows from answers anyone can check.
Common mistakes
- Ignoring the low bands forever. Risk-based means ordered, not optional. Lower-priority findings still need an owner and a deadline, or they pile up and some of them become tomorrow's exploited CVEs.
- Treating EPSS as a verdict. EPSS is a probability that changes daily. A low score today is not a promise. Recheck open findings each cycle.
- Forgetting findings without a CVE. Weak TLS settings, default credentials and end-of-life software often have no CVE, so they get no EPSS or KEV signal. Rank them on exposure and impact instead. See end-of-life software in vulnerability reports.
- Stale asset context. A server that moved behind a load balancer, or a test box that became production, changes the risk. Review the inventory as part of each cycle.
How to start this month
- Export your latest scan in full (CSV, XML or the scanner's native format).
- Look up each unique CVE against the CISA KEV list and EPSS. Both are free downloads.
- Tag each host as internet-facing or internal, and as critical or not.
- Assign every finding a band using the table above.
- Fix the top band first, rescan to prove it, and repeat each cycle.
Doing this by hand works for a small estate but gets heavy quickly, especially across several clients. We built Varaxon Scan Hub to do the lookup and ranking for you: upload an export from Nessus, Greenbone/OpenVAS, Qualys, Rapid7 or another scanner, and every finding is matched against CISA KEV, EPSS and CVSS, grouped into actions and shown in priority order, with the evidence for each ranking. You can see the result on the sample reports. Every new account gets a 14-day free trial, no card needed.
Common questions
What is risk-based vulnerability management?
An approach that ranks vulnerabilities by the real risk they pose, combining evidence of exploitation, the likelihood of exploitation and the importance and exposure of the affected system, instead of sorting by severity score alone.
Is EPSS or CVSS better for prioritization?
They answer different questions. CVSS describes impact if exploited; EPSS estimates how likely exploitation is. Use both, and put CVEs on the CISA KEV catalog ahead of either, because they are already being exploited.
Do I need a paid tool for risk-based vulnerability management?
No. CISA KEV, EPSS and NVD are free, and a spreadsheet can combine them. Tools save time when you have many scans or many clients and need the ranking done the same way every cycle.
Turn your next scan export into a client-ready report.
Run a free pre-flight check