The CISA Known Exploited Vulnerabilities (KEV) Catalog is a living database maintained by the US Cybersecurity and Infrastructure Security Agency that lists CVEs for which CISA has obtained reliable evidence of active exploitation in the wild. It was established under Binding Operational Directive 22-01 (BOD 22-01), issued in November 2021, which requires all US Federal Civilian Executive Branch (FCEB) agencies to remediate KEV-listed vulnerabilities within prescribed timeframes — typically 2 weeks for critical vulnerabilities and up to 6 months for older ones. A vulnerability must meet three criteria to be added: it must have a CVE ID, there must be reliable evidence of exploitation in the wild (not just a proof-of-concept or theoretical risk), and there must be clear remediation guidance available. CISA accepts nominations from the public and adds vulnerabilities continuously; the catalog is available in CSV and JSON formats at a stable URL, making it machine-consumable for integration into vulnerability management platforms and asset inventory tools.
The KEV’s operational significance is what distinguishes it from other vulnerability scoring and tracking mechanisms. The CVSS base score measures a vulnerability’s theoretical severity — how bad exploitation could be in the worst case — but says nothing about whether exploitation is actually occurring. The overwhelming majority of published CVEs are never exploited at scale in the wild; concentrating patching resources on high-CVSS scores that attackers ignore while KEV vulnerabilities with moderate scores go unpatched is a well-documented failure mode of traditional vulnerability management programmes. The KEV inverts this logic: it answers the question “what are attackers actually using right now?” rather than “what could theoretically be the most damaging?” Research by CISA and independent analysts consistently shows that KEV vulnerabilities have a dramatically higher probability of being used in a breach than a randomly selected high-CVSS vulnerability. A vulnerability with a CVSS score of 6.5 that is in the KEV catalog represents a higher operational risk than a CVSS 9.8 that is not, because the 6.5 is being actively weaponised. Ransomware groups and nation-state actors frequently exploit KEV-listed vulnerabilities — many KEV entries carry annotations identifying the specific threat actor groups or ransomware families known to use them.
KEV should be the floor of any vulnerability management programme, not the ceiling. The intended use is: continuously monitor the KEV feed (via the JSON API or a SIEM integration), correlate it against your asset inventory and SBOM data to identify affected systems, and remediate within the BOD 22-01 timeframes regardless of the CVSS score. For organisations outside the US federal government, BOD 22-01 is not legally binding, but CISA explicitly recommends all organisations treat KEV as a mandatory remediation priority — and major compliance frameworks including PCI DSS, NIST SP 800-53, and ISO 27001 vulnerability management controls are increasingly interpreted to require KEV-aligned prioritisation. The KEV feeds naturally into VEX workflows: if a component in your SBOM has a KEV-listed CVE and your VEX document does not contain a not_affected assertion with a valid justification, that vulnerability must be treated as actively exploitable in your product. In the container and Kubernetes context, SBOM-aware scanners (Grype, Trivy, Snyk) and admission controllers (Kyverno with image scanning policies) can be configured to block deployment of images containing KEV-listed vulnerabilities without a corresponding VEX not_affected assertion, providing a continuous KEV-aware gate in the CI/CD pipeline.