CISA Vulnrichment: How to Read SSVC Values in a CVE Record and Turn Them into a Patch Decision

If a CVE record has been analyzed by CISA, it contains three small fields that answer a triage question faster than most advisories do: is this being exploited, can attackers automate it, and what do they get if it works. They sit inside the record under CISA’s Authorized Data Publisher (ADP) container, and you can read them with one curl and one jq command. This article shows where the fields are, what each value means, what the data cannot tell you, and how CISA’s own decision table converts the three values plus one input from you into one of four actions.

We read CISA’s Vulnrichment README and flowcharts, the SSVC project’s definitions of the decision points, and CISA’s published decision tree file, and we ran the commands below against the live CVE Services API on October 14, 2026. This is research-based explanation plus our own command-line checks of public records; we did not scan any systems.

The short answer

• What it is: CISA’s Vulnrichment project enriches public CVE records. For each CVE CISA analyzes it adds three SSVC (Stakeholder-Specific Vulnerability Categorization) decision points: Exploitation, Automatable and Technical Impact. For some it also adds a CWE weakness identifier or a CVSS score.
• Where to read it: the adp array in the CVE record, in the entry whose providerMetadata.shortName is CISA-ADP.
• What to do with it: combine it with your own exposure and asset criticality. CISA’s decision table needs a fourth input, which only you can supply.

Where the data lives

A CVE record in the CVE Record Format has a CNA container, written by the organization that assigned the CVE, and zero or more ADP containers, written by other authorized publishers. CISA’s README says CISA never overwrites the CNA’s data in the CNA container; it writes its additions to its own ADP container.

You can fetch any record from the CVE Services API and filter for CISA’s entry. This is the command we ran (it needs curl and jq):

curl -s https://cveawg.mitre.org/api/cve/CVE-2024-4947 | jq '[
  .containers.adp[]?
  | select(.providerMetadata.shortName == "CISA-ADP")
  | .metrics[]?
  | select(.other.type == "ssvc")
  | .other.content
  | {version, timestamp, options: (.options | add)}
]'

On October 14, 2026 it returned, for CVE-2024-4947:

[
  {
    "version": "2.0.3",
    "timestamp": "2024-05-23T20:01:07.846921Z",
    "options": {
      "Exploitation": "active",
      "Automatable": "no",
      "Technical Impact": "total"
    }
  }
]

If CISA has not analyzed a CVE, the command returns []. Replace "ssvc" with "kev" and .other.content with .other.content.dateAdded to read the date CISA’s ADP container recorded the CVE being added to the Known Exploited Vulnerabilities (KEV) catalog; for CVE-2024-4947 that was 2024-05-20.

Two fields deserve attention:

• timestamp is when CISA produced that SSVC result. The record above is from May 2024. Exploitation can change after that date.
• version follows a major.minor.patch pattern. CISA’s README says major.minor is the SSVC version and the patch number is the version of CISA’s decision tree, so 2.0.3 means SSVC 2.0 and CISA Coordinator tree version 3. The README asks consumers to check this before validating or processing the JSON.

What the three values mean

Some details change how you should read them:

• Exploitation is present-tense, not predictive. The SSVC documentation says it measures current exploitation, not predicted future exploitation, and points to predictive systems such as EPSS for that. A none value means no exploitation evidence at the time of analysis, not that exploitation will not happen.
• The definitions of poc differ between versions. The SSVC project says Exploitation version 1.0.0 also counted privately attested exploitation and widespread hearsay under poc; version 1.1.0 limits it to public PoCs and well-known methods. CISA’s Coordinator tree file we read (v2.0.3) still carries the broader 1.0.0-style wording. Treat poc as “exploit knowledge exists”, not as a measured exploit-development effort.
• Automatable defaults to yes. The SSVC documentation says that if nothing is known, assume Yes, and that remote code execution or command injection should generally be scored Yes. Reasons for No include a component that is not discoverable on the network, weaponization that needs manual work per target, delivery blocked by common network controls, or exploit-prevention features that make exploitation unreliable.
• Technical Impact is relative to the vulnerable component. The SSVC documentation says control is judged relative to the affected component where the flaw resides. It does not describe how much of your network the attacker then reaches.

How CISA picks which CVEs get more data

