The CVE & NVD Crisis: A Wake-Up Call for Cybersecurity Industry andApplication Security

Not to be overdramatic, but..CVE and NVD seem to be in trouble…

The lights are dimming on one of the most trusted cornerstones of cybersecurity. On April 16, 2025, MITRE’s funding for the Common Vulnerabilities and Exposures (CVE) program, a backbone part of the National Vulnerability Database (NVD) process, will expire, disrupting a system that has quietly underpinned the entire vulnerability management ecosystem for over two decades. This isn’t just a budget line item for developers, CISOs, and remediation engineers alike. It’s a destabilizing shift with sweeping consequences across the entire software supply chain.

We set up a Slack channel to discuss those vulnerabilities and the consequences of the dramatic turn of events and track the possibility of resurrecting projects like OSVDB.

Gone—or at least severely slowed—are the days of consistent, centralized, and machine-readable vulnerability records that tools like Semgrep, Snyk, and others used to correlate code with exploitable flaws. The ripple effects? Delayed vulnerability declaration and confusion with more vulnerability scanners having their own database. Consequences? Blind spots in threat prioritization. There is also a growing disconnect between DevSecOps and real-time application security posture management (ASPM).

Update 16 April 11 am GMT

Latest Update: The CVE Foundation is possibly stepping in

The News about MITRE and NVD challenges

In a stunning disruption of global vulnerability management, nonprofit R&D giant MITRE confirmed that its contract with the Department of Homeland Security (DHS) to operate the Common Vulnerabilities and Exposures (CVE®) program has expired—leaving the 25-year-old system without funding, oversight, or an active publishing mechanism.

Timeline of Events

• Spring 2024 – NIST begins falling behind on CVE ingestion, sparking concern across the security community.
• October 2024 – CVE submissions spike by 32%, overwhelming the National Vulnerability Database (NVD).
• February 2025 – Early reports emerge that MITRE’s CVE contract is at risk of non-renewal.
• March 2025 – MITRE initiates layoffs; over 400 staff are impacted.
• April 10, 2025 – MITRE publicly confirms its funding for CVE and CWE will expire on April 16.
• April 16, 2025 – Midnight – The CVE program officially halts operations. MITRE stops issuing new CVEs
• April 16, 2025 – CVE Fundation possibly stepping in

Why CVE and NVD Matter—And What Happens Without Them

The value of the CVE program wasn’t just in assigning a number. It was creating a central and trusted, up to a certain degree, trust center for vulnerability:

• Timelines: CVEs offered public timestamps for when flaws were discovered, acknowledged, and patched.
• Cross-vendor intelligence: One identifier linked proof-of-concepts, vendor advisories, and threat feeds.
• Automation: Tools parsed CVE data to auto-enrich alerts and drive ticketing workflows.

Now, with CVE processing fragmented and NVD data bottlenecked by legacy ingestion workflows, organizations are left in limbo. The absence of centralized, authoritative records slows threat modeling, disrupts software bill-of-materials (SBOM) tracking, and breaks automation pipelines across DevSecOps tooling.

Security teams accustomed to daily triage via CVSS scores and CVE IDs are now turning to platform-native intelligence like Phoenix Security’s remediation engine to replace lagging upstream sources with faster, context-rich correlations.

What is the Impact

Former CVE board member Brian Martin outlined a multi-level impact:

1. CNAs (CVE Numbering Authorities) can no longer efficiently assign IDs.
2. The already-overwhelmed NVD (with 30,000+ backlogged vulnerabilities) loses its authoritative source of new CVEs.
3. Commercial databases that rely on MITRE’s CVE program will face severe intelligence gaps.
4. International vulnerability exchanges, including in Russia and China, will be cut off from consistent CVE data.
5. Thousands of CERTs and security teams globally will lose a free, reliable source of vulnerability intelligence.

Correlation Engines Step Up: Phoenix Security’s Role in the New Vulnerability Landscape

The degradation of NVD and CVE’s infrastructure creates a vacuum that Phoenix Security’s Code-to-Cloud Correlation Engine is designed to fill. As a forward-leaning ASPM solution, Phoenix doesn’t just wait for vulnerability records to trickle through broken pipelines. It maps, contextualizes, and correlates across source code, CI/CD systems, container environments, and cloud infrastructure.

With the new threat-centric approach, we also aim to be independent from pure CVE. With the Phoenix Security intel, we are looking to add an alternative source of vulnerability intelligence. Whilst this will not fit the gap

Rather than relying solely on CVEs, Phoenix weaves in enriched threat intelligence, exploitability data, and business context to give remediation teams actionable visibility—even in a post-CVE world. Its correlation engine uses real-time telemetry and advanced rule sets to track vulnerabilities at every stage of the SDLC, from semgrep findings in code to runtime signals from container orchestrators.

🔒 How Phoenix Security Is Already Positioned to Address the CVE Crisis

While the expiration of MITRE’s CVE program has exposed systemic fragility in vulnerability tracking, Phoenix Security is already architected to operate beyond those limitations.

