In February 2024, the National Vulnerability Database effectively stopped functioning. NIST, which operates the NVD, reduced its processing of CVE records to a trickle. By mid-2025, the backlog of unanalyzed CVEs exceeded 18,000. Vulnerabilities were being assigned CVE IDs by MITRE but sitting in the NVD without CVSS scores, CPE data, or reference links for weeks or months.
Then in April 2025, MITRE’s contract to operate the CVE program itself was nearly terminated due to federal funding cuts. The contract was extended at the last moment, but the message was clear: the foundational vulnerability identification system that the entire security industry depends on is one budget decision away from collapse.
I stopped treating CVE as my single source of truth for vulnerability intelligence in early 2025. This is what I use instead.
What broke
The NVD’s value was never just the CVE ID. It was the enrichment. NIST analysts added CVSS scores, mapped CVEs to specific products via CPE strings, categorized the vulnerability type (CWE), and linked to patches and advisories. This enrichment turned a bare identifier into actionable intelligence that vulnerability scanners, patch management tools, and GRC platforms could consume automatically.
When that enrichment pipeline slowed to a crawl, the downstream effects rippled through the entire ecosystem. Vulnerability scanners that depended on NVD data for severity scoring started returning incomplete results. Risk dashboards showed CVEs without CVSS scores. Compliance teams could not map vulnerabilities to affected products. The system did not break visibly. It degraded silently, which is worse.
I noticed it when a client’s vulnerability scan returned a critical finding with no CVSS score. The CVE had been published three weeks earlier. It affected a product the client used. The NVD still had not analyzed it. We had to read the vendor advisory and assess severity manually. That is not scalable.
My current stack
I now cross-reference four sources for vulnerability intelligence. No single source is complete. Together, they cover the gaps.
CVE/NVD. Still the canonical identifier. I use CVE IDs as the common key across all sources. But I no longer wait for the NVD to enrich a CVE before acting on it. If the NVD entry is bare, I look elsewhere.
OSV (Open Source Vulnerabilities). Google’s OSV database focuses on open source vulnerabilities and maps them directly to affected package versions, not CPE strings. When I need to know whether a specific version of a Python or Node.js library is affected, OSV gives me a precise answer faster than the NVD. The osv.dev API is free and well-documented. I integrated it into my CI/CD pipeline for dependency scanning.
GitHub Security Advisories. GitHub’s advisory database is curated and maps vulnerabilities to specific package ecosystems (npm, PyPI, Maven, RubyGems, Go modules). For any project with dependencies in these ecosystems, the GitHub advisory database is more actionable than the NVD because it speaks in package versions, not CPE strings. Dependabot consumes this data automatically, but I also query it manually when triaging vulnerabilities outside of GitHub-hosted projects.
Vendor advisories directly. For commercial software and infrastructure (Cisco, Palo Alto, Fortinet, Microsoft, VMware), I subscribe to the vendor’s security advisory feed and read it before checking the NVD. Vendors publish detailed advisories with affected versions, mitigations, and patches days or weeks before the NVD processes the corresponding CVE. Vendor advisories have always been faster than NVD enrichment, but since the 2024 slowdown the gap has widened from days to weeks or months. I have seen critical CVEs from mid-2024 onward sit in the NVD without a CVSS score for over a month while the vendor advisory included full details and a patch.
The decentralization efforts
In response to the CVE system’s fragility, two parallel efforts emerged in 2025.
The CVE Foundation, formed by CVE Board members after the MITRE funding scare, launched the GCVE (Global CVE) initiative, a decentralized numbering scheme that allows multiple authorities to issue vulnerability identifiers independently without depending on a single point of failure.
Separately, ENISA launched the European Vulnerability Database (EUVD) under NIS2 requirements, providing an EU-specific vulnerability catalog with its own enrichment and severity assessments.
I am watching both with cautious optimism. The decentralized models address the single-point-of-failure problem, but they introduce coordination challenges. Multiple identifiers for the same vulnerability. Conflicting severity assessments. Fragmented tooling support. The CVE system’s strength was always its centralization. These alternatives will need to prove their interoperability.
For now, I track both GCVE and EUVD identifiers when they appear in advisories and maintain a mapping to CVE IDs where both exist.
What this means for vulnerability management
If your vulnerability management program depends entirely on the NVD for severity scoring and product mapping, you have a single point of failure that has already demonstrated it can degrade without warning.
Based on what I have implemented for my own infrastructure and my clients:
Do not wait for CVSS. If a CVE is published without a CVSS score, read the advisory and assess severity yourself. The CVSS calculation is a formula. The inputs are in the advisory description. A missing NVD score is not permission to ignore a vulnerability.
Integrate OSV for open source. If you run applications with open source dependencies, and you do, OSV is more accurate and faster than the NVD for those components. The data format is designed for automated consumption.
Subscribe to vendor advisories. For your critical infrastructure vendors, go to the source. Cisco PSIRT, Microsoft MSRC, Fortinet PSIRT, Palo Alto security advisories. These are published before the NVD processes them. In active exploitation scenarios, hours matter.
Track the CVE funding situation. MITRE’s CVE contract is currently funded. That can change. The security industry’s reliance on a single government-funded program to identify all vulnerabilities globally is a structural risk. GCVE, OSV, and vendor-specific databases are hedges against that risk.
Most organizations treat CVE/NVD as the single authoritative source and build their entire vulnerability management workflow around it. That was reasonable five years ago. It is a liability today.
The mature security programs I work with consume multiple feeds, correlate across sources, and do not wait for a single authority to tell them a vulnerability is severe. They read the advisory. They check the exploit. They make their own call.
The CVE system may recover. The NVD backlog may clear. MITRE’s funding may stabilize. I am not building my security program on “may.” I am building it on multiple sources that function independently.