Every vulnerability management program eventually rediscovers the same uncomfortable arithmetic: the number of CVEs rated "critical" by CVSS exceeds the organization's annual patch capacity by an order of magnitude. A score designed to describe severity gets used, out of necessity, to decide priority, a job it was never built for.
The answer is a small stack of orthogonal signals rather than a better single score. EPSS estimates the probability of exploitation in the wild. CISA KEV confirms exploitation has already happened. Exploit maturity (no public code, proof-of-concept, weaponized) describes how cheap the attack is to mount. Ransomware linkage tells you whether the people exploiting it monetize at scale.
Run those four filters against a typical quarter of CVE publications and the "critical" pile collapses from thousands to dozens. More usefully, the survivors come with evidence you can attach to a change ticket, which is the difference between a patch request that waits for the next maintenance window and one that gets an emergency slot.
THE QUEUE, FILTERED
sample quarterCVEs published, one quarter
11,000
the feed
CVSS ≥ 9.0 · "critical"
4,200 38%
severity alone, still unpatchable at this size
+ EPSS ≥ 10%
610 6%
likely to be exploited within 30 days
+ KEV or weaponized exploit
140 1%
already burning somewhere
+ matches a product you run (CPE/PURL)
38 0.3%
your estate, not the world's
11,000 → 38 · A QUEUE A QUARTER CAN ABSORB
The fifth filter is the one only you can apply: whether the CVE touches something you actually run. Every record carries its CPE match set with version ranges and, where the ecosystem supports it, package matches for npm, PyPI, Maven and the rest. Intersecting that against your own inventory is what turns a defensible shortlist into this week's work order, and the vendor advisory already attached to the record names the version that closes it.