📚 A Self-Sustaining Vulnerability Intelligence Engine

Phoenix doesn’t depend solely on centralized databases like NVD or the now-defunded CVE issuance pipeline. Instead, it maintains its own internal vulnerability database, designed to deliver structured, actionable, and timely intelligence.

While this internal system does not replace the CVE issuance process, it mitigates risk from upstream data delays by functioning as a live, continuously enriched repository—capable of absorbing and normalizing data from multiple authoritative sources.

🔁 Multi-Source Synchronization

Phoenix Security synchronizes with a broad range of vulnerability data feeds and declaration platforms, including:

• VulnCheck – A CNA proactively issuing CVEs in response to MITRE’s shutdown
• OSV.dev – Google’s open-source vulnerability database
• GitHub Security Advisories – An increasingly vital source of developer-facing disclosures
• Other CNA and ADP feeds – For redundancy and diversity in intelligence

This federated approach enables Phoenix to cross-validate findings, reduce false negatives, and ensure continuity in threat visibility, even when a primary data source like NVD goes offline.

🧠 Proprietary Threat Intelligence & Discovery

Phoenix also leverages its own threat intelligence sources and discovery mechanisms to identify and track vulnerabilities beyond public disclosures. This includes:

• Consistently scraping the web for intelligence sources
• Clear and Gray web and exploit monitoring
• Zero-day tracking through research and prediction analysis
• Custom rulesets for vulnerability inference in cloud and containerized environments

The result is an intelligence system that’s not only reactive to disclosures, but also proactive in surfacing emerging threats—long before they’re officially assigned CVEs.

🎯 Enrichment with a Threat-Centric Lens

Beyond ingesting vulnerabilities, Phoenix applies deep enrichment using:

• Exploit availability & weaponization signals
• Business impact modeling
• Exposure and reachability data from the runtime environment

This threat-centric prioritization ensures that security teams focus on the vulnerabilities that matter most—based on actual exploitability and the potential blast radius in their specific infrastructure.

From Database Dependency to Correlation-First Security

The CVE shutdown isn’t a temporary hiccup. It’s a signal that the industry’s reliance on static vulnerability records—often weeks delayed and semantically thin—was always a brittle foundation. In the face of CNAs struggling to assign CVEs and NIST’s backlog swelling under submission overload, the future of vulnerability management must evolve.

Phoenix Security is already operating in that future with own vulnerability database and enrichment as many others in the industry have. the challenge would be having a central authority track and declare vulnerabilities.

By the Numbers: Why Running a Vulnerability Database Is More Than Just Ingestion

One of the most overlooked challenges in running a CVE-style vulnerability database isn’t just ingesting new records—it’s processing, analyzing, and enriching them consistently and at scale.

The latest data from the NVD makes this painfully clear:

Even though the NVD received 14,220 new CVEs in 2025 so far, only 11,352 have been fully analyzed—a 20% gap, and it’s widening each month.

🔍 CVE Status Breakdown (April 16, 2025):

• Total CVEs in database: 290,108
• Awaiting Analysis: 24,461
• Undergoing Analysis: 8,371
• Deferred (not to be analyzed): 80,000
• Rejected: 15,013
• Received but not yet published: 188

The Vulnrichment initiative was aiming to address the gap but with the 80-90K deferred the gap became even more painfully so for a full analysis check out this article

Here are three visual charts that highlight the key trends and challenges in CVE data management:

1. New CVEs Received vs Analyzed Over Time – This shows the growing gap between submissions and processing.
2. CVE Status Breakdown – A clear view of how many CVEs are in limbo (awaiting, undergoing analysis, or deferred).
3. Modified CVEs Re-analyzed – Illustrates the limited effort allocated to reprocessing modified vulnerabilities.

Would you like these formatted into an infographic, a slide deck, or added into your upcoming report? 

Combined, over 112,800 CVEs are either awaiting, undergoing, or have been deferred from full analysis—a staggering 39% of the total database.

🧠 Alternative Method: Running an Open Source Vulnerability Database

The conversation explored the feasibility and implications of transforming the National Vulnerability Database (NVD) or a similar vulnerability tracking system into an open source or consortium-led model, particularly in light of the CVE program shutdown.

Key elements of the method discussed:

1. Consortium Model

• A community-driven consortium (akin to a nonprofit or foundation) was proposed as a potential way forward to maintain the NVD-like service.
• Such a model would shift vulnerability ingestion, enrichment, and CVE tracking from a federally funded, centralized MITRE model to a shared responsibility model governed by multiple stakeholders.

2. Open Ingestion and API Model

• The technical core would remain the same: a database with ingestion workflows and public APIs, much like current NVD or MITRE implementations.
• The challenge lies in ownership and authority—who controls data quality, who issues or updates records (CVE IDs, CPEs), and how enrichment happens without introducing legal liability.

3. Role of CNAs and ADPs

