Security1 publisher2 min readPublished
CISA mirrors the KEV catalog on GitHub with a public commit history
The KEV catalog's CSV and JSON files now sit in a CC0 GitHub repo that CISA says stays within minutes of cisa.gov. For vulnerability teams, the git log supplies a change history the catalog page itself does not keep.
The Watch · Security desk
What happened
- CISA is publishing the data files behind the Known Exploited Vulnerabilities catalog in a GitHub repository, cisagov/kev-data, sourced from the canonical catalog at cisa.gov/kev.
- The repository updates shortly after the cisa.gov catalog, typically on weekdays during US Eastern business hours when entries change, and CISA says both sources should be synchronized within minutes.
- Alongside the CSV and JSON data, the repository hosts the current JSON schema for KEV, giving pipeline owners a published structure to validate against.
- The repository is not a route for requesting additions or deletions, which stay with CISA under criteria the README ties to the authority of BOD 26-04.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability A responder can now reconstruct what a KEV entry said last month without having archived the file, because the commit log holds the state the catalog page did not retain.
- decision Vulnerability teams have to pick which endpoint their tooling polls. CISA's own argument favours the one with an API over the government web page.
- constraint A public issue tracker sitting on the data does not make KEV membership arguable in public; that dispute still runs through CISA.
- precedent KEV joins the CVE List and Vulnrichment as federal vulnerability data with a public log. That sets the expectation that the next such feed ships diffable.
A team that wants to know when a KEV entry's text changed has needed its own saved copy of the file from before the change. The catalog, according to the repository's README, "has no inline file revision history or log that's easily accessible after the fact" [7]. In the mirror, each update lands as a commit, and CISA gives git history as the reason the repository makes tracking changes easier and more transparent [13].
The data was already machine-readable. CISA produces the catalog in two formats, CSV and JSON [2]. The README describes the GitHub copy as a mirror that users should expect to be synchronized with cisa.gov within minutes [4]. CISA's stated reason for the mirror is consumption. GitHub provides a rich API for querying and downloading data sets, and code developed and maintained on GitHub often has an easier time consuming data sources from GitHub than from US government websites [8]. A pipeline that switches is trading one endpoint for another with an API and a log.
The two kinds of file in the repository move at different speeds. The data changes whenever KEV changes, typically on weekdays in US Eastern business hours when there are new or updated entries [4]. The JSON schema, which the repository also carries [3], is expected to change perhaps a few times per year [5]. Fifty-two weeks of five business days gives 260 possible update days. A parser pinned to the published schema faces a couple of structural changes a year against contents that can move on most working days [14].
Contributions are bounded to technical defects: typos in prose, broken links to remediation guidance, accidental schema violations [9]. Anything else about a specific entry goes by email to [email protected] [11].
CISA also publishes a dashboard at cisagov.github.io/kev-data for viewing commit changes [6]. The files are CC0, identical to the license CISA applies to the KEV data on its own site [12].
What to watch
- Whether the JSON schema takes a version bump, and whether parsers pinned to the current file break when it does.
- Whether the GitHub mirror ever drifts from cisa.gov by more than the minutes CISA promises during a heavy KEV week.
- Whether public issue tracking extends from typos to the justification for individual entries, which the README currently routes to email.