The CVE identifier has stopped being a consistent unit of work. A preprint published July 6 on arXiv maps how vulnerability assignment migrated from NVD’s single authority to a federated sprawl of CVE Numbering Authorities, each scoring, scoping, and disclosing on its own terms. The result, per the paper’s title, is “The Cathedral and the Bazaar of Software Vulnerabilities,” and the bazaar’s inconsistency now leaks into every triage pipeline that treats a CVE as authoritative by construction.
How did CVE assignment move from NVD to a CNA federation?
For most of the database’s life, NVD was the cathedral: a single reference source for vulnerability data that downstream tools and researchers could treat as ground truth. NVD still defines a CVE as “a weakness in computational logic that when exploited results in a negative impact to confidentiality, integrity, or availability,” per its own vulnerability pages. That definition reads cleanly. The problem is that NVD no longer applies it alone.
CVE assignment now runs through a federated model governed by the CNA Rules, where a CNA can be a vendor, an open-source project, a national CERT, or a research organization. Each authority runs its own intake, its own scoring, and its own disclosure timeline. The federation grew for defensible reasons: NVD’s centralized queue had become a bottleneck, and the organization closest to a vulnerability often holds the most accurate information. But the architecture trades consistency for coverage. When the cathedral becomes a bazaar, the shared unit of work, the CVE, stops meaning the same thing at every stall.
That tradeoff is structural, not transitional. The paper’s framing treats the migration as settled rather than in-progress, and the second-order effects it documents follow from the federation being permanent. The interesting question is no longer whether CNAs should assign CVEs. It is what consumers of those identifiers are supposed to do now that “a CVE” is a family of records rather than a single authoritative one.
Where does the CVSS divergence show up?
The paper’s core empirical contribution is a systematic comparison of CVSS metrics between NVD and public CNAs, and the divergence it finds is concentrated, not random. According to the abstract, the major sites of disagreement are Attack Complexity, User Interaction, and Impact. Those three metrics are precisely the ones a triage engine leans on to rank what to patch first, which makes the disagreement load-bearing rather than cosmetic.
Then there is self-divergence. The authors checked whether a single CNA rates identical CVE descriptions, carrying identical CWEs, consistently. It does not. The same authority, given the same input, sometimes returns a different score. That is internal inconsistency, not cross-organizational disagreement, and it is the harder failure to explain away. Cross-CNA divergence could be written off as legitimate scope interpretation between different organizations. Same-authority self-divergence points at either human error or a scoring process with no stable internal rule.
The authors resist a single diagnosis. Their qualitative study involved interviews with NVD, open-source and proprietary CNAs, and the CVSS Special Interest Group at FIRST, and it lands on three root-cause buckets. Some divergence is human error. Some is defensibly correct given information the public record does not show. Some exposes gaps in the CVSS FAQs that need filling. That third bucket matters most: it means the standard itself is under-specified in places, and CNAs resolve the ambiguity differently by default.
Why does training on one CNA break the model?
Training a vulnerability-prediction model on one CNA’s dataset and deploying it against another can cost you up to 40% of your accuracy, according to the paper. The abstract states it plainly: if one downloads several years of NVD or another CNA dataset and uses it for predictions, “the models trained on one source do not reliably generalize to a different source (accuracy can drop by 40%).”
The mechanism is distribution shift in scoring conventions. A model trained on NVD data learns NVD’s tacit judgments: what counts as low Attack Complexity, when User Interaction counts as “required,” how broadly to cast Impact. Those judgments are encoded implicitly in the labels. When the model meets a vendor CNA’s records, which encode different tacit judgments for the same metric names, the feature distribution shifts and the model’s accuracy falls off a cliff. This is the standard failure mode of a model trained on one annotator and deployed on another, applied to a setting where nobody had previously measured how much the annotators disagree.
The practical implication lands hard. For a pipeline that auto-prioritizes patches, losing a third to two-fifths of your accuracy on cross-source advisories is the difference between surfacing the right CVE and quietly demoting it. The model does not error out. It returns confident-looking wrong answers, which is the most expensive failure mode a triage system can have.
What does this mean for SBOMs, agents, and triage pipelines?
SBOM tooling, agent-based advisory intake, and automated triage pipelines now carry a reconciliation job that NVD used to perform centrally, because a fetched CVE record is no longer guaranteed to be the only, or the most accurate, score for a given identifier. The cross-referencing work moved downstream onto every consumer.
Consider an advisory intake agent. It receives a CVE identifier and expects to pull a single CVSS vector, a single CWE, and a single severity rating. In 2026 that pull can return conflicting vectors from NVD, the vendor CNA, and an open-source CNA, each carrying a different base score. The agent now has to reconcile them. That reconciliation, picking which score to trust, weighting by source provenance, or escalating the conflict to a human, is labor NVD used to absorb by being the single authoritative scorer. It has been pushed onto every pipeline that consumes CVEs.
The same applies to enrichment. A CVE record from one CNA may carry a CWE that another CNA’s record omits. A pipeline that keys its reasoning on CWE presence or absence gets a different answer depending on which advisory it fetched first. For systems that chain multiple CVEs into an exploit-path analysis, the inconsistency compounds: one weak link scored inconsistently propagates uncertainty through the whole graph.
How should practitioners handle conflicting CVE records?
The practical fix is to stop treating a fetched CVE as ground truth: attribute every record to its source, cross-reference before scoring, and validate any prediction model against more than one CNA. The paper’s own framing, which separates human error from defensible divergence from standard gaps, points directly at this.
Concretely, a security team running automated intake should do three things. First, attribute. Every CVE record in your database should carry the CNA that produced it and the date it was fetched, because the same CVE record changes over time and the divergence between sources changes with it. Second, reconcile. When NVD and a vendor CNA disagree on Attack Complexity or Impact, that disagreement is a signal worth logging, not an error to average away into a single number. Third, hedge your model. If your prediction model was trained on NVD data, validate it against at least one other CNA’s records before trusting it in production. A 40% accuracy cliff is not something you want to discover after a missed patch.
The authors note the situation has been improving since 2025. That improvement is real, but it is backward-looking for anyone holding a historical dataset. The multi-year NVD dumps that researchers train on still encode the old inconsistency, because historical records are not retroactively rescored. A model trained on 2018 through 2024 NVD data carries that period’s divergence forward into every prediction it makes today, regardless of how clean 2026 scoring becomes.
Will FIRST and the CVSS SIG fix this?
The standardization path runs through the CVSS Special Interest Group at FIRST, the body that maintains and evolves the CVSS standard, and the authors presented their findings there as part of the qualitative study. The paper’s framing suggests the productive fixes are not all located at the CNA level. Some divergence requires industry-wide changes to how CVEs are generated. Some requires the CVSS SIG to publish additional FAQs that resolve the under-specified cases CNAs currently resolve differently by default.
| Divergence type | What it means | Where the fix lives |
|---|---|---|
| Human error | An analyst scored inconsistently | Individual CNA process |
| Defensible divergence | The CNA had non-public info justifying a different score | No fix; better disclosure |
| Standard gap | The CVSS FAQ is under-specified, CNAs resolve it differently | CVSS SIG at FIRST |
That table is the realistic prognosis in compressed form. The federation is permanent; CNAs are not going away, and nobody seriously proposes returning to NVD as a single bottleneck. The remaining work is narrowing the interpretive gap between authorities, and that work is slow, consensus-driven, and measured in FAQ revisions rather than architectural rewrites.
For now the operating assumption has to change. A CVE is not a fact about the world with one correct score. It is a record produced by a specific authority under specific interpretive rules, and those rules vary in ways the paper has now measured. Any pipeline that forgets this is carrying the cathedral’s assumptions into the bazaar, and the bazaar will charge for the difference.
Frequently Asked Questions
Does this inconsistency affect every CVE, or only records assigned after the federation expanded?
The worst divergence sits in historical multi-year NVD and CNA dumps, especially pre-2025 data. Scoring has improved since 2025, so a fresh vendor CNA record can be internally consistent, yet a model trained on 2018-2024 data still carries old divergence forward. Also note that the 40% accuracy drop is a worst-case ceiling from the abstract; the paper does not specify the exact benchmark dataset or model architecture there, so teams should read the methodology before treating it as an average.
How is a vendor CNA record different from an NVD record for the same CVE?
A vendor CNA often publishes before NVD finishes enrichment and may hold non-public reproduction details or embargo context that justify a different Attack Complexity or Impact rating. Vendor records can also add or omit CWEs that NVD later assigns. That means a pipeline that fetches only NVD lags behind the advisory chain and may miss the most current interpretation.
What is the minimum change a triage pipeline needs to avoid the 40% accuracy cliff?
Stop merging CVE records into a single row. Stamp every record with its CNA, fetch timestamp, and source URL, then validate the model on at least one held-out CNA before production. The cost floor is not a code patch; it is a schema and lineage change that turns one advisory fetch into a multi-source reconciliation job.
What is the biggest hidden failure mode when an agent fetches a CVE?
The agent returns a confident-looking score instead of an error, and if it does not record which CNA produced the vector, the wrong score gets baked into exploit-path analysis. Because the paper documents same-authority self-divergence, even two fetches from one CNA weeks apart can differ, so caching without a fetch date is a silent correctness bug.
What would force the community to reconsider the federation model?
A regulatory SBOM or vulnerability-disclosure mandate that requires a single authoritative severity per component could make downstream reconciliation costs politically visible. Until then, the federation stays permanent and fixes will come through slow, consensus-driven CVSS SIG FAQ revisions rather than a return to a central NVD bottleneck.