• CNA (CVE Numbering Authorities) issue CVE records.
• ADPs (Authorized Data Publishers), such as MITRE’s vulnrichment team, enrich these records post-submission but are limited in scope—they can’t modify another CNA’s submission.
• Maintaining a federated structure in an open source model would require replicating this tiered access and permissions logic—which is not trivial and demands strong governance.

⚠️ Consequences of Running a Vulnerability Database Openly

✅ Potential Benefits:

• Community ownership: Reduces dependency on one entity (like MITRE or DHS).
• Resilience: More distributed control can improve availability and scalability.
• Innovation: Faster adoption of improvements like AI-driven enrichment, SBOM ingestion, etc.

❌ Critical Risks:

• Governance complexity: Legal ownership, authority, and liability issues are non-trivial.
• Data integrity: Without centralized oversight, quality and consistency may degrade.
• Operational bottlenecks: Contributor models require curation and strict access controls.
• Legal risk: Even with disclaimers (“we are not responsible for data quality”), open-source projects could still face reputational or even legal challenges.

Some of the operational challenges

• Handle over 4,000 CVEs/month at scale
• Recruit and train analysts (or build automation) for triage and tagging
• Offer API support, metadata quality, and CPE mappings
• Establish clear access controls (like CNAs and ADPs) to manage submissions and updates

What Comes Next?

While MITRE’s historical CVE data will remain accessible via GitHub, and CNAs may continue issuing identifiers in isolation, the era of unified vulnerability intelligence is behind us.

This crisis doesn’t just affect vulnerability researchers. It impacts everyone building, deploying, or defending software. The good news? Tools like Phoenix Security are already adapting, already correlating, and already pushing vulnerability management into its next generation—one where remediation speed, context-aware prioritization, and cross-layer visibility define resilience.

At Phoenix Security we stood up our own threat intelligence and vulnerability database. whilst fetching from NVD we secure different sources

How Phoenix Security Can Help

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis and innovative Threat Centric approach . This innovative approach correlates runtime data with code analysis and leverages the threats that are more likely to lead to zero day attacks and ransomware to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.

Bonus for the curious how the CNA process works

🧩 How a Vulnerability Disclosure Becomes a Security Finding

Credit to James Berthoty for putting this together

Step 1: Vulnerability Discovered & Disclosed

The process begins when a researcher, vendor, or developer discovers a vulnerability. This could happen:

• In-house (internal QA or pentesting),
• Through coordinated disclosure (bug bounty, third-party researcher),
• Or via threat intel (exploits spotted in the wild).

Step 2: CVE Assignment & Publication by MITRE

MITRE, funded by the Department of Homeland Security (DHS), was historically the root authority for issuing CVEs.

• MITRE receives the report, validates it, and assigns a CVE ID.
• The entry is published on CVE.org with minimal information (title, product, and metadata).
• This is the step currently at risk due to the loss of funding (highlighted in red: “This could go away”).

⚠️ Without MITRE, no centralized CVE issuance or moderation exists—putting the upstream supply chain in jeopardy.

Step 3: Enrichment by NVD

The National Vulnerability Database (NVD), operated by NIST under the Department of Commerce, then pulls CVEs from CVE.org and enriches them with:

• CVSS scoring
• Affected platforms (CPE)
• Weakness categories (CWE)
• Configuration and mitigation metadata

📉 NVD is already struggling with backlogs and automation limitations and relies heavily on the upstream flow from MITRE. Without new CVEs flowing in, NVD loses relevance rapidly.

Step 4: Enrichment from Third Parties (Optional)

Platforms like VulnCheck act as Authorized Data Publishers (ADPs) or enrichers of vulnerability metadata. These third parties:

• Provide exploit context
• Improve data quality
• Can act independently in CVE assignment (if they are CNAs)

🧩 These players are becoming more important in light of MITRE’s decline.

Step 5: Security Scanners Integrate Findings

Security tooling (e.g., Snyk, Wiz, Palo Alto Networks) pulls from:

• NVD
• CVE.org
• GitHub security advisories
• And sometimes internal databases

They correlate these findings to your actual environments—code, containers, cloud workloads, etc.

Many scanners also:

• Assign their own internal vulnerability IDs
• Act as CNA-authorized publishers themselves

Step 6: KEV Assignment by CISA (Optional)

The Cybersecurity and Infrastructure Security Agency (CISA), also under DHS, publishes the Known Exploited Vulnerabilities (KEV) catalog.

• Not all CVEs make it here—only those with known exploitation in the wild.
• These become high-priority for government and critical infrastructure.

🧠 Key Takeaways

• MITRE’s role is central to validating and publishing CVEs. Its shutdown breaks the pipeline.
• NVD is downstream-dependent and already overburdened.
• Third-party enrichers and CNAs (like VulnCheck, GitHub, and security vendors) may fill some gaps.
• Security tools depend on this data to correlate and triage vulnerabilities.
• The entire system is fragile—and Phoenix Security, with its own correlation engine and threat-driven enrichment, is well-placed to provide resilience