New: Pressure test your SOC 2 report against buyer requirements
Free check
Risk-based vulnerability management (RBVM) prioritizes vulnerabilities by the real-world risk they pose, using asset value, internet exposure, and exploit likelihood, rather than ranking by raw severity score. It turns thousands of findings into the short list that actually reduces risk.
Risk-based vulnerability management (RBVM) is the practice of prioritizing vulnerabilities by the real-world risk they pose, using signals like whether a flaw is being exploited, how exposed the affected asset is, and how much that asset matters, instead of ranking by raw severity. Its goal is to turn an unworkable list of thousands of findings into the short set a team should actually fix first.
The scale of vulnerability disclosure has outrun any team's ability to keep up. More than 40,000 CVEs were published in 2024, and over 46,000 in 2025, a record that climbs year over year (NVD). The backlog is now so large that the U.S. National Vulnerability Database fully analyzes only a fraction of new CVEs (NIST). No security team, and certainly no team of one or two, can patch all of it.
Ranking by CVSS, the traditional severity score, makes the problem worse rather than better. By that measure a large share of findings land in the critical and high buckets, so the list you are told is urgent is still thousands long. And severity is not the same as risk: research from the Cyentia Institute and FIRST found that only about 6% of published CVEs are ever observed being exploited in the wild (Cyentia and FIRST). Prioritizing by CVSS alone sends a small team chasing the roughly 94% of findings attackers never touch, while the few that are genuinely dangerous sit in the same undifferentiated pile.
RBVM layers context on top of severity. The signals that matter most are these.
Two data sources have become the backbone of exploit-aware prioritization. EPSS (the Exploit Prediction Scoring System, maintained by FIRST) gives each CVE a probability that it will be exploited in the next 30 days. At a fixed level of remediation effort, EPSS delivers roughly 93% risk coverage versus about 37% for a patch-everything-CVSS-9-and-up strategy, nearly three times better (Cyentia and FIRST). EPSS has a limitation worth designing around: it can act as a trailing indicator, with scores sometimes rising only after exploitation is already public, so it should not be the only signal.
That is where the CISA KEV catalog comes in. KEV lists vulnerabilities confirmed to be actively exploited. A vulnerability on KEV is not a probability, it is a fact, and it should jump the queue regardless of its CVSS score.
A critical vulnerability on a throwaway staging box is not the same problem as the same vulnerability on the service that holds your customer data. RBVM weights findings by the value of the affected asset, so the systems that would actually hurt you if breached rise to the top.
Whether an attacker can reach the flaw matters as much as the flaw itself. An internet-facing, exploitable medium-severity issue outranks a critical-severity issue on an internal system with no path to it. Mature programs go further with reachability analysis, checking whether the vulnerable code path is actually invoked, since a vulnerable library your application never calls is a much smaller risk.
Active campaigns, public proof-of-concept code, and ready-made exploit modules all raise the odds that a given weakness will be used, and RBVM folds that signal into the ranking.
There are two common ways to act on these signals. The first is a combined risk score that blends CVSS, EPSS, KEV status, exposure, and asset value into a single ranking. The second is a decision framework: SSVC (Stakeholder-Specific Vulnerability Categorization), developed by CISA and CERT/CC, walks each vulnerability through a decision tree, exploitation status, exposure, and mission impact, and outputs an action rather than a number: Track, Track*, Attend, or Act. Numeric scores are easy to sort; decision frameworks are easier to defend to an auditor. Many programs use both.
Traditional vulnerability management finds vulnerabilities and ranks them by severity. RBVM is the same loop with real-risk prioritization added, so remediation effort follows exploitability and exposure instead of raw CVSS. CTEM (continuous threat exposure management) is the broader program that wraps prioritization in continuous scoping, discovery, and validation; RBVM is effectively the prioritization engine inside a CTEM program.
Fencer computes a Priority for every finding automatically, separate from its severity, driven by asset criticality, internet exposure, and exploit likelihood (describable as EPSS). Findings are grouped and deduplicated so the same issue is not triaged repeatedly, and the top of the queue reflects what is genuinely exposed and exploitable rather than what scores high on CVSS. Fencer does not stop at ranking: it also fixes what it can, a pull request for code or a direct correction for supported cloud misconfigurations, and re-scans to confirm the finding is closed, so the short prioritized list actually shrinks instead of just being sorted.
