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

Scope. This is a workflow guide built on public specifications and feeds, plus one script we ran. On November 2, 2026 we read the CVE JSON schema (5.2.0), CISA’s Vulnrichment README, CERT/CC’s SSVC deployer documentation and decision table, the OpenVEX specification and the EPSS repository README, and ran the script below against the KEV catalog (version 2026.10.30), the EPSS file scored 2026-11-01 and CVE records from cvelistV5. The assets, exposure ratings and the VEX document in the test are invented for the demonstration. The policy choices in the script are ours, not a standard.

The workflow in one table

Our comparison of CVSS, EPSS and KEV explains what each signal measures. This guide is the plumbing: the order in which a finding from a scanner or SBOM passes through the data, and what lands in the ticket.

Steps 1 to 3 remove work. Steps 4 to 6 order what remains.

Step 1: check the record state

A CVE record is either PUBLISHED or REJECTED (the schema’s two states), and published records can carry tags such as disputed. A rejected ID has no affected products to evaluate. In our test run, CVE-2026-23915 is a Fortinet-assigned ID that was rejected on January 20, 2026 with the reason “Not used”, so the finding closes. Our guide to CVE record states covers the tags and edge cases.

Step 2: confirm you are affected

The CNA’s affected block is an algorithm, not a list: walk versions, take the first match, otherwise use defaultStatus, and if that is missing the schema says the status is unknown. Scanner results that only match a product name skip this. Our explainer on CVE affected versions shows how lessThan, defaultStatus and versionType combine, with a tested evaluator. Keep three outcomes apart in the ticket: affected, unaffected, and unknown or undetermined. The last needs a person or the vendor advisory.

Step 3: apply supplier VEX

If the vulnerable component ships inside someone else’s product, the supplier may publish a VEX (Vulnerability Exploitability eXchange) statement. OpenVEX defines four statuses: not_affected (“No remediation is required regarding this vulnerability”), affected, fixed and under_investigation. A not_affected statement must carry a justification or an impact statement.

Two cautions. A VEX statement is about a specific product and version, so match on the product identifier, not on the CVE alone; a not_affected statement from an appliance vendor says nothing about your own services that use the same library. And read the justification before closing. Our guide to reading a VEX not-affected statement covers the five justifications and what to question.

Step 4: read the exploitation evidence

Two public sources answer “is this being exploited?”:

• KEV. The CISA KEV JSON feed lists CVEs with evidence of exploitation, with dateAdded, dueDate, knownRansomwareCampaignUse and, on newer entries, forensicTriage. The catalog we used (version 2026.10.30, released October 30, 2026) had 1,766 entries.
• CISA’s SSVC values in the CVE record. CISA’s Vulnrichment project writes three SSVC decision points (Exploitation, Automatable, Technical Impact) into a CISA-ADP container. Its README says CISA is “assessing new and recent CVEs”, and that it will not overwrite the CNA’s data. Each value set carries a timestamp. Our Vulnrichment guide shows where they sit and how to pull them with jq.

The SSVC documentation describes Exploitation as “the present state of exploitation”, not a prediction. A none from months ago can be stale, so a KEV listing should outrank an older ADP value. That is the rule our script applies.

Step 5: add EPSS for likelihood

For findings with no exploitation evidence, EPSS estimates “the probability [0-1] of exploitation in the wild in the next 30 days”, and percentile gives the share of scored CVEs with the same or a lower score. The file we used (model v2026.06.15, scored 2026-11-01) held 398,784 CVEs. EPSS is a ranking aid within the non-exploited queue. It does not replace step 4: in our run the KEV-listed FortiMail flaw scored 0.04573. See the EPSS data feed guide for the columns, model-version breaks and a scanner join.

Step 6: let exposure and impact decide

CERT/CC’s SSVC deployer model maps four inputs to a patch priority:

