What is the CISA KEV catalog?

KEV is the Known Exploited Vulnerabilities catalog maintained by the US Cybersecurity and Infrastructure Security Agency (CISA). It lists CVEs for which CISA has reliable evidence of exploitation in the wild, with the affected vendor and product, the required remediation action and a due date. It started in November 2021 alongside Binding Operational Directive 22-01.

What gets a vulnerability added to KEV?

Three criteria: the vulnerability has an assigned CVE id, there is reliable evidence it has been actively exploited (attempted or successful), and there is clear remediation guidance such as a vendor patch or mitigation. A high CVSS score is not a criterion, and a proof-of-concept alone does not count as exploitation.

Does KEV apply to private companies?

BOD 22-01 only binds US federal civilian executive branch agencies, which must remediate listed CVEs by each entry's due date. Everyone else uses the catalog voluntarily, as a short list of vulnerabilities attackers are known to use — which is why many scanners and vulnerability managers flag KEV membership.

What is the difference between KEV, CVSS and EPSS?

CVSS scores how severe a vulnerability would be if exploited. EPSS, from FIRST, estimates the probability it will be exploited in the next 30 days. KEV records that it already has been. They answer different questions, so a common triage order is KEV first, then high EPSS, then CVSS severity among the rest.

How do I check my scan results against KEV?

CISA publishes the catalog as JSON and CSV feeds. Download known_exploited_vulnerabilities.json, extract the cveID values, and intersect them with the CVE ids and aliases in your scanner output. The catalog is small — on the order of a thousand-plus entries — so the match is usually a handful of rows worth fixing first.

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 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:

It has a CVE id. Advisories without one — a GHSA-only flaw, a vendor bulletin with no CVE — are not eligible.
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.
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:

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 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 (Trivy and Grype), the npm audit viewer or the pip-audit / OSV-Scanner 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 →

CVSS · GHSA · OSV · SBOM · SARIF
Trivy viewer · npm audit viewer · pip-audit viewer
Share a Trivy report · Share an npm audit report · Glossary

KEV