# What Is CISA KEV? — The Known Exploited Vulnerabilities Catalog, Due Dates and KEV vs CVSS vs EPSS

Canonical: https://commareports.com/glossary/kev
Published: 2026-10-29

> CISA's KEV catalog lists CVEs with evidence of exploitation in the wild. What gets a CVE added, the BOD 22-01 due dates, the knownRansomwareCampaignUse field, how KEV differs from CVSS and EPSS, and how to check a scan against the JSON feed.

# KEV

**KEV — CISA's Known Exploited Vulnerabilities catalog — is a list of CVEs
that attackers are known to have exploited in the wild.** Where a
[CVSS](/glossary/cvss) score says how bad a flaw _could_ be, a KEV entry says
it _is already being used_. That makes it the shortest useful answer to "which
of these 400 findings do we fix today?"

## What gets a CVE into the catalog

CISA adds an entry when all three hold:

1. **It has a CVE id.** Advisories without one — a [GHSA](/glossary/ghsa)-only
   flaw, a vendor bulletin with no CVE — are not eligible.
2. **There is reliable evidence of active exploitation** — attempted or
   successful, in the wild. A published proof-of-concept or a scanner reporting
   "exploit available" is not enough.
3. **There is clear remediation guidance** — a patch, an update, a mitigation,
   or a vendor instruction to stop using the product.

Severity is not a criterion. Plenty of KEV entries score in the 6s and 7s,
and plenty of 9.8s will never appear.

## What an entry contains

Each record in the feed has the same fields:

| Field                        | Example                                                                 |
| ---------------------------- | ----------------------------------------------------------------------- |
| `cveID`                      | `CVE-2021-44228`                                                        |
| `vendorProject` / `product`  | `Apache` / `Log4j2`                                                     |
| `vulnerabilityName`          | `Apache Log4j2 Remote Code Execution Vulnerability`                     |
| `dateAdded`                  | `2021-12-10`                                                            |
| `dueDate`                    | The deadline for federal agencies                                       |
| `requiredAction`             | `Apply updates per vendor instructions.`                                |
| `knownRansomwareCampaignUse` | `Known` or `Unknown` — whether ransomware operators are known to use it |
| `cwes`, `notes`              | Weakness ids, and links to the vendor advisory                          |

`knownRansomwareCampaignUse: Known` is the strongest triage signal in the
whole record: those are the flaws that end in an encrypted file server.

## BOD 22-01 and the due dates

The catalog launched in November 2021 with **Binding Operational Directive
22-01**, which requires US federal civilian agencies to remediate every listed
CVE by its `dueDate`, a deadline set per entry — usually a few weeks after
it is added.
The directive binds no one else, but the list is public, free and
deliberately short, so security teams everywhere use it as a floor: if it is
in KEV and it is in your environment, it is overdue.

## KEV, CVSS and EPSS

Three signals, three different questions:

|          | Question it answers                             | Published by | Scale              |
| -------- | ----------------------------------------------- | ------------ | ------------------ |
| **CVSS** | How severe would exploitation be?               | FIRST (spec) | 0.0–10.0           |
| **EPSS** | How likely is exploitation in the next 30 days? | FIRST        | 0–1 probability    |
| **KEV**  | Has it been exploited already?                  | CISA         | In the list or not |

A practical order: **KEV first**, then high-EPSS findings, then CVSS severity
among what's left — and within each, only what is reachable in your
deployment. A Critical CVSS in a build-time dev dependency can wait behind a
Medium on your public login path that is in KEV.

## Checking a scan against KEV

The catalog is published as JSON and CSV. Intersect it with the CVEs in your
scanner output:

```bash
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort -u > kev.txt

# Trivy: every CVE id in the scan
jq -r '.Results[].Vulnerabilities[]?.VulnerabilityID' trivy.json | sort -u > found.txt

comm -12 kev.txt found.txt   # the ones to fix first
```

Mind the aliases: npm audit and OSV-Scanner lead with GHSA ids, so map those
through the advisory's CVE alias before comparing — an [OSV](/glossary/osv)
record lists them in `aliases`.

## Where the scan goes next

The short list still has to reach whoever owns the service. Drop the scan
JSON into the free [Trivy viewer](/tools/trivy-viewer) (Trivy and Grype), the
[npm audit viewer](/tools/npm-audit-viewer) or the
[pip-audit / OSV-Scanner viewer](/tools/pip-audit-viewer), publish the report
as a link, and comment on the KEV rows directly — "this one's in KEV, due
Friday" pinned to the finding rather than lost in a channel.

## Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision
history.

**[Open the Trivy viewer →](/tools/trivy-viewer)**

### Related

- [CVSS](/glossary/cvss) · [GHSA](/glossary/ghsa) · [OSV](/glossary/osv) · [SBOM](/glossary/sbom) · [SARIF](/glossary/sarif)
- [Trivy viewer](/tools/trivy-viewer) · [npm audit viewer](/tools/npm-audit-viewer) · [pip-audit viewer](/tools/pip-audit-viewer)
- [Share a Trivy report](/share-trivy-report) · [Share an npm audit report](/share-npm-audit-report) · [Glossary](/glossary)