BIPI
BIPI

Operationalizing the CISA KEV Catalog: From Feed to Patched in 14 Days

Cybersecurity

The CISA Known Exploited Vulnerabilities catalog cut through the CVE noise with a single principle: only list vulns that are actually being exploited. Mapping it to your asset inventory and hitting the 14-day SLA is the part nobody publishes a runbook for.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 22, 2024 · 7 min read

#cisa-kev#vulnerability-management#patching

Vulnerability management programs have been buried under CVE volume since at least 2018. NVD ingests roughly 25,000 new CVEs a year. CVSS scores them. Most are noise for any given organization. The CISA KEV catalog cuts through that noise by listing only vulnerabilities that have observed in-the-wild exploitation.

As of early 2026 the catalog holds around 1,200 entries, growing by 12 to 18 per week. That is a tractable list. The 14-day patch SLA is a real operational target. Most clients we audit are not hitting it, and the gap is rarely about technical capability.

Why KEV beats CVSS for prioritization

A CVSS 9.8 with no exploitation in the wild and a CVSS 6.5 with active ransomware deployment are not the same risk. CVSS measures hypothetical impact under ideal conditions. KEV lists what attackers are actually doing right now. For prioritization, the second signal beats the first.

We rebuilt one client's vuln management program around KEV-first triage in 2024. Their critical-priority queue shrank from 4,000 items to about 300. Their mean-time-to-patch on the smaller queue dropped from 47 days to 11. Same team, same tooling, different prioritization input.

Ingesting the feed

CISA publishes the catalog as JSON at a stable URL. Update frequency is daily on weekdays. Schema is simple: CVE ID, vendor, product, vulnerability name, date added, due date, action required, known ransomware use.

  • Pull the JSON daily into your vuln management platform via scheduled job.
  • Diff against yesterday's pull. New entries get auto-priority-bump.
  • Map by CPE or vendor/product strings against your asset inventory.
  • Store the due date as a hard SLA field on the resulting tickets.

The mapping problem

KEV entries identify products by vendor and product name, sometimes with versions, sometimes without. Your asset inventory identifies them by package name, image hash, hostname, instance ID. Closing that gap is the part nobody talks about.

We use a layered match: CPE if available, fuzzy vendor-product match if not, manual review for ambiguous cases. A typical mid-size org has 40,000 assets and roughly 8 percent of them carry KEV-relevant software. That is 3,200 assets to map, refreshed weekly. Without automation, this is a half-FTE problem.

1,200
active KEV entries as of Q1 2026
14 days
default patch SLA per CISA BOD 22-01
11 days
MTTR achievable with KEV-first triage

The 14-day reality

BOD 22-01 mandates federal civilian agencies hit the deadline. Private sector has no legal requirement but most mature programs adopt it as their internal SLA. Hitting it requires three things working together.

First, change windows have to support emergency patches. If your standard process is monthly patch Tuesday, the KEV process is parallel and faster. Second, the patch itself has to be available at scope. For Microsoft and major Linux vendors this is reliable. For long-tail commercial software, vendor patch availability is the main delay we observe. Third, the rollback story has to be tested. A bad emergency patch that takes the trading floor down at 9:31am is worse than the vuln.

What KEV does not tell you

KEV is a confirmed-exploitation list. It is not a pre-exploitation prediction. Vulnerabilities sitting at zero in-the-wild evidence today can land on KEV next Tuesday. EPSS (Exploit Prediction Scoring System) is a useful complement here, scoring the likelihood of exploitation in the next 30 days. Combined view: KEV plus high-EPSS plus your own asset criticality is the right triage signal.

If your vuln management program is drowning in CVSS 9s, restructuring around KEV is the highest-leverage change you can make. It does not require new tooling, just a change to how you prioritize the inputs you already ingest. The ROI shows up in the second quarter after deployment, when your team is no longer triaging the same false alarms for the fifth time.

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