Roughly thirty thousand CVEs were published last year. No organization on earth patches all of them. That is not a failure of discipline. It is an arithmetic fact. The practical question is which ones matter first, and on that question, most programs still answer wrong.
Ask any patch team how they prioritize, and you will hear some variant of: "we focus on critical and high." Translated, that means CVSS 9.0 and above. On a good day, seven and above. That approach has a problem. CVSS is a severity score, not an exploitation score. It answers "how bad would this be if exploited," not "is this being exploited." Those are different questions, and the answer to the second one is what determines whether your team should be losing sleep this week.
Why CVSS alone is a weak prioritization signal
CVSS is useful. It gives you a rough sense of blast radius and a consistent vocabulary across tools. It is not, by itself, a work queue. A few reasons:
- Most CVEs with a 9+ score are never exploited at scale. The base vector assumes ideal adversary conditions that rarely hold.
- Some CVEs with moderate scores (5.5, 6.1) are weaponized within days because they sit in the right product, the right position, the right internet-exposed path.
- CVSS does not move when exploitation changes. A CVE scored two years ago does not automatically update its urgency when a proof-of-concept drops on GitHub.
Empirical studies over the last several years consistently show that the correlation between CVSS score and observed exploitation is weak. Using it as a primary filter means your team is almost certainly working on the wrong things most weeks.
What KEV is, and why it is different
The CISA Known Exploited Vulnerabilities catalog is a public list of CVEs that CISA has evidence are being actively exploited in the wild. It currently sits around 1,500 entries. Each entry includes the CVE, the product, a short description, the date it was added, and a required remediation date for U.S. federal civilian agencies.
Three properties make KEV stronger than CVSS as a prioritization signal:
- Empirical. Entries are added based on observed exploitation, not theoretical severity.
- Curated. CISA applies a consistent standard and does not add every PoC that appears on the internet.
- Actionable. Each entry comes with a clock. That clock is a federal mandate, but the signal is useful to any organization.
In practical terms: if something is on KEV, attackers are already using it on someone. Your window is small and the work is not optional.
How to actually integrate KEV into a workflow
Most teams I have seen treat KEV as a newsletter. Someone reads the weekly additions, nods, and goes back to the CVSS queue. That is not integration. Integration looks like this:
1. Subscribe to the feed
CISA publishes KEV as JSON, CSV, and an RSS feed. Pick the format that fits your pipeline. The goal is that new additions trigger an automated workflow within hours, not whenever someone remembers to check.
2. Tag CMDB assets by product
KEV entries are product-scoped. To act on them, you have to know which of your assets run which products, at which versions. If your asset inventory is a spreadsheet maintained by whoever owned the system last, KEV will bounce off you. Fixing this takes real work, and it is where most of the value in the whole program actually lives. A KEV pipeline is, in the end, a forcing function for asset hygiene.
3. Prioritize KEV-affected systems above everything else
Not "consider prioritizing." Prioritize. When a CVE hits KEV and you have matching assets, those tickets jump the queue. Other work is paused or deferred. This requires management support, which requires having explained ahead of time what KEV is and why the interrupt pattern is necessary.
4. Measure the right thing
Track two separate metrics:
- Mean time to patch, KEV items. This is the number that matters. Target: under the CISA remediation date. Stretch: under seven days.
- Mean time to patch, non-KEV items. This can run slower and that is fine. Managing it in the background is an explicit choice, not a failure.
If you only have one SLA that covers everything, your team will be evaluated on average performance across a population where urgency is wildly uneven. Split the metric. It will change behavior.
What KEV does not cover
KEV is a strong signal, not a complete one. It is worth being clear about its limits:
- Zero-days before they are listed. KEV trails public exploitation by days or weeks. For the fastest-moving threats, you will be reacting after the fact.
- Adversary tradecraft that does not target U.S. federal infrastructure. CISA's visibility is not universal. A vulnerability exploited primarily in Asia-Pacific enterprises may never make the list.
- Internal-only vulnerabilities. KEV emphasizes internet-facing and widely-deployed products. Your line-of-business custom application will never appear.
The right framing is that KEV is the top of your queue, not the whole of it. Supplement it with your vendor-specific threat intelligence, a vulnerability scanner that tracks EPSS scores, and whatever sector-specific ISAC you belong to.
Patterns worth learning from
Several high-impact vulnerabilities of the last few years followed the same pattern: public disclosure, proof of concept within days, mass exploitation within a week, KEV listing shortly after. Log4j. MOVEit. Ivanti Connect Secure. A series of file transfer and VPN appliance issues. In every case, organizations with a working KEV pipeline were patching within the week. Organizations still running CVSS-first missed their window.
There is no cleverness in this. The mechanics are straightforward. The people who do it well are simply the people who decided that exploitation evidence, not theoretical severity, determines urgency — and built the plumbing to act on that decision.
A concise summary
Treat KEV as the top priority queue. Treat everything else as background. Measure the two populations separately. Invest in the asset inventory work that makes the pipeline possible. Accept that being good at this is mostly an operations discipline problem, not a tooling problem.
That framing will not impress a vendor selling a risk-scoring product. It will, however, measurably reduce the time your environment spends exposed to the vulnerabilities that adversaries are actually using. Which is the whole point.