vulnrichment publishes CISA's CVE scoring records as plain JSON

A public record of what CISA adds to CVE entries

The repository describes itself as the public repository of CISA's enrichment of public CVE records through CISA's ADP, the Authorized Data Publisher, container. That framing sets the whole expectation. This is not a scanner, not a feed and not a service. It is the published output of an analysis process, laid out as JSON files, so that anyone can see exactly what CISA decided about a given CVE and why.

The project is aimed at people who already produce or consume CVE data. The README says so directly, noting that producers and consumers should already be familiar with the current CVE Record Format and can access the data in the normal ways, including the GitHub API and the CVE Services API.

The layout is plain. The top-level entries are year directories from `1999/` through `2026/`, plus `assets/`, `flowcharts.md`, `CONTRIBUTING.md`, `LICENSE` and `README.md`. Each year directory holds the CVE JSON files in the same layout the record format uses, with paths like `2024/25xxx/CVE-2024-25522.json`, and the files carry the same identifiers the CVE program uses.

The licence is CC0-1.0, which is worth noting for a data project. There is no permission to obtain and no attribution requirement, so the enriched records can be copied into a corpus, redistributed or used to build a derived dataset without tracking license terms on the output. That is unusual for a government repository and it removes a common friction point for anyone building on top of CVE data.

SSVC triage decides which CVEs get worked on next

The process the README describes starts with every CVE going through an SSVC scoring process, where SSVC is CISA's Stakeholder-Specific Vulnerability Categorization. Three decision points are recorded for every CVE that CISA analyzes: Exploitation, Automatable and Technical Impact.

After scoring, there is a filter. CVEs rated as "Total Technical Impact", "Automatable", or carrying an Exploitation value of "Proof of Concept" or "Active Exploitation" go on to further analysis. That subset is the one where the cost of a CWE identification or a CVSS score is justified.

The README is also candid about the edges of that filter, noting that in some cases CISA provides these metrics even to vulnerabilities that do not rate as high risk on any of those decision points. So the threshold is a guide, not a hard gate.

The decision point values are visible in the record. This example is the SSVC block for CVE-2024-25522, which the README points to as having a "poc" value for Exploitation, meaning a public proof of concept was available at the time of analysis.

"options": [
  {
    "Exploitation": "poc"
  },
  {
    "Automatable": "yes"
  },
  {
    "Technical Impact": "total"
  }
]

The README explains what the values mean in prose next to the data. An Automatable value of yes indicates an attacker could generally exploit the vulnerability at will, without worrying about recon, weaponization, delivery or exploitation prevention techniques. A Technical Impact of total indicates that exploiting the vulnerability generally gives the attacker total control over the impacted software.

The ADP container never overwrites the originating CNA

The most important structural rule is stated twice in the README, and it explains why this repository can be public without breaking anyone's workflow.

CISA populates the associated ADP container with CWE, CVSS and similar values, and at no point does it overwrite the originating CNA's data in the original CNA container in the CVE record. A CVE record therefore carries two independent containers. The CNA container holds what the numbering authority said when it published the record, and the ADP container holds what CISA added later. Nothing is merged, and nothing is silently replaced.

The second rule concerns maintenance rather than structure. If a CVE entry is updated later to include CWE, CVSS or CPE data that the originating CNA provided, then the CISA ADP drops its own assessments from the entry. The stated reason is to reduce duplicate and possibly conflicting data within the record, and the README frames the practice as an encouragement for CNAs to provide their own data.

That second rule has a consequence for anyone archiving these files. An enrichment you see today may be gone from the file later, not because it was wrong but because the CNA supplied the same information. A snapshot taken from the repository is a record of what CISA had published at that point in time, not a permanent addition to the CVE.

What an enriched record looks like in practice

The README walks through the concrete JSON shapes, which is the fastest way to understand what you get.

