Using CISA KEV to Find the Vulnerabilities That Matter First
Most vulnerabilities are never exploited in the wild. A small fraction are, and those account for a large share of real-world risk.
The hard part is knowing which ones. CISA's Known Exploited Vulnerabilities catalog is a direct, free answer to part of that question.
What KEV is
KEV is a list maintained by the U.S. Cybersecurity and Infrastructure Security Agency. A vulnerability is added when it has an assigned CVE ID, there is reliable evidence of active exploitation, and there is clear remediation guidance such as a vendor update.
Each entry includes the CVE, vendor and product, a short description, the date added, a required action, and a due date. There is also a field noting known use in ransomware campaigns.
The catalog is published as CSV and JSON, which makes it easy to pull into tooling.
U.S. federal civilian agencies are required to remediate KEV entries by the listed due dates under Binding Operational Directive 22-01. Everyone else can use it voluntarily, and many do.
Why it changes prioritization
Severity scores describe potential impact. KEV describes observed attacker behavior. That is a different, and often more actionable, kind of information.
When a finding matches a KEV entry, you know:
- Attackers have actually used it.
- A fix or mitigation exists.
- It is common enough to warrant a public catalog entry.
That combination is a strong reason to move it up the queue, even if its CVSS score is moderate.
Putting it to work
Match it automatically
Pull the KEV feed daily and join it against your scanner findings by CVE ID. Flag matches clearly in dashboards and tickets. This is a small amount of code with a large payoff.
Combine with exposure
A KEV vulnerability on an internet-facing system is the classic emergency. The same vulnerability on an isolated lab machine is still important, just less urgent. Use KEV status together with exposure and asset criticality to set timelines.
Watch for new additions
Entries are added as exploitation is confirmed, sometimes years after a CVE was published. A vulnerability you deprioritized long ago can become urgent overnight. Alert on newly added entries that match existing findings, not just new findings.
Use the ransomware flag
The ransomware campaign field is a useful extra signal for systems where availability matters most, such as file servers, hypervisors, backup systems, and remote access gateways.
Track your KEV backlog
A simple, meaningful metric: how many open findings match KEV, and how long have they been open? It is easy to explain to leadership and hard to argue with.
Limitations to keep in mind
KEV is valuable, but it isn't complete.
It lags. Exploitation often begins before an entry is added. Vendor advisories and threat intelligence may flag active exploitation first.
It requires a CVE. Vulnerabilities without CVE IDs, misconfigurations, and exposed credentials won't appear.
It is selective. Inclusion depends on reliable evidence. Absence from KEV doesn't mean a vulnerability is safe.
It doesn't know your environment. It can't tell you whether you are exposed, how critical the asset is, or whether you have compensating controls.
Pairing KEV with other signals
KEV works best as one strong input among several:
- EPSS estimates the probability of exploitation activity and covers far more CVEs than KEV, giving you a forward-looking signal.
- Vendor and threat-intelligence advisories may report exploitation earlier.
- Exposure and criticality data tell you how much a given instance matters.
- Reachability analysis helps for application dependencies.
A practical rule set might put KEV-listed, exposed findings at the top, then high-EPSS exposed findings, then everything else by criticality and severity.
The takeaway
If you do only one thing to improve prioritization this quarter, join your findings to KEV and give matches a faster remediation track. Then make sure the rest of your model is ready for the vulnerabilities KEV hasn't caught up with yet.