The decision table (deployer_patch_application_priority_1_0_0.csv, 72 rows) returns one of four outcomes, which the deployer documentation defines as: Defer (“Do not act at present”), Scheduled (“Act during regularly scheduled maintenance time”), Out-of-cycle (“Act more quickly than usual… during the next available opportunity”) and Immediate (“Act immediately; focus all resources on applying the fix”). In the table, Immediate appears in 3 rows, all with active exploitation and open exposure. Our SSVC deployer explainer walks through the inputs, including where Human Impact is easy to get wrong.

One mapping detail: CISA’s ADP data writes poc, while the deployer table uses public poc. They are not identical definitions. CISA’s tree uses the older PoC value, which also covers privately attested exploitation and widespread hearsay; the newer Public PoC value covers only public exploit code or a well-known method. Our script maps one to the other, which can understate cases CISA marked poc on private evidence.

A tested script that writes the ticket fields

The script reads a findings CSV, the KEV JSON, the EPSS daily file, the SSVC deployer CSV, a folder of CVE records and an optional OpenVEX file, and prints one ticket row per finding. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Turn scanner findings into patch-decision ticket rows.

Inputs : findings.csv (asset,product,cve,exposure,human_impact)
         KEV JSON, EPSS daily CSV (.csv.gz), SSVC deployer table CSV,
         a directory of cvelistV5 records, optional OpenVEX file.
