CISA's vulnrichment repository publishes the agency's ADP-container enrichment of public CVE records with SSVC decision points, CWE identifiers, CVSS scores and KEV flags for defenders and authorized security teams.

vulnrichment is not a scanner, an exploit framework, or anything you point at a target — it is the public data repository where CISA publishes its enrichment of public CVE records through the agency's ADP (Authorized Data Publisher) container. In the current phase of the project, CISA analysts assess new and recent CVEs and attach key SSVC (Stakeholder-Specific Vulnerability Categorization) decision points to each record. For higher-risk findings, the agency additionally asserts CWE identifiers and CVSS scores where the public evidence supports them. For any security team that has ever stared at a bare-bones CVE entry and wondered whether it actually matters, this repo is the answer to that question, delivered as structured JSON you can consume directly.

The architectural detail that matters most here is separation of containers. Every enriched record keeps CISA's assessments inside the ADP container, and the README is explicit that the originating CNA's data is never overwritten in the CNA container. That means the CVE record becomes a layered artifact: the CNA says what it knows, and CISA appends what it has independently determined. This is only possible because of the ADP program the CVE ecosystem launched in 2024, which added CISA as an Authorized Data Publisher. The practical consequence for downstream consumers is significant — you do not need to fork or track this repository at all if you are already consuming live CVE data, because vulnrichment results are pushed back into the main CVE corpus through the standard channels.

The workflow itself follows a two-stage funnel described in the README and illustrated in the repo's flowcharts.md. First, every analyzed CVE goes through an SSVC scoring pass that produces three decision points: Exploitation, Automatable, and Technical Impact. Second, only CVEs rated as Technical Impact: total, Automatable: yes, or with Exploitation values of poc or Active Exploitation trigger deeper analysis, where CISA determines whether enough evidence exists to assert a specific CWE and/or a CVSS score. Notably, the README concedes that in some cases CISA provides these metrics even to vulnerabilities that do not rate high on any of those decision points — human judgment still overrides the funnel.

The three SSVC decision points deserve unpacking because they encode genuinely operational questions that raw CVSS cannot. An Exploitation value of poc, as seen in the record for CVE-2024-25522, means a public proof-of-concept existed at analysis time. An Automatable value of yes, demonstrated in CVE-2024-34974, indicates an attacker could exploit the flaw at will without worrying about recon, weaponization, delivery, or exploitation-prevention friction — effectively a wormability signal. A Technical Impact of total, shown in CVE-2024-35057, means successful exploitation generally grants the attacker total control over the impacted software. Read together, these three values give a prioritization picture that is far closer to how attackers actually behave than a static severity number.

For defenders running patch programs, the KEV block is arguably the highest-value enrichment. When a CVE appears in CISA's Known Exploited Vulnerabilities catalog, the ADP container gains an other node of type: kev containing dateAdded and a reference link back to the catalog entry — the README walks through CVE-2024-4947 as the worked example, with its schema defined in assets/kev_metrics_schema-1.0.json. CVEs not on the KEV simply receive no update. This means a pipeline that consumes vulnrichment can programmatically flag Fed-configuration-relevant vulnerabilities without maintaining a separate KEV sync job, which is a meaningful simplification for smaller security engineering teams.

The CWE enrichment addresses one of the chronic gaps in CVE quality: CNAs frequently ship records without a weakness classification. The README's example is CVE-2024-3477, where the originating CNA provided no CWE and a CISA analyst derived CWE-352 (Cross-Site Request Forgery) from the available vulnerability context, recorded under the problemTypes node in standard CVE format. Similarly, CVSS enrichment fills in scoring where the CNA did not — CVE-2024-0043 received a CISA-calculated cvssV3_1 block with a base score of 7.8, AV:LOCAL, and a full vector string. One important historical note: as of December 10, 2024, CISA stopped adding CPE strings to new enrichments, though previously enriched records may still carry them, such as the cpe:2.3:a:gitlab:gitlab entry on CVE-2024-1347.

A design decision in vulnrichment that reveals a lot about CISA's intent is the de-duplication policy for updated records. If a CNA retroactively adds its own CWE, CVSS, or CPE data after CISA has already made an assessment, the CISA ADP drops its own version to reduce duplicate and conflicting data within the record. The README goes further: in the rare event both containers carry the same metric type, that should be treated as an error in the ADP container, and the originating CNA's data takes precedence. The agency is deliberately using its enrichment as a pressure mechanism to encourage CNAs to provide their own complete metadata rather than becoming a permanent crutch.

There is also a versioning subtlety that any pipeline author must handle correctly. The SSVC data is encoded according to the schema of the SSVC version used in the generating decision tree — currently the CISA Coordinator tree from the CERTCC/SSVC project. The version field follows a major.minor.patch convention where major.minor is the SSVC version and patch is the decision tree version, yielding 2.0.3 today: SSVC 2.0, Coordinator tree 3. The README explicitly warns that tree updates will change this string and that consumers should inspect the version before decoding and validating the SSVC JSON, which is exactly the kind of forward-compatibility discipline that separates a durable enrichment pipeline from a brittle one.

Access patterns are straightforward for anyone already working in the CVE ecosystem. Records are standard CVE-format JSON organized by year and ID range (for example, 2024/25xxx/CVE-2024-25522.json), retrievable via the GitHub API, and the README points to the CVE Services API for live consumption. The repo defaults to the develop branch, is licensed CC0-1.0 (public domain), and sits at 866 stars at the time of this writing. CISA actively solicits issues and pull requests from the professional community, though data problems in the CNA container itself should be raised with the responsible CNA directly, not with this project.

Where this fits in an authorized workflow is concrete: vulnerability management platforms, asset-correlation engines, and risk-scoring services can join vulnrichment data against inventory to elevate patching queues using exploitation reality rather than theoretical severity. A record scoring Exploitation: none with Automatable: no and Technical Impact: partial — the low-risk pattern the README illustrates with CVE-2024-33666 — can rationally wait, while a poc plus Automatable: yes combination jumps the queue regardless of what the CVSS number says. That is the entire value proposition: CISA's analysts are doing the triage homework, and publishing it as reusable, machine-readable, public-domain data for the defensive community.

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

Related coverage

• Red-Team-Infrastructure-Wiki for planning resilient authorized engagement infrastructure


• Mapping your entire attack surface with cartography


• bromite for hardened, ad-free Chromium browsing on Android