Improving CISA KEV data integrity

tl;dr - Sometimes CISA removes Known Exploited Vulnerabilities catalog records. It would be awesome if they marked them as withdrawn and/or superseded instead.

Background

The Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog has fast become an integral source of vulnerability data consumed by organizations, products, researchers, and notably entities subject to CISA’s mandate to reduce the risk of known exploited vulnerabilities. Widespread adoption of KEV is a key component of the program’s charter:

The KEV catalog sends a clear message to all organizations to prioritize remediation efforts on the subset of vulnerabilities that are causing immediate harm based on adversary activity. Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework . . . Organizations should also consider using automated vulnerability and patch management tools that automatically incorporate and flag or prioritize KEV vulnerabilities.

As the CISA KEV catalog grows in terms of both data and adoption, it’s important that the schema and data support core use cases, including basic analytics and automation.

CISA KEV criteria and data structure

To be included in the catalog, a vulnerability must have a CVE ID assigned, be under active exploitation, and CISA must be able to provide remediation guidance (more on these requirements here).

Once admitted into the catalog, an entry is added based on the published schema. At the time of writing, the KEV vulnerability data structure contains the following keys:

vendorProject 
product 
vulnerabilityName 
dateAdded 
shortDescription 
requiredAction 
dueDate 
knownRansomwareCampaignUse * 
notes * 

* Not required

So, the KEV catalog is a structured data set that is the product of cyber threat intelligence collection and analysis. Structured data ensures predictable outputs, and is meant to enable ingestion into other systems, ranging from spreadsheets to vulnerability management products and frameworks. But “intelligence collection and analysis” implies that, as new information becomes available, the data set may be subject to substantive updates.

Where things break down

As CISA’s understanding of a given vulnerability changes, it may no longer make sense for the vulnerability to remain in the KEV catalog. When that happens, CISA typically does two things:

1. The vulnerability is removed from the catalog.
2. Another related vulnerability may be added or, if a related vulnerability is present, its shortDescription field is updated with a note that looks like this:

A consequence of this is that, when the catalog is exported via JSON or CSV, we cannot assume that data prior to the time of export is still valid. So, some amount of reconciliation needs to take place. Here’s how the above change looks when exporting the catalog via CSV:

The most recent entries as of 2023-10-20:

The most recent entries as of 2023-10-30:

Note that the initial entry for CVE-2021-1435 on row 1023 is no longer present on 2023-10-30, and a new entry for CVE-2023-20273 appears on that row instead (that both entries on row 1023 are related is coincidental).

This happens from time to time, and as you can see in the more detailed screenshot above, CISA does make an effort to reference related vulnerabilities in the shortDescription field. However, these notations are part of unstructured text, and make it challenging to consume and reconcile the KEV catalog on an ongoing or automated basis without error-prone parsing of these description fields (which we cannot assume will always reference related vulnerabilities in a predictable manner, or at all).

Proposal: dateWithdrawn and supersededBy

Once a vulnerability is added to the KEV catalog, it is never removed but can be marked as “withdrawn”.

dateWithdrawn - The date the vulnerability was withdrawn as a catalog entry, in the format YYYY-MM-DD

If a vulnerability is superseded by another (e.g., as CVE-2021-1435 was superseded by CVE-2023-20273), that relationship is made explicit:

supersededBy - The CVE ID that supersedes this vulnerability

Thank you, CISA!

I’ve written and said many times how valuable a service the KEV catalog is to both the public sector and to private industry. The above is not a complaint—far from it.

Making the above changes (or something like them) would improve the integrity of the catalog, ensure that vulnerability records within the catalog are preserved, and that consumers of the catalog (human or computer) aren’t burdened with any ambiguity or reconciliation tasks.