CVE prioritization without the noise

The volume problem

The National Vulnerability Database published 29,000 CVEs in 2023. That number increased in 2024. At current rates, a security team that tries to review every published CVE for relevance spends more time on triage than on remediation.

Most organizations respond to this volume in one of two ways. They patch everything above a CVSS threshold, which produces a queue so long that genuinely critical vulnerabilities wait weeks for remediation alongside medium-severity issues that will never be exploited in their environment. Or they patch reactively, after a vulnerability is reported in the press or in a customer breach, by which point exploitation is already active.

Neither approach is a prioritization strategy. Both leave the organization more exposed than necessary, in different ways.

Why CVSS alone fails

CVSS (Common Vulnerability Scoring System) scores vulnerabilities on a 1 to 10 scale based on exploitability, impact scope, and other technical characteristics. A CVSS 9.8 vulnerability sounds alarming. It may be completely irrelevant to your organization.

CVSS does not account for whether your organization runs the affected software. It does not account for whether the software is exposed to the internet or running in an isolated internal environment. It does not account for whether exploit code is publicly available or actively being used in campaigns. A CVSS 9.8 in software you do not run is less urgent to patch than a CVSS 7.5 in a VPN appliance that sits on your network perimeter and has a public proof-of-concept exploit.

The industry has recognized this limitation. CISA's Known Exploited Vulnerabilities catalog, EPSS (Exploit Prediction Scoring System), and vendor-specific severity adjustments all attempt to add context that CVSS lacks. They are improvements. They are not a complete solution without one more ingredient: your specific attack surface.

The filter chain

Effective CVE prioritization applies a series of filters in sequence. Each filter reduces the pool further. What reaches the remediation queue is a small set of vulnerabilities with high relevance, high exploitability, and high exposure in your specific environment.

Filter 1: Asset inventory match

The first question for any CVE is whether you run the affected software. This requires a maintained asset inventory that includes software versions, not just hostnames. Most organizations maintain a partial inventory at best. The gaps create blind spots: a piece of software running on a forgotten server that is not in the inventory does not get patched, regardless of how good the downstream filtering is.

If your asset inventory is incomplete, CVE prioritization starts with improving it. The filter chain only works on the assets you know about.

Filter 2: Exposure context

Not all assets carry equal risk. A vulnerability in software running on an internet-facing host is more urgent than the same vulnerability on an internal system accessible only via VPN. A vulnerability on a host processing financial data or holding credentials is higher priority than the same vulnerability on a development workstation.

This filter requires understanding not just what software you run, but where you run it and what data it touches. Enriching your asset inventory with exposure context (internet-facing vs. internal, data classification, privilege level) takes time upfront and saves significantly more time in ongoing triage.

Filter 3: Exploitation status

Has this vulnerability been exploited in the wild? Is exploit code publicly available? Is it being used by threat actors targeting your sector or geography?

CISA's KEV catalog is a reliable source for confirmed wild exploitation. EPSS provides a probability score for exploitation within 30 days based on multiple signals. Threat intelligence feeds add sector-specific and geography-specific targeting context. A CVE that is in the KEV catalog, has a high EPSS score, and is being used by a threat actor known to target EMEA financial services organizations moves to the top of the queue, regardless of its CVSS score.

A CVE with a CVSS 9.8 score that has no public exploit, affects software in an isolated internal environment, and has no reported wild exploitation can wait for the next scheduled maintenance window.

Filter 4: Compensating controls

Before a vulnerability enters the remediation queue, the last filter checks for existing controls that reduce risk. A WAF rule blocking the exploit path, network segmentation that limits reachability, or an existing detection rule that would catch active exploitation all change the urgency calculation. A mitigated vulnerability is not the same as a patched vulnerability, but it is different from an unmitigated one.

The goal of CVE prioritization is not to patch fewer vulnerabilities. It is to ensure the vulnerabilities most likely to be exploited in your environment are patched first, every time.

What this looks like in practice

Applied to a real environment, this filter chain typically reduces the daily CVE volume by 95% or more before it reaches the remediation team. Of 200 CVEs published today, perhaps 40 affect software your organization runs. Of those 40, perhaps 12 are on internet-facing hosts. Of those 12, perhaps 4 have active exploitation or public proof-of-concept code. Of those 4, perhaps 1 or 2 have no compensating control in place.

Those 1 or 2 are the ones your team patches this week. The rest are triaged and scheduled according to their filtered priority score, not their CVSS number.

The organizations that implement this filter chain consistently report two outcomes: fewer critical vulnerabilities reaching exploitation before patching, and patch teams that are less burned out from triage work they know will not produce useful results.

Building the capability

The filter chain requires three inputs that many organizations do not have in usable form: a maintained software asset inventory with version data, exposure context for each asset, and a threat intelligence feed calibrated to your sector and geography. Building these takes time. Maintaining them requires ongoing effort.

The alternative is continuing to triage 200 CVEs per day and patching by CVSS score. The math on which approach produces better security outcomes is not close.