CISA’s README says that CVEs rated Total Technical Impact, Automatable, or with Exploitation poc or active get further analysis for a CWE identifier and a CVSS score, where there is enough information, and that CISA may provide those even for lower-rated CVEs. The README also says that if the CNA later provides its own CWE, CVSS or CPE data, CISA removes its own, and if both exist the CNA’s data takes precedence. As of December 10, 2024, CISA no longer adds CPE strings.

Four records, four profiles

We pulled these records from the CVE Services API on October 14, 2026. The three values are as CISA recorded them at the timestamp shown.

CVE-2024-25522 shows why you need more than one field. CISA’s ADP container also carries a CVSS v3.1 base score of 9.4 for it (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), yet its SSVC profile is only poc, with no exploitation evidence. A near-critical severity score and an unexploited status can coexist; they answer different questions. Our companion article on CVSS, EPSS and KEV covers how to combine them.

For records published in September 2026, the same command returned active / yes / total for CVE-2026-76504 (KEV block dated 2026-09-30, and covered in our Cisco SD-WAN Manager article) and for CVE-2026-88771 (KEV block dated 2026-09-27, covered in our NetScaler article).

From three values to a decision

CISA’s SSVC page says its tree uses five decision points (exploitation status, technical impact, automatable, mission prevalence and public well-being impact) and ends in one of four outcomes. It describes them as follows:

Vulnrichment fills in three of the five. The other two, Mission Prevalence and Public Well-being Impact, are combined in CISA’s tree file into a single input called Mission and Well-being, with three values:

• Low: Mission Prevalence is Minimal and Public Well-being Impact is Minimal.
• Medium: Mission Prevalence is Support and Public Well-being is Minimal or Material, or Mission Prevalence is Minimal or Support and Public Well-being is Material.
• High: Mission Prevalence is Essential, or Public Well-being Impact is Irreversible.

Our reading, not stated in the README, is that these two are left out of the public record because they depend on who you are and what the component does in your environment, which a public CVE record cannot know.

CISA’s tree file lists all 36 combinations. The table below is the full result for the three Vulnrichment values and each Mission and Well-being level. We extracted it directly from the file (CISA-Coordinator.json, title “CISA Coordinator v2.0.3”) and checked that each of the 12 combinations has exactly one outcome per level.

Applying it to the records above:

• CVE-2024-4947 (active / no / total): Track if the affected software is of minimal mission relevance to you, Attend at medium, Act at high.
• CVE-2024-25522 (poc / yes / total): Track at low, Track* at medium, Attend at high. Despite the 9.4 CVSS score, the tree does not send it to Act at any level.
• CVE-2024-34974 (none / yes / partial): Track at low and medium, Attend at high.
• CVE-2021-44228 (active / yes / total): Attend at low, Act at medium and high.

Two cautions on this table. First, it uses a data file from the CERT/CC SSVC repository’s main branch, which the Vulnrichment README links as the tree CISA currently uses; a newer tree version would change both the version string in records and possibly the table. Second, “Track” in the tree is not “never patch”: CISA’s description says remediation still follows standard update timelines.

How to use this without over-trusting it

1. Read the timestamp first. A May 2024 none for Exploitation says nothing about October 2026. Cross-check KEV and the vendor advisory.
2. Treat a missing block as missing data. CISA’s README describes Vulnrichment as covering new and recent CVEs that CISA assesses. No CISA-ADP entry means no CISA SSVC result, not low risk.
3. Decide your Mission and Well-being input per asset class, once. Write down which systems are Minimal, Support or Essential for your organization, so triage does not reopen the question for every CVE. That classification is yours; CISA’s data cannot supply it.
4. Keep your own exposure facts separate. The tree does not know whether the vulnerable service is reachable from the internet in your environment. An internet-facing instance can justify a faster timeline than the table’s output.
5. Do not confuse SSVC outcomes with legal deadlines. Our BOD 26-04 explainer covers the KEV deadlines that bind federal agencies. SSVC’s Track, Attend and Act are decision aids, not deadlines.

Limits of this article

• We ran read-only queries against public records and read documentation; we did not test any automation at scale or measure how complete Vulnrichment coverage is.
• The records in the tables are examples chosen to show different profiles, not a statistical sample.
• Values in live records can change; the numbers above are as of October 14, 2026.
• We did not read CISA’s separate SSVC Guide PDF, so the tree logic is taken from the published JSON file rather than from CISA’s prose explanation.

Sources and verification

Vulnerability ManagementProcess