You Have 40,000 Vulnerabilities. Here's How to Care About the Right Ones.

A vulnerability scan returns 40,000 findings. Your patching team has capacity for maybe 200 remediations a month, if conditions are favorable and nothing else is on fire. Leadership wants to know when you'll be done. The honest answer is never, but that is not the answer you give in the meeting.

This is the operational reality of vulnerability management in most organizations, and the way most programs respond to it is deeply counterproductive. They sort by CVSS score, work from the top down, and spend enormous resources patching critical-rated vulnerabilities in systems that an attacker would have no reason to target, while medium-rated findings in externally exposed, actively exploited software collect dust.

CVSS scores measure theoretical severity. They do not measure the probability that someone will use a specific vulnerability to attack your specific environment. Those are different questions with very different answers.

The CVSS Problem

CVSS was designed to communicate the inherent characteristics of a vulnerability. How complex is exploitation? Does it require authentication? What's the potential impact? These are useful inputs. They were not designed to be the single number that determines your remediation priority, and using them that way produces bad decisions at scale.

A CVSS 10 vulnerability in software you don't run is not a priority. A CVSS 6.5 vulnerability in your externally exposed VPN concentrator with a publicly available exploit and active exploitation in the wild is an emergency. CVSS gives both of them a number that tells you almost nothing about which one to fix first in your environment.

The security industry has known this for years and has largely kept sorting by CVSS anyway, because it is simple to explain and requires no additional data sources.

EPSS and the Exploitation Probability Question

The Exploit Prediction Scoring System is a model developed by FIRST that estimates the probability a given vulnerability will be exploited in the wild within the next 30 days. It ingests threat intelligence data, proof-of-concept publication activity, social media, and a range of other signals to produce a probability score per CVE, updated daily.

The distribution is striking. Roughly 97 percent of published CVEs have an EPSS score below 10 percent, meaning credible exploitation in the next 30 days is unlikely. A few percent have scores above 50 percent. A smaller fraction are above 90. Those are the ones getting used in active attacks right now.

When you overlay EPSS with CVSS, the priority list changes substantially. Some CVSS criticals have EPSS scores near zero because there's no working exploit and no attacker interest. Some CVSS mediums have EPSS scores above 80 because they're in widely-deployed software with public exploit code and confirmed exploitation.

Fixing the CVSS criticals first because the number is bigger is not a risk-based strategy. It is a comfort strategy that makes reports look good.

The CISA KEV List Is Free and Underused

The Cybersecurity and Infrastructure Security Agency maintains a Known Exploited Vulnerabilities catalog, a list of CVEs with confirmed evidence of active exploitation in the wild. It is publicly available, updated regularly, and comes with mandated remediation timelines for federal agencies.

Private sector organizations are not required to use it. Most should be treating it as a first-pass priority filter regardless. If a vulnerability is on the KEV list, it is not a theoretical risk. It is something that attackers are using against real targets today. The question of whether to prioritize it should not require an internal committee.

A practical starting point for any vulnerability management program: KEV list findings get remediated on an accelerated timeline. High EPSS, internet-facing exposure gets treated as urgent. Everything else gets risk-scored against your actual environment, your compensating controls, and whether exploitation would require an attacker to already be inside your perimeter.

What a Mature Program Actually Looks Like

Asset context changes everything. A CVSS 9 finding on an isolated development system with no external access and no sensitive data is not the same risk as the same finding on a production server handling payment data. Your vulnerability management program needs to know what your assets are, what they do, and what the business impact of their compromise would be. Without that context, every finding looks the same, which means nothing gets prioritized correctly.

Track remediation velocity, not just finding count. The number of open vulnerabilities is a lagging indicator. Mean time to remediate by severity tier, the percentage of findings remediated within SLA, the proportion of your internet-exposed attack surface that is current on critical patches: these tell you whether the program is actually moving.

And close the feedback loop with your threat intelligence function. The vulnerabilities being exploited in attacks against organizations in your sector are different from the ones being exploited in attacks against a different industry. That context should be feeding your prioritization model in near-real time, not showing up in a quarterly report.

You are not going to fix 40,000 vulnerabilities. You are going to fix the ones that matter before someone else finds them first. Build a program that knows the difference.