What is the Known Exploited Vulnerabilities (KEV) Catalog

The CISA Known Exploited Vulnerabilities (KEV) list has become a critical resource for organizations aiming to rapidly close exploitable gaps. Unlike predictive scoring models, KEV is a retrospective model: it catalogs CVEs confirmed to have been leveraged in real-world attacks. By focusing on vulnerabilities with proven exploitation, security teams can drive high-confidence, prioritized patching and mitigation efforts. This post provides an in-depth look at KEV’s structure, data sources, inclusion criteria, integration strategies, and best practices for maximizing its value within a vulnerability management program.

1. What Is KEV?

• Definition: KEV is a curated catalog of vulnerabilities (CVEs) for which there is demonstrable evidence of exploitation in the wild.
• Maintainer: Cybersecurity and Infrastructure Security Agency (CISA), part of the U.S. Department of Homeland Security.
• Purpose: Enable organizations—particularly federal agencies, critical infrastructure operators, and private-sector entities—to remediate the most urgent threats. KEV serves as an authoritative list, often tied to regulatory mandates (e.g., Binding Operational Directive 23-02).

‍

2. Data Sources and Inclusion Criteria

2.1 Primary Data Sources

1. US-CERT and FBI Incident Reports: Verified reports of active exploitation submitted by CERT teams and law enforcement.
2. Private Sector CERTs and Security Vendors: Threat intelligence feeds from vendors (e.g., Microsoft Threat Intelligence Center, CrowdStrike, FireEye) documenting exploit usage.
3. Vendor Security Advisories: Official bulletins from software vendors confirming attacks in customer environments (e.g., patches or mitigations issued after active exploitation).
4. Public Exploit Repositories: Evidence of public proof-of-concept (PoC) code alone does not guarantee KEV listing, but often signals emerging exploitation.

2.2 Inclusion Workflow

1. Initial Evidence Collection: Analysts gather potential evidence from intelligence feeds, incident response teams, and vendor bulletins.
2. Analyst Verification: CISA analysts validate that a CVE has been weaponized. Verification may include:
   
   • Incident timelines (date and context of the first observed exploitation).
   • Malware or exploit code samples referencing the CVE.
   • Victim telemetry logs showing attack behavior consistent with the CVE.
3. Publication Process: After verification (typically within 28–60 days of first exploitation), CISA publishes the CVE to the KEV list along with:
   
   • Date Added: Date when the CVE entry is officially listed.
   • Exploitation Summary: Brief description of how the CVE was exploited (e.g., ransomware group using CVE-2021-34527 to gain remote code execution).
   • Patch or Mitigation References: Direct links to vendor patches, workarounds, or mitigations.

‍

3. KEV List Structure and Content

KEV entries are published in a JSON format accessible via CISA’s KEV JSON feed. Each entry includes:

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j",
  "vulnerabilityName": "Log4Shell",
  "dateAdded": "2021-12-10",
  "shortDescription": "Remote code execution via crafted message strings.",
  "requiredActions": ["Apply vendor patch ASAP"],
  "notes": "Widely exploited by multiple threat actors in December 2021"
}

‍

Key fields to note:

• cveID: Unique identifier for the vulnerability.
• vendorProject/product: Specifies affected software.
• dateAdded: When CISA added the CVE to KEV.
• shortDescription: Summary of exploitation vector.
• requiredActions: High-level guidance (e.g., patch, mitigation).
• notes: Contextual intelligence—threat actor names, campaign details, or references.

‍

4. Use Cases and Integration Strategies

4.1 Emergency Patching

• Objective: Address high-confidence, exploited vulnerabilities with the highest urgency.
• Process:
  
  1. Daily Feed Pull: Schedule an automated job to fetch the KEV JSON feed (e.g., via curl) once daily.
  2. Asset Matching: Cross-reference asset inventory (CMDB, SCCM, or vulnerability scanner outputs) with KEV CVE IDs.
  3. Ticket Generation: Automatically open high-priority patch tickets (e.g., Jira, ServiceNow) for each impacted asset.
  4. Verify and Deploy: QA patches in staging/test environments, then push to production within mandated timelines (e.g., within 60 days).

4.2 Compliance and Reporting

