CISA's Known Exploited Vulnerabilities (KEV) catalog, launched in November 2021, had been operational for over a year by early 2023. What started as a binding operational directive for federal agencies had become one of the most influential vulnerability prioritization tools in the industry. By April 2023, the catalog contained over 900 entries, each representing a vulnerability confirmed to be actively exploited in the wild.
The KEV catalog changed the patching conversation from "what's the CVSS score?" to "is it actually being exploited?" That shift matters more than most people realize.
What the KEV Catalog Is (and Isn't)
The KEV catalog is a curated list of vulnerabilities that meet three criteria:
- Has an assigned CVE
- Has reliable evidence of active exploitation in the wild
- Has a clear remediation action (patch or mitigation available)
Under Binding Operational Directive 22-01, federal civilian agencies are required to remediate KEV vulnerabilities within timelines specified by CISA (typically 2-3 weeks for new additions). While this directive only applies to federal agencies, many private organizations have adopted KEV as a primary prioritization input.
What the KEV catalog is not:
- A complete list of all exploited vulnerabilities (many exploited vulns don't make it into KEV)
- A real-time feed (there's a delay between exploitation and KEV listing)
- A replacement for vulnerability management (you still need to patch non-KEV CVEs)
The Numbers After One Year
Analyzing the KEV catalog entries through early 2023 revealed several patterns:
Vendor Distribution
Microsoft products dominated the catalog, which is unsurprising given Windows' market share:
- Microsoft: ~35% of all KEV entries
- Apple: ~12%
- Google (Chrome/Android): ~10%
- Cisco: ~5%
- Adobe: ~4%
- The remaining ~34% spread across dozens of vendors
Vulnerability Types
The most common vulnerability types in KEV:
- Remote Code Execution: 40%+ of entries
- Privilege Escalation: ~20%
- Information Disclosure: ~10%
- Authentication Bypass: ~10%
- Other: ~20%
RCE vulnerabilities dominate because they provide the highest value to attackers — full system access without requiring prior access.
Age of Vulnerabilities
This is where it gets interesting. Not all KEV entries are new vulnerabilities:
- ~60% were added within one year of their CVE publication
- ~25% were 1-5 years old when added
- ~15% were over 5 years old when added
The presence of years-old vulnerabilities in the KEV catalog demonstrates that organizations aren't patching old CVEs, and attackers know it. Why develop new exploits when perfectly good unpatched vulnerabilities exist?
CVSS Score Distribution
- ~70% of KEV entries have CVSS scores of 7.0 or higher
- ~30% have CVSS scores below 7.0
- Some KEV entries have CVSS scores as low as 4.0-5.0
This is the key insight: CVSS score alone is a poor predictor of real-world exploitation. A "medium" severity vulnerability that's being actively exploited is a more urgent problem than a "critical" vulnerability that has no known exploit.
How KEV Changed Vulnerability Prioritization
Before KEV
Organizations typically prioritized patching based on:
- CVSS score (critical first)
- Asset exposure (internet-facing first)
- Vendor recommendations
- Security team judgment
This approach led to patching fatigue. With thousands of "critical" CVEs published each year, teams couldn't keep up and had to make judgment calls about which ones were actually dangerous.
After KEV
Many organizations now use a tiered approach:
- KEV entries: Patch immediately (exploited in the wild)
- Critical CVSS with exploit code available: Patch within days
- Critical CVSS without known exploits: Patch within weeks
- Everything else: Patch on regular cycle
KEV provides a signal-to-noise filter that dramatically reduces the "everything is urgent" problem.
KEV and Supply Chain Security
The KEV catalog has direct implications for supply chain security:
Third-Party Software Risk
Many KEV entries are in third-party software — libraries, frameworks, and products that organizations incorporate into their own supply chains. When a dependency has a KEV-listed vulnerability, it should be treated as a supply chain emergency.
Vendor Accountability
The KEV catalog creates public accountability for vendors. Having a product appear in KEV means attackers are actively targeting your customers. Vendors whose products appear frequently in KEV face reputational pressure to improve their security.
Patch Velocity Metric
KEV entries come with deadlines. Tracking how quickly your organization remediates KEV vulnerabilities is a meaningful metric for supply chain security maturity.
Limitations and Criticisms
Coverage Gaps
The KEV catalog underrepresents:
- Open-source vulnerabilities (CVEs in npm packages, Python libraries, etc.)
- Cloud-specific vulnerabilities
- Vulnerabilities exploited by less-visible threat actors
- Supply chain attack vectors that don't have traditional CVEs
Inclusion Criteria
The requirement for a "clear remediation action" means that vulnerabilities where the only mitigation is "stop using the product" may not be included, even if they're being actively exploited.
Timing
There's inevitably a delay between when exploitation begins and when CISA adds a vulnerability to KEV. During that gap, organizations without their own threat intelligence are unaware of the active exploitation.
Using KEV Effectively
Automate KEV Monitoring
Don't check the KEV catalog manually. Use automated tools that compare your software inventory against KEV entries and alert you immediately when a match is found.
Include KEV in SLA Requirements
Establish internal SLAs for KEV remediation. Many organizations adopt CISA's federal timelines (typically 2-3 weeks) even though they're not mandated to.
Track KEV Across Your Supply Chain
Don't just check your own software. Check your vendors' products, your open-source dependencies, and your infrastructure components against KEV.
Use KEV as a Board-Level Metric
The number of unpatched KEV vulnerabilities in your environment is a clear, defensible metric for communicating cyber risk to executives and board members.
How Safeguard.sh Helps
Safeguard.sh integrates CISA KEV data into your supply chain security workflow:
- Automated KEV Matching: Safeguard.sh automatically compares your SBOM components against the KEV catalog, alerting you immediately when any component has a KEV-listed vulnerability.
- Prioritized Remediation: Safeguard.sh uses KEV status as a primary signal for vulnerability prioritization, ensuring actively exploited vulnerabilities get immediate attention.
- Supply Chain KEV Tracking: Safeguard.sh tracks KEV vulnerabilities not just in your direct dependencies, but across your entire supply chain, including transitive dependencies.
- Compliance Reporting: Safeguard.sh generates reports showing your KEV remediation status and timelines, supporting compliance with internal SLAs and regulatory requirements.
The KEV catalog transformed vulnerability management from a score-based exercise to an intelligence-based practice. Integrating KEV data into your supply chain security tooling is one of the highest-impact improvements you can make.