TL;DR
Most vulnerability lists tell you what could go wrong. The CISA KEV Catalog tells you what is going wrong right now. Known Exploited Vulnerabilities (KEVs) are CVEs confirmed to be actively exploited in the wild. CISA maintains the official catalog and mandates remediation timelines for federal agencies through Binding Operational Directive 22-01. Most private organizations use the same list to cut through alert noise and identify what actually needs to be fixed first.
CVSS, EPSS, and KEV answer three different questions. CVSS measures theoretical severity — how bad could this be? EPSS predicts exploitation probability within 30 days — how likely is this to be targeted? KEV confirms active exploitation — is this being attacked right now? A vulnerability with a moderate CVSS score, a high EPSS score, and a KEV tag is more urgent than a critical CVSS score with no exploitation evidence. The three signals work together, not interchangeably.
A KEV in your dependency is not a theoretical risk — it has a deadline. KEVs frequently involve third-party components, frameworks, containers, and CI/CD dependencies that teams assume are safe. CVE-2023-4966 (CitrixBleed) was confirmed exploited within days of disclosure. CVE-2024-1086 was picked up by ransomware groups shortly after its KEV Catalog entry. The standard fix-window for internet-facing KEVs is 1–3 days, not the typical patch cycle.
This post covers: what KEVs are and how they differ from CVEs, CVSS, and EPSS; how to build a prioritization workflow around the CISA catalog; and how Xygeni automates KEV correlation, guardrail enforcement, and remediation across CI/CD pipelines — including a working YAML guardrail policy.
What Are Known Exploited Vulnerabilities (KEVs)?
Every vulnerability scanner produces findings ranked by CVSS severity. The problem is that CVSS measures theoretical impact, not active exploitation. The CISA Known Exploited Vulnerabilities (KEV) Catalog solves a different, more urgent problem: it lists the CVEs that attackers are exploiting right now, with patch deadlines attached. For any team trying to decide what to fix first, it is the most actionable signal available.
Known Exploited Vulnerabilities (KEVs) are CVE-listed vulnerabilities confirmed to be exploited in the wild. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains the official KEV Catalog and mandates remediation timelines through Binding Operational Directive 22-01. Many private organizations now use this list to prioritize patching.
Although CVSS scores measure potential impact, KEVs represent active exploitation. In other words, they turn “maybe exploitable” into “being exploited,” requiring faster SLAs and automated guardrails.
KEVs vs CVEs vs EPSS
Security teams often confuse these related terms. Understanding the difference is crucial for accurate risk
| Acronym | Source | Purpose |
|---|---|---|
| CVE | NVD | Unique identifier for a disclosed vulnerability. |
| CVSS | NVD / FIRST | Measures theoretical severity (impact + exploitability). |
| EPSS | FIRST.org | Predicts probability of exploitation within 30 days. |
| KEV | CISA | Confirms real-world exploitation and sets patch deadlines. |
Together, these systems form a hierarchy of risk: CVSS shows how bad it could be, EPSS shows how likely it is, and Known Exploited Vulnerabilities show what’s actually happening.
Further reading: CVSS Score: How CVSS Scoring Works and EPSS vs CVSS: What’s the Difference?
Why KEVs Matter for Developers and CISOs
Firstly, KEVs highlight live attacker behavior. Secondly, they frequently involve third-party components, frameworks, containers, or CI/CD dependencies, that teams assume are safe. Consequently, a delayed fix can open lateral-movement paths inside your build and delivery infrastructure.
Recent examples:
- CVE-2024-1086 (Linux nf_tables): added to the KEV Catalog; exploited by ransomware groups in mid-2024.
- CVE-2023-4966 (CitrixBleed): confirmed exploitation within days of disclosure; forced emergency patch cycles worldwide.
Takeaway: KEVs are not potential threats, they’re active ones. Therefore, treat every Known Exploited Vulnerabilities as “fix-now”, unless reachability analysis proves otherwise.
How to Track and Prioritize Known Exploited Vulnerabilities
To begin with, check the official CISA Known Exploited Vulnerabilities Catalog and mark any matches inside your security scanner. Then, use this information to decide which fixes need to happen first. In addition, combine Known Exploited Vulnerabilities with EPSS scores to cut noise and focus on the weaknesses that really affect your running code.
Step-by-step workflow:
- Sync data: Pull the latest updates from the CISA list every day and combine them with your other vulnerability feeds.
- Tag results: Label each finding as “Known Exploited” when the ID matches the CISA list.
- Check reachability: See whether the vulnerable code actually runs inside your app or build pipeline.
- Assess exploitability: Use EPSS to find which other issues might soon be targeted.
- Apply deadlines:
- Internet-facing vulnerabilities: fix within 1–3 days.
- Internal ones: fix within a week.
- Code not in use: keep an eye on it and verify often.
- Automate responses: The system blocks unsafe merges, opens secure pull requests, and records exceptions to make sure teams don’t miss anything.
From Awareness to Action: Automating Fixes with Xygeni
In practice, handling all this by hand doesn’t scale. Therefore, Xygeni connects Known Exploited Vulnerabilities directly to your CI/CD workflows, turning alerts into real, guided actions.
- Smart correlation: Matches detected CVEs against the CISA list and highlights “fix-now” issues inside pull requests.
- Reachability + Exploitability: Confirms if the vulnerable code path runs and links EPSS data for precise prioritization.
- Guardrails: Stops risky merges or deployments when an exploited flaw affects sensitive files or services.
- Auto-Remediation: Opens secure PRs, checks for possible breaking changes, and runs tests before merging.
- Audit logs: Keeps clear records of what was fixed and when, supporting internal security goals.
In short, threat intelligence shows what’s being attacked, Xygeni ensures it gets fixed quickly, safely, and automatically.
Example Guardrail Policy (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7d
This rule enforces no merge for active Known Exploited Vulnerabilities, notifies relevant channels, and auto-creates a fix PR, all within your CI/CD guardrails.
Mini Case: Preventing a KEV Deployment
- Week 1: A new open-source library passes SAST but includes CVE-2023-4966.
- Week 2: Xygeni’s KEV correlation detects it in the latest CISA update.
- Week 3: Guardrails halt the merge; Auto-Remediation proposes a patched version.
Outcome: The team avoided shipping a known exploited vulnerability to production and resto red pipeline flow within the same sprint.
Xygeni correlates your open CVEs against the CISA KEV Catalog automatically, flags known exploited vulnerabilities inside pull requests, enforces guardrails that block unsafe merges, and opens remediation PRs with breaking-change validation built in.
