CVE ADP Containers: CISA-ADP, CVE Program and Supplier ADPs

Scope. This is a specification explainer with measurements from public data. We read the CVE JSON schema (CVE_Record_Format.json, default dataVersion 5.2.0, CVEProject/cve-schema main branch), the cvelistV5 README and the CISA Vulnrichment README, then sampled 2,000 random 2026 record files from cvelistV5 at commit 1a44d59 (November 3, 2026). The script below was run with Python 3.13.

The short answer

A CVE record is not one author’s statement. Under containers there is exactly one cna object, written by the CVE Numbering Authority that assigned the ID, and an optional adp array. Each adp entry is written by an Authorized Data Publisher and names its author in providerMetadata.shortName.

In 2026 records you will mostly meet three kinds:

The rule that matters for tooling: read the CNA container and the CVE Program Container every time, read CISA-ADP for prioritization signals, and treat supplier ADPs as extra affected-product data for that supplier’s builds. Keep every value tagged with who published it.

What the schema says about ADP containers

The schema describes containers as “a set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program.” It goes on: “There can only be one ‘cna’ container, as there can only be one assigning CNA. However, there can be multiple ‘adp’ containers.”

Three details shape how you parse them:

• Only providerMetadata is required. The adpContainer definition lists providerMetadata as required with minProperties: 2, so an ADP container can be just a publisher plus one other field. Code that assumes affected, descriptions or metrics will exist breaks.
• The fields mirror the CNA container. An ADP container can carry affected, cpeApplicability, problemTypes, metrics, references, solutions, workarounds, exploits, timeline and more. The schema notes that “for the most part, the ‘cna’ and ‘adp’ containers contain the same properties. The main differences are the source of the information.”
• Extensions are allowed. adpContainer permits properties matching ^x_[^.]*$. Supplier ADPs use this: every redhat-SADP and siemens-SADP container in our sample had "x_adpType": "supplier", and Red Hat’s also carried x_generator. These are not schema-defined fields, so treat them as hints.

providerMetadata holds orgId (a UUID, required), shortName and dateUpdated. Match publishers on orgId if you need certainty; shortName is what humans read.

The three kinds you will see

CISA-ADP: prioritization signals

The cvelistV5 README says the CISA ADP provides three things: SSVC, KEV catalog data, and “Vulnrichment” updates such as “missing CVSS, CWE, CPE information for CVE Records that meet specific threat characteristics, and for when CNAs do not provide it themselves.”

What that looked like in our sample of 1,963 published records:

Every CISA-ADP container in the sample carried SSVC. CVSS and CWE were mostly gap-fills: 381 of the 389 CVSS entries (97.9%) and 326 of the 336 CWE entries (97.0%) sat on records whose CNA container had none. That matches the Vulnrichment README: “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.”

The exceptions matter. In 8 records both the CNA and CISA-ADP carried a CVSS score, and they did not always agree: in CVE-2026-70373 the CNA (TuranSec) published CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8) while CISA-ADP published .../C:H/I:N/A:N (6.5). We did not check which came first. The point is that a parser which picks “the first CVSS it finds” will produce different answers depending on container order.

The KEV block is small: dateAdded and a link to the catalog. Treat it as a pointer, and use the KEV catalog itself for dueDate, requiredAction and ransomware use. Our KEV JSON feed field guide covers those fields, and the Vulnrichment SSVC guide covers the three SSVC values.

The CVE Program Container: references you must not skip

The cvelistV5 README is explicit. The container has title “CVE Program Container” and shortName “CVE”, and “all CVE Program-added references after 7/31/2024 for a CVE Record will be stored in the CVE Program Container of that Record. CNA-provided references will continue to be stored in the CNA Container.”

It also says what tools must do: “to retrieve all information about a reported vulnerability in the CVE Repository, tool vendors and community users will need to examine the CVE Record CNA Container and the CVE Program Container (if one exists). These two containers are minimally required to obtain the core information required by the Program. All other ADP containers remain optional from a Program perspective.”