Output : tickets.csv on stdout. Python 3.10+, standard library only.
"""
import csv, gzip, json, sys, argparse, pathlib

def load_kev(path):
    data = json.load(open(path))
    return {v["cveID"].strip().upper(): v for v in data["vulnerabilities"]}

def load_epss(path):
    scores = {}
    with gzip.open(path, "rt") as fh:
        rows = (line for line in fh if not line.startswith("#"))
        for r in csv.DictReader(rows):
            scores[r["cve"]] = (float(r["epss"]), float(r["percentile"]))
    return scores

def load_deployer(path):
    rows = list(csv.reader(open(path)))
    return {tuple(r[1:5]): r[5] for r in rows[1:]}

def load_vex(path):
    out = {}
    if path:
        for s in json.load(open(path)).get("statements", []):
            for p in s.get("products", []):
                out[(s["vulnerability"]["name"].upper(), p["@id"])] = s
    return out

def cisa_ssvc(record):
    """Return CISA ADP SSVC values (Exploitation, Automatable, Technical Impact, timestamp)."""
    for adp in record["containers"].get("adp", []):
        for m in adp.get("metrics", []):
            other = m.get("other", {})
            if other.get("type") == "ssvc":
                c = other["content"]
                opts = {k: v for o in c["options"] for k, v in o.items()}
                return (opts.get("Exploitation"), opts.get("Automatable"),
                        opts.get("Technical Impact"), c.get("timestamp"))
    return (None, None, None, None)

def main():
    ap = argparse.ArgumentParser()
    for a in ("findings", "kev", "epss", "deployer", "records"):
        ap.add_argument(a)
    ap.add_argument("--vex")
    args = ap.parse_args()
    kev, epss = load_kev(args.kev), load_epss(args.epss)
    table, vex = load_deployer(args.deployer), load_vex(args.vex)
    out = csv.writer(sys.stdout)
    out.writerow(["asset", "cve", "record_state", "vex_status", "kev_dateAdded",
                  "kev_dueDate", "kev_ransomware", "cisa_exploitation", "cisa_automatable",
                  "cisa_technical_impact", "cisa_ssvc_timestamp", "epss", "epss_percentile",
                  "deployer_exploitation", "deployer_priority", "next_step"])
    for f in csv.DictReader(open(args.findings)):
        cve = f["cve"].strip().upper()
        rec_path = pathlib.Path(args.records) / f"{cve}.json"
        if not rec_path.exists():
            out.writerow([f["asset"], cve, "NO RECORD"] + [""] * 12 + ["check the ID"])
            continue
        rec = json.load(open(rec_path))
        state = rec["cveMetadata"]["state"]
        if state == "REJECTED":
            out.writerow([f["asset"], cve, state] + [""] * 12 + ["close: CVE ID rejected"])
            continue
        v = vex.get((cve, f.get("product", "")), {})  # VEX applies to one product, not every asset
        k = kev.get(cve, {})
        exp, auto, ti, ts = cisa_ssvc(rec)
        e, pct = epss.get(cve, ("", ""))
        # Our policy choice: a KEV listing counts as active exploitation, whatever
        # the (possibly older) CISA ADP snapshot says. CISA writes "poc"; the
        # deployer table writes "public poc".
        dexp = "active" if k else {"poc": "public poc"}.get(exp, exp)
        prio = ""
        if dexp and auto:
            prio = table.get((dexp, f["exposure"], auto, f["human_impact"]), "")
        if v.get("status") == "not_affected":
            step = "close: supplier VEX not_affected (" + v.get("justification", "no justification") + ")"
        elif not prio:
            step = "manual triage: no CISA SSVC data"
        else:
            step = prio
        out.writerow([f["asset"], cve, state, v.get("status", ""), k.get("dateAdded", ""),
                      k.get("dueDate", ""), k.get("knownRansomwareCampaignUse", ""),
                      exp or "", auto or "", ti or "", ts or "", e, pct, dexp or "", prio, step])

if __name__ == "__main__":
    main()

The test input (findings.csv) used invented assets with real CVE IDs:

asset,product,cve,exposure,human_impact
edge-mail-01,fortimail,CVE-2026-104286,open,high
k8s-node-17,linux-kernel,CVE-2026-46300,controlled,medium
build-runner-03,pkg:cargo/gix-fs@0.22.1,CVE-2026-100419,small,medium
billing-api,pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1,CVE-2021-44228,open,very high
vendor-appliance-2,pkg:generic/example-appliance@4.2,CVE-2021-44228,open,very high
legacy-scan,unknown,CVE-2026-23915,open,low

The VEX file is an invented OpenVEX document from an “Example Appliance Vendor” stating not_affected with justification vulnerable_code_not_present for CVE-2021-44228 in pkg:generic/example-appliance@4.2. We ran:

python3 patch_decision.py findings.csv known_exploited_vulnerabilities.json \
  epss_scores-2026-11-01.csv.gz deployer_patch_application_priority_1_0_0.csv \
  records/ --vex vendor.openvex.json > tickets.csv

The data came from raw.githubusercontent.com/cisagov/kev-data, the empiricalsec/epss_scores repository (2026/epss_scores-2026-11-01.csv.gz), CERTCC/SSVC (data/csv/ssvc/) and CVEProject/cvelistV5 at commit 451e97a. Output, with some columns dropped for width:

Three things in that output are worth noticing:

• The same CVE got two different answers (Log4Shell rows) because the VEX statement applies to one product only.
• A KEV-listed kernel flaw came out Scheduled. CVE-2026-46300 is in KEV with forensicTriage: Yes and a three-day federal due date, but with controlled exposure, no automatability and medium Human Impact the deployer table says Scheduled. If you follow CISA’s directives, the due date wins. If you do not, the table is telling you the exposure is what drives urgency. Either way, keep both fields in the ticket, and consider a compromise check when forensicTriage is Yes; our BOD 26-04 explainer covers what that flag asks agencies to do.
• EPSS and KEV disagreed on FortiMail, as expected: one estimates future observed activity, the other records evidence already seen.

What the ticket should hold

Store the inputs, not just the priority, so a reviewer can see why. A suggested field list (ours, not a standard):

Keeping it current

The feeds move at different speeds: CISA updates KEV on weekdays, EPSS publishes daily, and CVE records and VEX documents change when their authors revise them. Re-run the flow on a schedule and on any change to a ticket’s inputs, and alert when a finding’s priority rises. Set your service-level targets per priority (for example, how many days “Out-of-cycle” means for you) in policy, not in the script; the deployer model does not define days.

Limits of this article

The script is a working example, not a product. It reads CVE records from a local folder (it does not fetch them), does not evaluate affected versions itself (pair it with a version check such as the evaluator in our affected-versions guide), handles OpenVEX JSON only, and uses one policy choice (KEV overrides an older CISA Exploitation value) that you may want to change. The four-value deployer inputs simplify real decisions: SSVC expects organizations to adapt trees to their context. We did not test it against commercial scanner exports.

Sources and verification