• Mandates: Federal agencies follow BOD 23-02, requiring patching of KEV-listed CVEs within 30–60 days.
• Documentation:
  
  • Maintain evidence of patch deployment (deployment logs, screenshots).
  • For unpatchable systems, document compensating controls (e.g., isolating servers, WAF rules).
  • Submit compliance attestations to CISA or governing bodies as required.

4.3 Risk Triage

• Prioritization: When building quarterly patch schedules, treat KEV-listed CVEs as Tier 1—address before any non-KEV CVEs, regardless of CVSS score.
• Integration with SIEM/SOAR:
  
  • Ingest KEV CVEs into security orchestration workflows.
  • Correlate SIEM alerts (e.g., IDS/IPS events) to KEV-related CVE IDs to trigger rapid investigation.

4.4 Threat Intelligence Enrichment

• Leverage the notes field to understand which threat actors are active. For example:
  
  • If a ransomware group is using a specific CVE, correlate it with internal threat feeds to gauge relevance.
  • Use IOC (Indicator of Compromise) data (e.g., IP addresses, domains) from KEV-related bulletins to enrich monitoring.

‍

5. Benefits and Limitations

5.1 Benefits

• High Confidence: Because KEV entries are confirmed exploits, teams focus on vulnerabilities that are actively weaponized.
• Regulatory Authority: Tied to BOD mandates, ensuring organizational accountability and alignment with federal requirements.
• Simplicity of Action: Binary inclusion makes decision-making straightforward—if it’s on KEV, it’s top priority.
• Operational Focus: Reduces noise by filtering out unexploited CVEs, allowing resource concentration on real threats.

5.2 Limitations

• Retrospective by Design: KEV only lists vulnerabilities after they’ve been exploited—there’s an inherent lag from first exploit to KEV inclusion.
• No Exploitation Probability: KEV does not distinguish the scale of exploitation (e.g., wide-scale ransomware vs. targeted attacks), only that exploitation occurred.
• Potential Data Lag: Analysis and verification can take 28–60 days; emerging zero-day threats may not appear until after widespread abuse.
• Limited Scope: Not all exploited CVEs are guaranteed to appear—only those vetted by CISA through validated evidence.

‍

6. Best Practices

1. Automate KEV Feed Consumption:
   
   • Schedule daily or hourly JSON pulls.
   • Validate feed integrity (checksum or record count).
2. Maintain an Accurate Asset Inventory:
   
   • Sync CMDBs, vulnerability scanner outputs (Nessus, Qualys) with asset tagging.
   • Ensure that up-to-date OS and application versions are used to map accurately to CVE IDs.
3. Implement Rapid Ticketing Workflows:
   
   • Use REST APIs (Jira, ServiceNow) to auto-create tickets for impacted hosts.
   • Assign Severity levels (e.g., P1) to KEV tickets and include remediation deadlines.
4. Facilitate Patch Testing:
   
   • Establish a rapid-test environment that mirrors production for validating KEV patches.
   • Use blue-green or canary deployment patterns where feasible to minimize production risk.
5. Document Compensating Controls:
   
   • When patching is not immediately possible (e.g., legacy systems, end-of-life software), implement network segmentation, access controls, web application firewall (WAF) rules, and intrusion prevention system (IPS) signatures.
   • Record these controls in a risk register for audit purposes.
6. Track Compliance Metrics:
   
   • Monitor key metrics: time-to-patch rate and percentage of assets remediated within 30- and 60-day windows.
   • Utilize dashboards to visualize progress and identify outliers.
7. Correlate with Threat Intelligence:
   
   • Map KEV entries to observed threat actor campaigns.
   • Prioritize KEV CVEs linked to actors targeting your sector or geography.

7. How to Access Kev

KEV is publicly accessible in multiple formats—web, CSV, and JSON—through the official CISA sources listed below:

• Web: https://us-cert.cisa.gov/kev
• CSV: https://us-cert.cisa.gov/kev.csv
• JSON: https://us-cert.cisa.gov/kev.json

Subscribe to the KEV mailing list to receive update notifications and catalog changes.

‍

8. Conclusion

The KEV list provides a proven, high-confidence approach to vulnerability prioritization, focusing on real-world exploitation. By automating feed ingestion, maintaining precise asset inventories, and enforcing rapid patching workflows, organizations can significantly reduce exposure to known attacks. While KEV’s retrospective nature means it can’t predict next-gen threats, integrating KEV with predictive models (e.g., EPSS) and broader threat intelligence ensures a balanced, proactive vulnerability management strategy.