BIPI
BIPI

CVSS Is Lying to Your Vulnerability Management Program

Threat Intelligence

There are over 220,000 CVEs published. Roughly 1,300 are in CISA's Known Exploited Vulnerabilities catalog. Prioritizing by CVSS alone means treating those two populations as equally urgent.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 17, 2024 · 7 min read

#cve#kev#vulnerability-management

A healthcare client's vulnerability program was generating 47,000 "critical or high" findings per month across their estate. The team had no realistic path to remediating that volume, so they remediated what was easy and let the rest age. When we audited the actually-exploited findings versus what they had patched in the prior quarter, the overlap was 12 percent. They were doing a tremendous amount of work and missing most of what mattered.

The arithmetic of vulnerability management has changed enough that scoring everything by CVSS and working top-down is no longer a defensible strategy. The CVE corpus has crossed 220,000 published vulnerabilities. CVSS scores cluster heavily in the 7.0 to 9.8 range because the scoring system is generous with high marks. The result is that "critical" loses meaning when 30 percent of your environment has at least one critical-by-CVSS finding at any given time.

220K+
Total CVEs published
~1,300
Vulnerabilities in CISA KEV catalog
~6%
of CVEs ever observed exploited in the wild
12%
Typical overlap between patched-this-quarter and actually-exploited at unaudited orgs

What KEV actually represents

CISA's Known Exploited Vulnerabilities catalog is the subset of CVEs for which CISA has reliable evidence of exploitation in the wild. Currently around 1,300 entries, growing by roughly 20 to 40 per month. The bar for inclusion is high: not just "PoC exists," but "used in observed attacks." That makes KEV one of the highest-signal vulnerability prioritization inputs available, and it is free.

The limitation is that KEV is not exhaustive. Plenty of vulnerabilities are exploited by APT groups or sophisticated criminal operators without ever showing up in KEV, especially recent zero-days and vulnerabilities exploited in narrowly targeted campaigns. KEV is a high-precision, moderate-recall signal.

EPSS as the second axis

FIRST.org's Exploit Prediction Scoring System (EPSS) gives every CVE a probability score (0 to 1) of being exploited in the next 30 days, based on a model trained on observed exploitation data. EPSS is noisy at the individual CVE level but useful as a population filter. A CVSS 9.8 with EPSS 0.001 is dramatically less urgent than a CVSS 7.5 with EPSS 0.85.

  • EPSS above 0.5: meaningfully likely to be exploited soon, prioritize even at CVSS 6 or 7.
  • EPSS 0.1 to 0.5: worth tracking, patch in normal cycle if asset is exposed.
  • EPSS below 0.1: deprioritize unless it is on KEV or in your specific threat model.
  • EPSS scores below 0.01 represent the bulk of CVEs and are largely defer-and-monitor candidates.

The third axis: asset exposure

KEV plus EPSS still gives you thousands of findings. The third filter is exposure context: which of these vulnerable assets is internet-facing, which is in a flat network with privileged users, which is on an isolated OT segment with no inbound paths. A KEV finding on an internet-facing Citrix appliance is a different problem than the same finding on a developer laptop that VPNs in occasionally.

The clients we work with who have functional vulnerability programs all converge on similar prioritization logic: score = function(KEV membership, EPSS, asset exposure tier, business criticality). The exact weighting varies, but the structure is consistent. CVSS appears in the mix as one input, not the primary key.

The political problem

The hardest part of moving from CVSS-only to KEV+EPSS+exposure is internal. Auditors, regulators, and executives are used to the language of "critical findings." Telling them you are deprioritizing a CVSS 9.8 because EPSS is 0.002 sounds, on its face, like cutting corners. It is not. It is acknowledging that you cannot patch everything and choosing to patch what attackers actually exploit.

Get this in writing with executive sponsorship before you change the program. Document the methodology, show the math on remediation capacity versus exploit-likelihood, and tie it to incident outcomes (yours or peers'). Most regulators we have engaged with on this are receptive when the methodology is sound. The ones that are not, you work around with a parallel reporting metric while running the actually-effective program underneath.

Stop ranking by CVSS. Start ranking by what gets exploited.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.