Two practical consequences:

• References tagged x_transferred were copied from the CNA container on July 31, 2024, so expect duplicates. The README says downstream users “will have to determine the appropriate way to resolve potential reference duplications.” Deduplicate on URL.
• New records only get this container if the Program adds something. In our 2026 sample, 43 records (2.2%) had one.

Supplier ADPs: a vendor’s view of someone else’s CVE

Supplier ADP containers let a vendor that ships an upstream component add its own product data to a CVE that a different CNA assigned. Siemens describes its SADP as useful when “a supplier like Siemens wants to add information to a vulnerability” in an upstream dependency, and says it was introduced in April 2026 after a pilot. Its stated aim is better scanner matching for affected Siemens products, with “known-not-affected” product data planned later.

In our sample, 24 published records (1.2%) carried one: 18 from redhat-SADP, 6 from siemens-SADP. Their shapes differ:

• redhat-SADP containers looked like a full advisory: affected entries per Red Hat product stream with CPEs, package names and RPM versionType, plus Red Hat’s severity rating, CVSS, solutions, workarounds and references.
• siemens-SADP containers were lean: affected entries for Siemens products, references to the Siemens advisory, and nothing else. All had defaultStatus set to unknown.

Two traps. First, supplier affected data describes the supplier’s product names and version strings, not the upstream project’s. A Red Hat entry such as defaultStatus: affected with lessThan: "*" and status: unaffected from a fixed RPM version is a statement about that Red Hat package, which is how our affected-versions guide explains these encodings. Second, supplier severity ratings and CVSS are the supplier’s assessment for its builds and can legitimately differ from the CNA’s.

One record, four publishers

CVE-2026-46300 is a Linux kernel flaw assigned by the Linux CNA and added to the KEV catalog on October 28, 2026. Its record shows why you need a per-provider view. This is the output of the script in the next section against the cvelistV5 file at commit 1a44d59:

CVE-2026-46300 PUBLISHED dataVersion 5.2

[cna] Linux (updated 2026-08-05)
  cvss: ['3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H']
  affected_products: 2
  references: 8

[adp] CVE (updated 2026-05-23)
  references: 4

[adp] redhat-SADP (updated 2026-09-01)
  other: ['Red Hat severity rating: Important']
  cvss: ['3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H']
  cwe: ['CWE-123']
  affected_products: 39
  references: 36
  solutions: 33
  workarounds: 1
  x_adpType: supplier

[adp] siemens-SADP (updated 2026-10-15)
  affected_products: 10
  references: 2
  x_adpType: supplier

[adp] CISA-ADP (updated 2026-10-29)
  ssvc: Exploitation=active, Automatable=no, Technical Impact=total
  kev: dateAdded=2026-10-28
  cwe: ['CWE-456']
  references: 1

Read it as five separate statements:

• The CNA says what the kernel project considers affected and scores it 7.8. It gives no CWE.
• The CVE Program added four references a tool reading only the CNA container would miss.
• Red Hat lists 39 affected product entries for its own streams with 33 solutions, rates it Important, and maps it to CWE-123.
• Siemens lists 10 affected product entries for its own devices.
• CISA says exploitation is active, records the KEV date, and maps it to CWE-456, a different CWE from Red Hat’s.

None of these overrides the others. A kernel team, a RHEL fleet owner and an OT engineer running Siemens PLCs each need a different slice of the same record.

A tested script: who said what

This Python script prints one block per container. It uses only the standard library and was run with Python 3.13 against the record above and against the 2,000-record sample.

#!/usr/bin/env python3
"""Print who said what in a CVE JSON 5 record: one line per container and field."""
import json, sys

