CISA’s Known Exploited Vulnerabilities (KEV) Catalog
summary
KEV is a curated list that requires CVE ID, requires reliable evidence of exploitation (execution of malicious code without owner consent), and requires clear remediations before entry; entries trigger BOD‑22‑01 federal remediation deadlines, so adding a CVE often creates million‑dollar obligations. Evidence comes from vendors, telemetry (e.g., Microsoft/Azure), researchers and high‑quality honeypots, not public POCs, scans or pen tests. KEV is manually reviewed, added within days for urgent cases, and is rarely removed when new evidence contradicts earlier claims.
AI-written summary · about
chapters (15)
- 0:00CISA’s KEV Catalog intro
- 1:06History and purpose
- 3:39BOD 22-01 role
- 6:35KEV entry criteria
- 10:48CVE ID requirement
- 17:06Active exploitation criteria
- 27:02Exploitation evidence sources
- 35:16Evidence transparency
- 40:36Physical and network vulns
- 42:23Target agnosticism scope
- 46:18Removing vulnerabilities
- 48:49Attribution evidence-based
- 51:38Mitigations and KEV
- 55:37What KEV excludes
- 56:18Future enhancements
related talks
30mIdentifying Exploited and Likely-to-Be-Exploited Vulnerabilities
50mThe Weaponization Gap: What 20 Million KEV Detections Reveal About Edge Remediation
48mCISA-ENISA Joint Messaging
27mExploited CVEs of 2024: Lessons for Vendors and Defenders
41mNIST’s National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem
15mKeynote
56mOutpacing Attackers: How Data-Driven Insights Speed Up Vulnerability Remediation
32mUnderstanding Exploitability with VEX, EPSS, and Other Standard Frameworks