Every day, security researchers publish CVE advisories. Most of them sit in databases, theoretical threats to organisations that may or may not run the affected software. But some of those CVEs are already being exploited in the wild — right now.
The CISA Known Exploited Vulnerabilities (KEV) catalog is the difference between patching everything (impossible) and patching what actually matters (urgent).
{/* TODO: refresh KEV count quarterly — last verified 1,587 as of 2026-05-04 via https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json */} As of May 2026, CISA's KEV catalog lists 1,587 confirmed exploited vulnerabilities. Each one on that list has evidence of active exploitation — adversaries are weaponising it today, not planning to tomorrow.
For incident response teams, KEV is the critical input to a single question: "If an attacker is going to hit us first, which vulnerabilities will they use?"
What the KEV Catalog Is
CISA's KEV catalog is a curated, live-updated list of CVEs where there is reliable evidence of active exploitation. Unlike the broader National Vulnerability Database (NVD), which contains 45,777 CVEs for 2025 alone (averaging 130.4 new CVEs published per day), KEV is intentionally narrow and high-confidence.
For each KEV entry, CISA publishes:
- CVE identifier (e.g., CVE-2024-3094)
- Vendor and product name
- Vulnerability description
- Evidence of active exploitation (public PoC, active in-the-wild attacks, etc.)
- Date added to the catalog
- CISA's recommended remediation deadline (BOD 22-01 sets 14 days as the standard window for newly listed CVEs — FCEB agencies must remediate internet-facing KEVs within 15 days and all other KEVs within 25 days; applies industry-wide as a prioritization signal)
Why KEV Matters During Incidents
1. Rapid Triage of CVE Alerts
When a vulnerability is announced, your team's first question should be: "Is this on the KEV catalog?"
If yes:
- Threat level: Critical — active exploitation confirmed
- Remediation window: 14 days (per CISA BOD 22-01; 15 days for FCEB internet-facing systems, 25 days for all other FCEB systems)
- Investigation requirement: Immediate
If no:
- Threat level: Context-dependent (CVSS score, your attack surface, etc.)
- Remediation window: Standard patch cycle (30–90 days)
- Investigation requirement: Lower urgency
This single check saves incident response teams from the paralysis of "we have 130 new CVEs per day, which ones matter?"
2. Incident Forensics
If an incident has already begun and your team is investigating root cause, KEV provides a shortcut:
"Did we get compromised via a known-exploited vulnerability?"
Query your SBOM and deployment history against the KEV catalog. If a running artifact contains a KEV entry, that's a strong leading hypothesis for initial access.
According to Verizon's 2025 Data Breach Investigations Report, vulnerability exploitation surged 34% year-over-year as an initial attack vector — driven largely by an ~8x rise in edge-device and VPN exploitation (3% → 22% of breaches), where only 54% of edge KEVs ever get patched and the median fix time is 32 days. Not all of those are KEV entries, but a large portion are. If you can match your incident to KEV, you've dramatically narrowed the attack surface.
3. Remediation Prioritization at Scale
Most organisations cannot patch everything immediately. The patch backlog is always real. KEV solves this by answering: "In what order should we patch?"
Answer: KEV entries first, everything else second.
Verizon's 2025 DBIR shows only 54% of vulnerable devices are fully remediated within the year. The reason isn't lack of patches or tooling — it's triage failure. When you patch by KEV first, you reduce the attacker's window into your known-vulnerable attack surface from "any of thousands of CVEs" to "the specific handful of actively exploited ones."
Integrating KEV into Incident Response Workflow
Step 1: Build SBOM → KEV Lookup
Every SBOM your organisation generates should be queryable against the KEV catalog. This is a build-time operation:
# After generating your SBOM (CycloneDX or SPDX format)
# Query against CISA KEV API
curl -s "https://www.cisa.gov/sites/default/files/json/known_exploited_vulnerabilities.json" \
| jq '.vulnerabilities[].cveID' > /tmp/kev_list.txt
# Compare your SBOM components against KEV
sbom-scan \
--sbom application.sbom.json \
--against-list /tmp/kev_list.txt \
--output json > kev_findings.jsonIf the result is empty, your deployment contains no known-exploited vulnerabilities (today). If the result has entries, those are your incident-response priorities.
Step 2: Automated KEV Alerting
Configure your monitoring stack to alert on KEV entries, weighted by your infrastructure:
# Example: OPA Gatekeeper policy for container images
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoKEVContainers
metadata:
name: block-kev-images
spec:
match:
kinds:
- apiGroups: ["apps"]
kinds: ["Deployment", "StatefulSet", "DaemonSet"]
parameters:
check_sbom: true
fail_on_kev: true
kev_severity: all # Block any KEV, regardless of CVSSWhen a new KEV entry is published that matches your infrastructure, your deployment automation should fail until remediation is verified.
Step 3: Runbook Integration
Your incident response runbooks should have a KEV check as an early triage step:
Incident triage checklist:
1. ✓ Identify affected service/artifact
2. ✓ Retrieve its SBOM
3. ✓ Query SBOM against current KEV catalog
4. ✓ If match found:
- Severity: CRITICAL
- Go to KEV Remediation Runbook
- Assume active exploitation until proven otherwise
5. ✓ If no match:
- Continue standard incident investigation
The Remediation Gap
Despite CISA's clear guidance and the availability of KEV data, remediation rates lag. Verizon reports only 54% of vulnerable devices fully remediated within the year.
The gap exists because:
- Triage inertia — Teams lack visibility into which vulnerabilities are on the KEV list, so they patch randomly
- Supply chain delays — Even KEV vulnerabilities sometimes require dependency updates that take time
- False urgency — When every CVE is treated as equally critical, nothing is treated as urgent
- Approval bottlenecks — Patches require change control, and when you're patching hundreds of CVEs per quarter, approvals become a queue
KEV data short-circuits the first and third problems. If you patch KEV entries on the BOD 22-01 14-day cadence regardless of other priorities, you eliminate the 54% of devices that sit unpatched for over a year.
Connecting KEV to SBOM and Deployment Metadata
The full incident-response capability chain:
- CVE published → Check KEV catalog
- KEV entry found → Scan all active SBOMs
- SBOM match found → Query deployment metadata
- Identify running artifacts → Correlate to production deployments
- Affected instances isolated → Targeted remediation vs. broad rollback
Without this chain, a KEV entry is just a number. With it, you have:
- Exact list of running instances affected
- Impact scope (development, staging, production)
- Urgency (14-day CISA BOD 22-01 deadline — 15/25 days for FCEB internet-facing/all-other — but likely sooner given active exploitation)
Automation for Continuous KEV Monitoring
#!/bin/bash
# Run daily to fetch fresh KEV catalog
KEV_URL="https://www.cisa.gov/sites/default/files/json/known_exploited_vulnerabilities.json"
SBOM_DIR="/path/to/sboms/"
# Download latest KEV
curl -s "$KEV_URL" -o /tmp/kev_latest.json
# Compare each SBOM against current KEV
for sbom in "$SBOM_DIR"/*.json; do
echo "Scanning $sbom..."
sbom-query-tool \
--sbom "$sbom" \
--kev-file /tmp/kev_latest.json \
--output-format slack
done | tee /tmp/kev_scan_results.txt
# Post to incident channel if findings exist
if grep -q "KEV_MATCH" /tmp/kev_scan_results.txt; then
curl -X POST $SLACK_WEBHOOK \
-d "$(cat /tmp/kev_scan_results.txt)"
fiThis runs continuously, alerting your team when:
- A running deployment contains a KEV entry
- A new KEV entry affects your software supply chain
- Remediation deadlines approach
The Business Case for KEV-First Patching
Organisations that prioritise KEV remediation over generic CVSS-score patching see:
- 60% faster incident response to vulnerability-based attacks
- 80-day faster breach detection and containment (IBM 2025: organisations with automation save 80 days vs. manual processes)
- Reduced attacker dwell time from 26 days (external detection) to 11 days (comprehensive monitoring + fast remediation)
The cost of not using KEV data is measured in months of undetected compromise and millions in breach costs.