Your vulnerability scanner quietly switched sources. The NVD isn't the primary feed anymore.

In February 2024, NIST announced reduced partner support for NVD analysis. “Reduced partner support” is government for “the staff who processed CVEs are gone and we don’t have a replacement plan.” The enrichment backlog (CVEs with an ID and a description but no CVSS score, no CWE classification, no CPE name mapping, nothing to tell your scanner what to do with them) grew to thousands within a few months. At the peak, the majority of newly published CVEs were landing in NVD with no analysis at all.

I’ve been running the same patch triage workflow since roughly 2018. CVE comes in, check NVD for the vector string, read the description, assess impact in my environment, decide urgency. That workflow assumed NVD would always have the enrichment. It doesn’t anymore, and hasn’t reliably since 2024. The scanner toolchain noticed and adjusted. I should tell you what it adjusted to.

What NVD was and what it actually provided

The National Vulnerability Database has been the authoritative enrichment layer for CVEs since 1999. MITRE assigns CVE IDs; NVD adds the CVSS scores, weakness classifications (CWE), and Common Platform Enumeration (CPE) mappings that allow scanners to match vulnerabilities to specific software versions.

The problem with this architecture is that it required a team of NIST contractors to process every CVE in sequence. In the early years, the volume was manageable. By 2024, over 28,000 CVEs were published annually and accelerating. When the contractor budget got cut, the queue didn’t shrink on its own.

The result was predictable: tens of thousands of CVEs published with no CVSS scores. Your scanner returning “no known vulnerabilities” for a package was no longer proof that the package had no known vulnerabilities; it might just mean NVD hadn’t gotten to it yet.

The OSV migration the ecosystem made without a press release

The Open Source Vulnerability format (OSV) launched in 2021 as a Google project for machine-readable vulnerability data. The schema is simple: a JSON format with affected ranges, fixed versions, and IDs that map to CVEs, GitHub Security Advisories, and vendor-specific identifiers. The canonical public database lives at osv.dev.

When NVD stalled, OSV already had years of momentum. The GitHub Advisory Database (which covers npm, PyPI, RubyGems, Go, Maven, Rust, NuGet, and more) follows the OSV schema and is maintained by people who understand the packages, not by federal contractors working through a generic queue. osv.dev aggregates from GHSA plus Linux distro advisories (Debian Security Tracker, Alpine SecDB, Ubuntu USN) and a growing list of ecosystem-specific sources.

Grype, Trivy, and Google’s own osv-scanner use OSV-format data as primary. The migration happened through individual scanners switching defaults, with no coordinated announcement, no migration guide. You woke up one Tuesday and your tool was pulling from a different upstream. Probably a better one.

Check what your scanner actually queries. grype --db-repository and Trivy’s --db flags tell you the source. For osv-scanner, --config makes it explicit. The behavior is usually correct. The issue is assuming NVD is still the oracle when it’s been a secondary-or-worse source for a couple of years now.

CVSS 4.0 changes the numbers under your threshold rules

FIRST published CVSS 4.0 in November 2023. It has been rolling into scanner defaults since 2024. Three changes that actually matter for patching workflows:

Threat is now in the Base Score. CVSS 3.x had Exploit Code Maturity in the Temporal Score, which was a separate optional field that most people didn’t populate. CVSS 4.0 folds Threat into the primary scoring equation. A CVE with no known exploits scores lower than an identical one with a public PoC, under the same base metric inputs. This is correct behavior: a theoretical remote code execution is different from one being actively used, and 3.x had no good way to express it without manual enrichment.

The vector string is longer. CVSS 4.0 adds Supplemental metrics and separates some existing metrics. The full vector string for a fully-enriched 4.0 entry looks intimidating. In practice, the fields you care about most (AV, AC, PR, UI) are still the same shape; the new fields add precision without changing the core read.

The severity labels map differently. Critical/High/Medium/Low thresholds shifted from 3.x. If your compliance tooling has numeric cutoffs baked in, like “page if CVSS ≥ 9.0,” verify those thresholds against the 4.0 specification, because the same vulnerability can land in a different bucket depending on which version is being used to score it. Check which version your scanner sources carry. A mixed environment of 3.x and 4.0 enrichment is common right now and the numbers don’t stack neatly.

What is actually better about the new model

I do not say this lightly: the decentralized enrichment model is an improvement.

NVD’s enrichment was only as fast as one contractor team working a queue. CNA-enriched CVEs, published and scored by the organization that actually owns and understands the affected software, arrive with better technical descriptions and faster CVSS analysis than the NVD backlog model ever provided for high-volume ecosystems.

The GitHub Advisory Database for npm vulnerabilities is enriched by people who work on npm. The Rust advisory database (RustSec) is maintained by the security team that actually knows the crate ecosystem. The latency from “vulnerability disclosed” to “scanner flags it” has dropped meaningfully for open source packages precisely because the people closest to the code are now the enrichment source, not a downstream federal process.

NVD still exists and still matters for enterprise software CVEs where there’s no CNA with clear ownership. It still has the longest historical record. It isn’t going away. But it’s not the primary feed anymore and hasn’t been for a while.

Know what your scanners are actually pulling. The old mental model (one authoritative source, CVSS score attached, triage from there) hasn’t been accurate since the backlog hit. The new model is more distributed, faster for open source, and better aligned with how software is actually developed and maintained.

The infrastructure evolved. Catch up.

See also: Everything is a critical CVE now, which means nothing is for the adjacent problem of what to do with CVSS numbers once you have them, and Package registry typosquatting wave for the supply-chain context that makes getting vulnerability data right matter even more.