Your Vulnerability Gate Is Quietly Failing Open

Somewhere in your repository there is a line of configuration nobody has read in two years — a --severity HIGH,CRITICAL flag, a Dependabot threshold, a policy file that blocks a merge when a transitive dependency crosses CVSS 7.0. That line encodes an assumption about the outside world that stopped being reliably true in April 2026, and the backstory matters before you touch it: the shared naming system your entire toolchain gates on came within hours of going dark, as this reconstruction of how the world nearly lost its only shared catalog of software flaws documents in uncomfortable detail, and while the identifiers themselves survived the funding scare, the free enrichment layer that made those identifiers machine-actionable did not survive intact. The CVE ID is still there. The severity score bolted onto it increasingly is not.

The Number You Gate On Has an Owner

Almost every developer-facing scanner — Trivy, Grype, npm audit, Snyk's free tier, your registry's built-in checker — resolves a CVE ID into a severity by asking someone else. Historically that someone was the National Vulnerability Database, which took the raw record a CVE Numbering Authority published and added the parts machines need: a CVSS vector, a CWE classification, and CPE strings describing which product versions are actually affected.

That arrangement broke under arithmetic. NIST spelled it out plainly when it announced the new prioritisation model: CVE submissions grew 263% between 2020 and 2025, and the analysis capacity behind the database never grew to match. The fix was triage rather than expansion. Every unenriched record published before March 1, 2026 was moved into a status called Not Scheduled — roughly 29,000 of them by most counts — and going forward only vulnerabilities that intersect a narrow set of criteria get full treatment. NIST published the new criteria in its own operations notice, and the shape of them is worth internalising: known exploitation, software the US federal government runs, and critical software as defined by Executive Order 14028. Independent estimates put the share of incoming CVEs that will clear that bar at somewhere between 15% and 20%.

The volume side of the equation is not slowing down either. The CVE program published 48,185 records in 2025, up 20.6% on the 40,009 published in 2024, with 484 numbering authorities feeding the pipeline as of January 2026 and first-quarter 2026 submissions running roughly a third ahead of the year before. FIRST forecast another record year. Whatever your scanner does with an unenriched record, it is going to be doing it a lot.

Fail Open, Fail Closed, or Fail Silently

Here is the concrete failure mode. A CVE lands with no NVD-supplied CVSS vector. Your scanner asks for a severity and gets nothing back. What happens next depends entirely on implementation details you almost certainly never audited.

Some tools fall back to a severity supplied by the CNA at publication time, which is often present and often disagrees with what NVD would have assigned. Some fall back to an ecosystem source like the GitHub Advisory Database, which curates its own severities and covers open-source packages well but hardware and enterprise appliances poorly. Some simply emit UNKNOWN. And a gate configured as "block if severity is HIGH or CRITICAL" treats UNKNOWN as not high — which means the build goes green and the merge lands. That is failing open, and it is failing open silently, which is the worst variant because nothing in your logs looks wrong.

The inverse configuration is not better. Teams that flip to "block on anything unresolved" discover their pipeline red-lining on hundreds of records with no context attached, and within about two sprints somebody adds a blanket ignore rule that never gets removed. Alert fatigue is not a personality flaw; it is the predictable output of a gate that cannot distinguish signal from absence of data.

Rewire Around Exploitation, Not Around Severity

The useful correction is not finding a replacement severity feed. It is admitting that a static base score was always a weak proxy for "should this block my release," and replacing it with signals that answer the question directly.

• Make known exploitation a hard gate. CISA's Known Exploited Vulnerabilities catalog lists flaws with confirmed in-the-wild abuse, ships as CSV and JSON, and was reaffirmed as the anchor for federal patching timelines under Binding Operational Directive 26-04 in June 2026. It is small, it is free, and a hit on it justifies waking someone up.
• Add EPSS as a soft gate. The Exploit Prediction Scoring System publishes daily probabilities that a given CVE will be exploited in the next 30 days. FIRST's own analysis puts the share of published vulnerabilities ever exploited at roughly 2–7%, so an EPSS threshold cuts triage volume by an order of magnitude without discarding much real risk.
• Treat missing severity as its own state. UNKNOWN is not zero and it is not critical. Route it to a review queue with a service-level target rather than letting a boolean comparison decide.
• Prefer package-level data for package-level problems. OSV records express affected version ranges per ecosystem, which is the question a lockfile actually poses. CPE strings were designed for enterprise asset inventories and map onto package.json badly.
• Record which source produced each verdict. When a build fails, the log should say whether the score came from a CNA, from NVD, from an ecosystem advisory, or from a fallback default. Without that, you cannot debug the gate at all.

Fragmentation Is Now Your Problem Too

The redundancy built after the 2025 scare is genuine progress and it also generates work. ENISA's European Union Vulnerability Database went live in May 2025 and assigns its own EUVD identifiers on top of CVE IDs, built on CSAF and driven partly by Cyber Resilience Act obligations. CIRCL's Global CVE system opened to the public in January 2026 with a federated model where numbering authorities issue identifiers without waiting on central approval. CISA's Vulnrichment effort distributes enrichment across authorised data publishers. GitHub keeps its GHSA namespace.

None of these replace CVE. All of them mean the same defect can now appear in four catalogs, at four different times, carrying four different severity judgements and four different claims about which versions are affected. If your tooling ingests more than one source — and increasingly it will, whether or not you chose that — you need a canonical identifier map and an explicit precedence rule for conflicts. Otherwise you get duplicate findings, contradictory dashboards, and engineers who learn to distrust the scanner entirely.

What Actually Changed

For twenty-five years, vulnerability triage was something a developer could outsource to a public good. A free service turned an identifier into a decision, and CI configs were written on the quiet assumption that the service would always be there and always be complete. Both halves of that assumption are now formally retired — not by a catastrophe, but by a published policy change from the organisation that maintained it, arrived at honestly because the volume made anything else impossible.

The catalog survived. The convenience did not. Prioritisation has moved from an external dependency back into your codebase, where it now belongs. Open the policy file, check what it does when the score is missing, and fix that first.