Vulnerability Data Architecture

The identifier layer went plural and the enrichment went partial

October 21, 2026·9 min read·CVEasy Threat Research
Four tall mint-green pillars rise over paper, each capped with a different ink-outlined badge for CVE, EUVD, GHSA, and vendor advisories, and a dashed gold horizontal join line stretches between them but is broken in the middle with a hollow gold circle marked by a gold X standing in for the lost CPE, while below the pillars four ink curves gather downward into a single mint-filled hexagonal alias set node that carries small shapes mirroring every pillar cap and a short gold flag beside it

Every vulnerability program built in the last fifteen years rests on a quiet assumption, which is that someone else turns a raw CVE identifier into a structured record a scanner can act on. Someone else writes the CPE, the CVSS, the CWE, the description that lets a tool line a finding up against your inventory. The assumption held while NIST's National Vulnerability Database did that work. On April 15, 2026 it stopped doing most of it.

About 29,000 backlogged records moved to "Not Scheduled" in a single policy change, and the new rule narrowed enrichment to three populations (CVEs in CISA KEV, software used by the federal government, and the EO 14028 critical software list), per NIST's announcement and Help Net Security's coverage. Everything else now receives no CVSS, no CPE, and no CWE, indefinitely. The Cloud Security Alliance research note estimates the policy covers roughly 15 to 20 percent of projected CVE volume, against about 42,000 CVEs enriched in 2025 and 50,000 to 70,000 projected for 2026.

The identifier layer went plural at the same time. ENISA's EU Vulnerability Database launched May 13, 2025 as a complementary repository alongside CVE, issuing EUVD identifiers that pair with CVE IDs (VulnCheck's assessment). ENISA was elevated to a CVE Program Root on November 20, 2025, and the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities through ENISA's Single Reporting Platform starting September 11, 2026 (CRA reporting via ENISA). Three identifier databases now matter to any vulnerability program with EU exposure, and one of them owns the reporting pipe.

The April 2025 funding scare sits in the background and no longer sets the pace. CISA extended MITRE's CVE contract eleven hours before it lapsed, the extension ran eleven months, and funding has since been secured again on terms that remain opaque, with a FOIA request for the contract unanswered (CSO Online, The Record). The identifier program is funded; the enrichment layer that made identifiers useful at scale is now explicitly partial. The question for a vulnerability program is architectural rather than political, which is what you have to build when identifiers are plural, enrichment is conditional, and your scanner's CPE match no longer resolves on roughly four fifths of 2026 inflow.

CPE is the quiet casualty

CVSS has substitutes. If NIST stops publishing a base score, you can lift the vendor score, run EPSS or LEV, or score with SSVC, and BOD 26-04, effective June 10, 2026, has already pulled CVSS out of the required federal input entirely and replaced it with a four-factor model (asset exposure, KEV status, automatability, technical impact) producing remediation windows of three, fourteen, or sixty days. CVSS is a replaceable score.

CPE is a replaceable join key only in theory. The Common Platform Enumeration is the string a scanner uses to answer the question "do I have this product on this host," and most scanner backends match on NIST-supplied CPEs because that is what made the identifier set uniformly joinable to inventory. "Not Scheduled" is announced as a policy choice, but the practical effect is that a growing share of the corpus carries no CPE at all, so your scanner has nothing to match on until a human writes one or another authority publishes it. SBOM pipelines running package URLs (PURLs) are insulated; host and appliance scanners are not. OSV and GHSA cover open source cleanly through PURL and ecosystem names, vendor advisories cover their own products, and neither answers the full picture a Fortune 500 inventory contains. That is a data engineering problem wearing a policy announcement's clothes, and it does not go away when the funding question gets resolved.

The identifier set is now plural

The ecosystem a program's data model has to carry is at least four roots.

  • CVE, maintained by MITRE under contract with CISA, the universal identifier the rest of the world still aliases to.
  • EUVD, maintained by ENISA under NIS2 with CIRCL's Vulnerability-Lookup, with its own EUVD-YEAR-N identifiers and advisory sources that sometimes publish before a CVE ID is assigned.
  • GitHub Security Advisory (GHSA), the open source authoritative source for npm, PyPI, Composer, RubyGems, and the rest, feeding OSV and often leading NVD on package-level enrichment.
  • Vendor advisories, the authoritative source for their own products and almost always first to publish, with product identifiers that only sometimes map cleanly to CPE or PURL.

