The CISA Vulnrichment project is the public repository of CISA's enrichment of public CVE records through CISA's ADP (Authorized Data Publisher) container. In this phase of the project, CISA is assessing new and recent CVEs and adding key SSVC decision points. Once scored, some higher-risk CVEs will also receive enrichment of CWE and/or CVSS data points, where possible.
Producers and consumers of this CVE data should already be familiar with the current CVE Record Format and can access this data in the normal ways, including the GitHub API and the CVE Services API. Note that the results of Vulnrichment are being pushed back to the CVE corpus, through the recently (2024) launched ADP Program. Downstream consumers need not fork and track this GitHub repo if they are already consuming live CVE data.
This project is under active development, so keep an eye on this README.md for updates.
First, CISA will take each CVE through an SSVC scoring process.
Next, for those CVEs that are rated as "Total Technical Impact," "Automatable," or have "Exploitation" values of "Proof of Concept" or "Active Exploitation," further analysis will be conducted. CISA will determine if there is enough information to assert a specific CWE identifier and/or a CVSS score. In some cases, CISA will provide these metrics even to vulnerabilities that do not rate as high risk on any of these decision points.
For those CVEs that do not already have these fields populated by the originating CNA, CISA will populate the associated ADP container with those values when there is enough supporting evidence to do so. At no point will CISA overwrite the originating CNA's data in the original CNA container in the CVE record.
This flowchart (dot source) illustrates the Vulnrichment process. Please note that the details in the flowchart are subject to change as Vulnrichment processes are refined.
Let's take a moment to look at some CVE records for each kind of vulnrichment you can expect from the CISA ADP.
All of the CVEs taken as examples below were chosen at random among those that fit the demonstrated criteria.
Every CVE analyzed by the CISA ADP will have three SSVC decision points listed. For these examples, we'll take a look at CVE-2024-34974, CVE-2024-25522, and CVE-2024-35057. We'll also look at CVE-2024-33666, which is a low-risk SSVC score.
CVE-2024-25522 has a "poc" value for Exploit on line 47 indicating there was a public proof-of-concept available at the time of analysis:
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
]CVE-2024-34974 has a "yes" value for "Automatable" on line 50 indicating that an attacker could generally exploit this vulnerability at will, without having to worry about recon, weaponization, delivery, or exploitation prevention techniques.
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
]CVE-2024-35057 has a "total" value for "Technical Impact" on line 59 indicating that the exploiting this vulnerability generally will give the attacker total control over the impacted software.
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
]For those CVEs that are on the KEV, the CISA ADP will add a KEV block. For those that aren't, no update will occur.
CVE-2024-4947 is one such CVE, and contains the KEV block starting at line 88:
"other": {
"type": "kev",
"content": {
"dateAdded": "2024-05-20",
"reference": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2024-4947"
}
}CVE-2024-3477 is an example CVE which the originating CNA did not provide a CWE, and a CISA analyst was able to determine one from the context of the vulnerability information available. That metric starts on line 49 under the problemTypes node:
"problemTypes": [
{
"descriptions": [
{
"lang": "en",
"type": "CWE",
"cweId": "CWE-352",
"description": "CWE-352 Cross-Site Request Forgery (CSRF)"
}
]
}
]CVE-2024-0043 is an example CVE that had a CVSS calculation added by CISA, starting on line 30. Again, this is based on the context of the vulnerability information available at the time of analysis.
"cvssV3_1": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.8,
"attackVector": "LOCAL",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "REQUIRED",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "NONE",
"confidentialityImpact": "HIGH"
}Please note that as of December 10, 2024, CISA will no longer be adding CPE strings to the enriched dataset. Previously enriched data may still contain CPE information. The notes here regarding CPE strings are for historical purposes.
CVE-2024-1347 is an example CVE that had a CPE string added by CISA, starting on line 61.
"cpes": [
"cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:*"
]We have more to say about CPE strings below.
CVE-2024-2905 is an example CVE that already had CWE, CVSS, and CPE metrics (see here) when CISA performed the SSVC triage step, and it's not on the KEV, so nothing more needed to be added. Good job, Red Hat CNA!
Of all the enriched data types, consistent and universal software identification, currently in the form of CPE, is the most difficult to accurately generate and maintain. CISA will assess and improve CPE enrichment as this project progresses. There are three sets of CPE data, all of which conform to the CPE Specification:
- The official NVD CPE Dictionary
- CPE entries that are present in NVD data but not in the Dictionary
- CPE entries created by CISA
Due to the current design of the CVE Record Format, adding CPE strings (to the cpes list) effectively requires us to also create affected and versions arrays. This increases the possibility of disagreement between sources of vulnerability status and software identity information, including:
- the CVE description (CNA)
affecteddata (CNA)cpesdata (ADP)affecteddata (ADP)- external references, like an advisory from the CNA
- external references from a party other than the CNA
We'll do what we can to fix or improve data in our control, please open an issue if you notice trouble with ADP-provided data.
Since the CISA ADP is committed to encouraging CNAs to Do The Right Thing and provide their own CWE, CVSS, and CPE data, if a CVE entry is updated to include that data after the CISA ADP has made their assessment, the CISA ADP will drop its own assessments from the CVE entry. This approach will reduce duplicate (and conflicting) data within the CVE record. In the rare event that there is CWE, CVSS, or CPE data provided by the originating CNA and the CISA ADP, this should be treated as an error in the CISA ADP container, and the originating CNA's data should take precedence.
SSVC data is encoded in a way that aligns with the schema for the SSVC version used in the decision tree that generated the data. Currently, CISA is utilizing the CISA Coordinator tree.
The version field in SSVC data follows the major.minor.patch convention, where major.minor denotes the SSVC version, and patch denotes the decision tree version. For the current CISA decision tree, this results in a version number of 2.0.3: SSVC version 2.0, CISA Coordinator tree version 3.
Updates to the decision tree to conform with updates to SSVC will result in changes to the version string. Users consuming this data are urged to observe the version when decoding SSVC scores to determine how to validate and process the JSON data.
We want to hear from you, the IT cybersecurity professional community, about Vulnrichment and ADP! If you see something, please feel free to say something in the Issues, or even better, open a Pull Request with your suggested fix. Note that if you have an issue with the data from the CNA container, you are encouraged to take that issue up with the responsible CNA directly.