Risk-Based Vulnerability Management: How to Fix What Actually Matters

Key Takeaways

• Over 48,000 CVEs were published in 2025 alone, and 2026 is on pace to beat that record, so patching everything is not a plan anymore.
• CVSS tells you how bad a flaw could be in theory. It does not tell you if anyone is actually trying to exploit it.
• EPSS adds a real-world exploitation probability to every CVE, and pairing it with CVSS cuts wasted patch cycles.
• Risk-based vulnerability management ranks fixes by exploitability, exposure, and business impact, not by severity score alone.
• CTEM is the bigger program risk-based vulnerability management fits inside. One is a mindset shift, the other is the five-stage cycle that operationalizes it.

A mid-sized security team gets a scanner report on a Monday morning. It has 4,200 open findings. 380 are rated critical. The team has three engineers and a two-week patch window. By Friday, they will have closed maybe 60 tickets, and they will have no idea if they picked the right 60.

That story plays out at companies of every size, every single week. It is not a staffing problem. It is a prioritization problem, and it is exactly what risk-based vulnerability management was built to fix.

Why Patch-Everything Vulnerability Management Doesn’t Work Anymore

The old model was simple. Scan, score with CVSS, patch anything above a 7, repeat. It made sense when a few thousand CVEs came out each year. It does not make sense now.

Researchers logged 48,185 CVEs in 2025, a new record, and the CISA Known Exploited Vulnerabilities catalog grew to 1,484 entries, with 246 added in that year alone. That works out to roughly 131 new vulnerabilities a day, and the window to act is shrinking fast. Median time to exploit is now under five days. Some forecasts put 2026’s total closer to 59,000 CVEs, which would mean a mid-sized team doing even a five-minute triage per CVE would burn over six hours a day just reading tickets, before fixing a single one.

Here’s the part that should change how your team works: most of that volume is never touched by an attacker. Historically, fewer than 5% of published CVEs are ever exploited in the real world. Teams that patch by CVSS severity alone are guessing at which slice of that 5% they landed on. One analysis of organizations that patch everything scored CVSS 7 or higher found that only 2.3% of those “critical” fixes were ever actually attempted in the wild that month. That is a lot of engineering hours spent on flaws nobody was ever going to touch, while the ones that mattered sat in the same queue, untouched, ranked no differently.

This is the gap risk-based vulnerability management closes. Instead of asking “how severe is this on paper,” it asks “how likely is this to get exploited, on this system, tied to this asset, right now.”

What Risk-Based Vulnerability Management Actually Means

Risk-based vulnerability management is a prioritization model that scores and ranks vulnerabilities using real-world exploit likelihood and business context, not just technical severity. It layers three signals on top of each other:

• CVSS for technical severity. How bad is this flaw if someone pulls it off?
• EPSS for exploitation probability. How likely is someone to actually pull it off?
• Asset context for business impact. Does this sit on a crown jewel asset, or a dev sandbox nobody logs into?

CVSS alone measures theoretical impact, not the likelihood of an attack happening. That gap is exactly why the Exploit Prediction Scoring System exists. It assigns every CVE a probability score between 0 and 1, representing the estimated chance of exploitation in the next 30 days, and higher scores point to a greater likelihood of exploitation. That single number gives security teams a way to prioritize by real threat instead of gut feel.

How to Operationalize EPSS in Vulnerability Prioritization

Knowing EPSS exists is one thing. Wiring it into a daily workflow is another. A practical approach looks like this:

• Set a floor, not a cutoff. Pull EPSS scores into your scanner or ticketing pipeline and flag anything above a threshold like 0.5, but don’t ignore lower scores on assets that matter. A 0.3 score on a crown jewel asset can outrank a 0.7 score on an isolated test box.
• Pair it with CVSS, never replace it. A vulnerability with high CVSS and high EPSS is your fire alarm. High CVSS with low EPSS can usually wait behind a compensating control.
• Recalculate weekly, not quarterly. EPSS scores move as new exploit code surfaces, so a flaw that was quiet last month can jump this month.
• Feed in KEV status. If CISA has confirmed active exploitation, that overrides both scores and jumps straight to the top of the queue.
• Tie the score to an owner and an asset. A number with no owner attached just becomes another line on a spreadsheet nobody opens.

This is also where a lot of teams realize CVSS was never built to carry the whole decision. One recent breakdown of the scoring gap put it plainly: a technical severity number and a business risk number are not the same thing, and treating them as interchangeable is how the wrong tickets get worked first, an idea covered in more depth in Secure.com’s piece on why CVSS scores are not risk scores.

CTEM vs Risk-Based Vulnerability Management

These two terms get used almost interchangeably, and that causes confusion. They are related, but they are not the same thing.

Risk-based vulnerability management is a prioritization method. It changes how you rank the fixes already in your queue.

CTEM, or Continuous Threat Exposure Management, is the full program those rankings live inside. Gartner created it in 2022 as a five-stage cycle: scoping, discovery, prioritization, validation, and mobilization. It covers far more than CVEs, including misconfigurations, identity gaps, and exposed cloud assets across the whole attack surface. Risk-based vulnerability management is essentially the engine that powers the prioritization stage of a CTEM program.

Adoption is moving fast for good reason. A recent Gartner survey found 71% of organizations believe they could benefit from a CTEM approach, and 60% are already running one or actively building toward it. Gartner has also predicted that organizations that prioritize security investments through a continuous exposure management program will be three times less likely to suffer a breach.

Think of it this way. Vulnerability management, attack surface management (including EASM for what’s exposed externally), and breach and attack simulation are all inputs. A CTEM program pulls them into one loop, and risk-based scoring is what tells that loop where to point first. If you want the full five-stage breakdown, here is a walk-through of it end-to-end in CISO guide to CTEM.

Building a Risk-Based Vulnerability Management Program That Works

A working CTEM program built around risk-based vulnerability management usually has four moving parts.

Exposure prioritization. Rank findings by CVSS, EPSS, KEV status, and asset criticality together instead of any single number. This is where most of the noise gets cut before anyone touches a ticket.

Crown jewel assets. Map every finding back to what it touches. A flaw on your payment processor and the same flaw on an internal wiki are not the same risk, even with an identical CVSS score. Teams that skip this step end up patching in the dark.

Attack path analysis. Individual findings rarely tell the whole story. A low-severity misconfiguration next to a medium-severity IAM gap can chain into a full compromise of a crown jewel system. Mapping those paths shows which single fix breaks the most chains, which often matters more than fixing the highest-scored item on the list.

Exposure validation and remediation mobilization. Confirm the exposure is real, often through breach and attack simulation, then route the fix to the right owner with a clear deadline. A prioritized list that never reaches an owner accomplishes nothing.

FAQs

The Bottom Line

You will never patch every CVE, and trying to is how the ones that matter get lost in the ones that don’t. Risk-based vulnerability management gives your team a way to sort real risk from noise using exploitability, exposure, and business context together. Start small: pull EPSS into your existing pipeline, map your crown jewel assets, and rank from there. The queue gets a lot shorter once it only holds the fixes that were ever actually going to matter.