A single finding frequently carries three or four identifiers, each from an authority with its own enrichment and sometimes contradictory details. Keying your findings table on "CVE ID" has been subtly wrong for years; it is now operationally wrong at scale. The join key for a modern vulnerability program is an alias set, and the alias set is the primary key of the finding record.

A precedence policy when authorities disagree

Two authorities will disagree, and the precedence policy is a short written document the on-call engineer can read in forty seconds, not a spreadsheet of edge cases. A working shape:

  1. For enrichment metadata (affected products, severity, CWE, exploitability), the vendor advisory wins where it exists.
  2. Where there is no vendor advisory, the ecosystem authority wins (GHSA for open source packages, OSV where it carries the authoritative range).
  3. Where neither exists, the regional database covering the asset wins (EUVD for EU exposure, NVD for federal exposure on records NVD is still enriching).
  4. CPE follows the same precedence. If no authority publishes one, the program builds its own from product identifiers (PURL where available, vendor product strings otherwise) rather than failing closed.
  5. KEV, EPSS, and SSVC decisions are sourced independently and merged last.

None of this is novel. CSAF (OASIS) and CycloneDX have carried the plumbing for a precedence model since 2022, and VulnCheck's long-running work on NVD alternatives has described the same shape in different words. What is novel is that until this year the policy was mostly theoretical because NIST's enrichment was the practical default. It no longer is.

What a program ships this quarter

The engineering is unglamorous and worth doing anyway. Mirror the inputs you still trust by pulling CISA KEV, EPSS, the CVE JSON feeds, OSV, and the EUVD export on your own cadence into a local store, storing the raw advisories alongside the extracted fields because the extraction logic will change again. Air-gapped environments already run on a mirror by necessity (the shape is in the air-gapped intel pipeline), and non-air-gapped environments benefit from the same discipline because enrichment has to survive any one source going silent for a week.

Model the finding as an alias set, keyed on the set rather than on a lead ID. Every alias carries its source authority and the timestamp it was first observed, so a single record holds something like {cve: CVE-2026-12345, euvd: EUVD-2026-9876, ghsa: GHSA-aaaa-bbbb-cccc, vendor: CISCO-SA-2026-11-A}, and a record missing one authority's identifier is still joinable through the others.

The product-to-finding matcher is yours now, not the scanner's. Where you have an SBOM, match on PURL and ecosystem name. Where you have host inventory, match on vendor-and-product strings from the CMDB and treat the scanner's CPE as a hint. The matcher produces a confidence score, and low-confidence matches surface for human review rather than silently dropping.

Finally, write the precedence policy on one page, attach it to the on-call runbook, and rehearse it against last quarter's hardest multi-authority finding before it rehearses itself against this quarter's.

The sovereignty read

The EU did not build EUVD because the identifier database was broken. They built it because the identifier database and the reporting pipeline sit in the same operational layer. By September 11, 2026 the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities to ENISA's Single Reporting Platform, which uses the same identifier scheme EUVD does. Pairing an identifier authority with a mandatory reporting platform is a sovereignty move with technical consequences, so EU-regulated manufacturers now have operational incentive to report into the EU stack first. A regional identifier database paired with a mandatory reporting pipe is a template cheaper to copy than to replace, and the plural identifier set we have today is the floor rather than the ceiling. Dual-ID plumbing is a 2027 engineering requirement.

The patch backlog bankruptcy piece in September read the NVD triage as a governance precedent; this one reads it as architecture. Different frame, same event, different work on the roadmap.

Build the layer you own

The identifier layer you can trust is the one you mirror, your alias set, and your written precedence policy. The organisations that treated upstream enrichment as free are the ones scrambling in October; the ones that already ran mirrors and kept their own match logic have a smaller rebuild in front of them.

CVEasy AI is the local-first CTEM platform we built around an alias set rather than a single ID, with intel mirrored on your hardware and the precedence policy a first-class object in the console. The data model we chose in 2024 is the shape the rest of the industry now has to build.