kev-data is CISA's official GitHub mirror of the Known Exploited Vulnerabilities catalog, giving defenders CSV, JSON, and a versioned JSON schema for patch-prioritization pipelines.

cisagov/kev-data is one of those repositories that looks almost too plain to matter until you consider how much defensive automation hangs off it. It is the official home of the data files that make up the Known Exploited Vulnerabilities (KEV) catalog, originally published at cisa.gov/kev. What CISA ships here is the same authoritative dataset in GitHub-friendly form: known_exploited_vulnerabilities.csv, known_exploited_vulnerabilities.json, and the current known_exploited_vulnerabilities_schema.json that defines the record structure. For anyone building vulnerability management tooling, this is the canonical machine-readable tap into what the US government considers actively exploited in the wild.

The first thing to understand is the deliberate format redundancy. The CSV flavor suits quick spreadsheet triage and legacy SIEM ingest, while the JSON flavor is what most code will want — one array of vulnerability records, each carrying the fields defined by the co-located JSON schema. Because the schema file lives in the same repo, integrators can validate their parsers against the exact contract CISA publishes, rather than reverse-engineering structure from samples. The README notes the schema changes only a few times per year, which is a strong signal that your parsing code will not churn constantly. Treat schema updates as low-frequency, high-signal events worth an alert in your pipeline.

The update cadence is the operationally interesting part. The repo is synchronized with the canonical cisa.gov source shortly after CISA posts new or updated KEV entries, which typically happens on weekdays during US Eastern business hours. The README commits to both sources being aligned within minutes of each other. That matters if you are polling: there is no point hammering the repo at one-second intervals when the upstream publisher works business hours. A sensible consumption pattern is a periodic fetch of the JSON file — either raw from the branch, or via the GitHub API the README explicitly points to — on an hourly or faster schedule if your threat model demands freshness.

Why mirror to GitHub at all when cisa.gov already serves the files? The README is candid about the rationale: code that is developed and hosted on GitHub, and the broader ecosystem around it, has a much easier time consuming data sources from GitHub than from US government websites. That is not a trivial concern. Government portals can be slow, geo-inconsistent, or awkward to script against, whereas the GitHub raw-content and API endpoints are well-understood, cacheable, and authenticated uniformly. If your remediation platform already lives in this ecosystem, kev-data removes an entire class of integration friction.

The second major value proposition is version history. The KEV on cisa.gov has, as the README puts it, no inline file revision history or log that is easily accessible after the fact. Once an entry is added or modified, you cannot conveniently ask the website what changed and when. The git commit history of this repo fixes that: every catalog update becomes a diff you can inspect, correlate with advisories, and feed into change-detection logic. There is even an interactive dashboard at cisagov.github.io/kev-data to visualize commit changes, which is genuinely useful for analysts who want to see the cadence and scope of KEV growth without touching git directly.

This versioned-log pattern is part of a broader CISA strategy the README makes explicit by reference. Sibling projects like CVEProject/cvelistV5 and cisagov/vulnrichment — the repo that enriches CVE records with CNA-consistent data — all benefit from public logging and public issue tracking. If you are assembling a vulnerability intelligence stack, kev-data slots in as the exploitation-evidence layer on top of the raw CVE list, letting you triage which of the thousands of annual CVEs actually have observed in-the-wild abuse. That distinction between theoretical and demonstrated exploitability is the entire premise of the catalog, and it is why KEV lookups have become a default enrichment step in mature vuln-management pipelines.

It is worth being precise about what this repository is not. The README states bluntly that this is not a repo for requesting additions or deletions of KEV entries. Catalog curation is handled by CISA directly under the authority of BOD 26-04, and the bar for inclusion is strict — entries require credible evidence of active exploitation. Substantive tips about individual entries go to [email protected], not to the issue tracker. Contributions here are scoped to purely technical hygiene: typos in prose, broken links to remediation guidance, accidental schema violations. Knowing this boundary saves you from filing a pull request that will be closed on sight, and it also tells you the data itself is authoritative and not community-edited.

Licensing removes the last barrier to adoption. The dataset ships under CC0, universal public domain dedication, identical to the license CISA publishes at its own site. You can fold kev-data into commercial products, internal tooling, or redistributed feeds without attribution obligations or legal review. For vendors building scanner enrichment or managed-service dashboards, that is the difference between a procurement conversation and a non-starter, and it is unusual enough among government-adjacent data products to deserve emphasis.

In an authorized workflow, the obvious integration is vulnerability prioritization: intersect your asset inventory and scanner output against the KEV JSON on a schedule, and elevate anything matching a CVE ID in the catalog to the top of the remediation queue, respecting the due dates CISA assigns to federal agencies as a reasonable private-sector benchmark. The commit history adds a retrospective dimension — you can reconstruct when an entry appeared and correlate that with your own patch latency metrics, turning the feed into a KPI source as well as a work queue. Incident responders get a parallel benefit: when a new KEV entry drops, the diff tells them exactly which newly enumerated vulnerability just crossed into actively-exploited territory.

Defenders should also note the observability angle in the other direction. Because updates are published as commits, watching the repo — via GitHub notifications or a scheduled git pull — gives you a free, low-latency alerting channel on new exploitation events, often faster than waiting for vendor bulletins to propagate. A small script that diffs known_exploited_vulnerabilities.json between fetches and posts the new entries to your team channel is a few dozen lines and is entirely within the educational, defensive spirit of the dataset. kev-data is infrastructure-grade open data, and the teams that instrument it well get measurably faster at the one task that consistently outperances exotic detection: patching what is actually being exploited.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• garble for stripping source-revealing metadata out of Go binaries


• Inside kernel-research: how Googles kernelXDK assembles a full Linux kernel exploitation workbench


• Inside msynth: how lookup tables and program synthesis tame MBA obfuscation