def summarize(container):
    out = {}
    for m in container.get("metrics", []):
        for k, v in m.items():
            if k.startswith("cvss"):
                out.setdefault("cvss", []).append(f"{v['version']} {v['baseScore']} {v['vectorString']}")
            elif k == "other":
                t, c = v.get("type"), v.get("content", {})
                if t == "ssvc":
                    out["ssvc"] = ", ".join(f"{k2}={v2}" for o in c["options"] for k2, v2 in o.items())
                elif t == "kev":
                    out["kev"] = f"dateAdded={c.get('dateAdded')}"
                else:
                    out.setdefault("other", []).append(f"{t}: {c.get('value', c)}")
    cwes = [d["cweId"] for p in container.get("problemTypes", []) for d in p.get("descriptions", []) if d.get("cweId")]
    if cwes: out["cwe"] = cwes
    if container.get("affected"): out["affected_products"] = len(container["affected"])
    if container.get("references"): out["references"] = len(container["references"])
    for k in ("solutions", "workarounds"):
        if container.get(k): out[k] = len(container[k])
    if "x_adpType" in container: out["x_adpType"] = container["x_adpType"]
    return out

rec = json.load(open(sys.argv[1]))
c = rec["containers"]
rows = [("cna", c["cna"])] + [("adp", a) for a in c.get("adp", [])]
print(rec["cveMetadata"]["cveId"], rec["cveMetadata"]["state"], "dataVersion", rec.get("dataVersion"))
for kind, cont in rows:
    pm = cont["providerMetadata"]
    print(f"\n[{kind}] {pm.get('shortName')} (updated {pm.get('dateUpdated', '?')[:10]})")
    for k, v in summarize(cont).items():
        print(f"  {k}: {v}")

Run it with python3 containers.py CVE-2026-46300.json, using a record file from the cvelistV5 repository (cves/2026/46xxx/CVE-2026-46300.json). It is a reading aid, not a merge engine; the next section is about merging.

How to merge ADP data without lying to yourself

There is no Program-defined precedence between ADPs. The following policy is our editorial recommendation, built on the rules quoted above:

1. Always read cna and the CVE container. The README calls them the minimum. Union and deduplicate references across both.
2. Store values with their provider. Keep cvss_cna, cvss_cisa_adp and cvss_supplier side by side rather than one cvss column. The same goes for CWE.
3. Prefer the CNA for scoring, fall back to CISA-ADP. Use the CNA’s CVSS when present; use CISA-ADP’s when the CNA gave none (the common case in our sample); flag disagreements for a human when both exist.
4. Take SSVC and the KEV date from CISA-ADP. No other container in our sample carried them. Then confirm KEV details against the catalog.
5. Scope supplier data to the supplier. Use redhat-SADP affected entries only to match Red Hat packages, and siemens-SADP entries only for Siemens products. Never use them to clear or confirm an upstream version.
6. Do not ignore unknown publishers. Log any new shortName so a person can decide how to treat it, rather than dropping it silently.
7. Check the record state first. A rejected record has no ADP data to act on; see our guide to CVE record states.

These steps fit into the record-reading stage of our vulnerability prioritization workflow, which takes a CVE from record to patch ticket.

Common mistakes

• Reading only containers.cna. You lose CISA’s SSVC and KEV signals, about one in five CVSS scores in our 2026 sample, and Program-added references.
• Taking adp[0]. Container order is not a precedence order. In CVE-2026-46300, CISA-ADP came last.
• Merging CWE lists without provenance. Red Hat and CISA mapped the same CVE to different CWEs. A merged list hides that they disagree.
• Matching upstream versions against supplier entries. RPM release strings and Siemens firmware versions are not kernel versions.
• Hard-coding today’s publisher list. Supplier ADP is new. More publishers will appear.

Limits of this article

The sample covers 2,000 of 84,066 2026 record files in cvelistV5 on November 3, 2026, chosen at random, and 2026 records only. Shares will differ for older years, since the README says the CISA-ADP container was launched on June 4 (2024) and applied back to February 2024. We could not load cve.org’s ADP pages (they render with JavaScript), so the description of supplier ADPs relies on Siemens’ own page and on the records themselves. x_adpType is an extension field, not part of the schema. We did not check how NVD or commercial scanners consume ADP data.

Sources and verification

Vulnerability ManagementCveCve Json 5Cisa VulnrichmentAdpSsvc