A CVE on the KEV catalog, the Known Exploited Vulnerabilities catalog, gets a KEV block in the `other` node, and no update occurs for CVEs that are not on the list.

"other": {
  "type": "kev",
  "content": {
    "dateAdded": "2024-05-20",
    "reference": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-4947"
  }
}

A CWE identifier appears under the `problemTypes` node, in the case of CVE-2024-3477 determined by a CISA analyst from the context of the vulnerability information available.

"problemTypes": [
  {
    "descriptions": [
      {
        "lang": "en",
        "type": "CWE",
        "cweId": "CWE-352",
        "description": "CWE-352 Cross-Site Request Forgery (CSRF)"
      }
    ]
  }
]

A CVSS calculation is added in the same way, as a `cvssV3_1` object carrying the base score, the vector string and the individual impact metrics.

"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"
}

The README also shows the case where nothing happens. CVE-2024-2905 already had CWE, CVSS and CPE metrics when CISA performed the SSVC triage step, and it is not on the KEV, so no additional update was needed.

CPE enrichment stopped on 2024-12-10

One enrichment type has been retired, and the README keeps its history in place rather than deleting it.

As of December 10, 2024, CISA no longer adds CPE strings to the enriched dataset. Previously enriched data may still contain CPE information, and the README states that the notes regarding CPE strings are for historical purposes. The example it keeps is CVE-2024-1347, which had a CPE string added by CISA.

"cpes": [
  "cpe:2.3:a:gitlab:gitlab:*:*:*:*:*:*:*:*"
]

This is a good example of a data project that records its own history rather than pretending a decision was never made. A consumer building a parser over this repository has to handle three states for a CPE field: present and CISA-authored, present from the CNA, or absent, and the absence no longer implies anything about the vulnerability.

The flowcharts referenced in the README, in `flowcharts.md`, illustrate the process, and the README adds the caveat that their details are subject to change as the process is refined. Combined with the notice that the project is under active development, that is a signal that the shape of the enrichment changes over time, and that a consumer who hardcodes assumptions about which fields appear will need to revisit them.

Consuming the corpus without forking the repository

The README is direct about how you should get this data if you are building a pipeline rather than studying the process. It notes that the results of Vulnrichment are being pushed back to the CVE corpus through the ADP Program launched in 2024, and that downstream consumers need not fork and track this GitHub repository if they are already consuming live CVE data.

That is the single most important line in the README for an adopter. The repository is the transparent record of what CISA published, and the way to consume it in production is through the CVE data sources you already use, with CISA's ADP container arriving as part of the normal record.

The difference between the two paths is about intent rather than mechanism. Pulling the year directories gives you a frozen view with the exact JSON, the git history and the ability to see when a given assessment appeared or disappeared, which is what you want for research, auditing and diffing. Consuming the live corpus gives you the current state of every record including CISA's contributions, which is what you want for vulnerability management tooling.

The alternative worth naming is a private enrichment pipeline of your own, where an analyst scores incoming CVEs and writes the results into your own store. The difference in approach is that this repository publishes decisions with the reasoning visible in the record and the process documented in the flowcharts, so a team that adopts it starts from CISA's assessment rather than from a blank scoring sheet, while a private pipeline produces assessments tied to your own decision criteria and stays under your control.

Editorial conclusion

Use the vulnrichment repository when you need to study how CISA's ADP scores vulnerabilities, to diff a local copy of CVE data against the enriched records, or to see the concrete JSON shape of an SSVC, KEV, CWE or CVSS enrichment. Do not build a pipeline on it as a substitute for the CVE corpus itself, because the README says the results are pushed back through the ADP program and that downstream consumers need not fork or track this repository. Verify first which year directories hold the CVEs you care about, and check that a given record still carries the CISA container, since CISA removes its own assessments once the originating CNA supplies the same data.

Frequently asked questions

Official sources

1. cisagov/vulnrichment on GitHub
2. Issues
3. License: CC0-1.0
4. README