After the NVD Shift: Building a Multi-Source Vulnerability Intelligence Stack

For more than a decade, most vulnerability programs quietly relied on one assumption: every CVE would eventually show up in the U.S. National Vulnerability Database with a CVSS score and a list of affected products (CPE entries), and scanners would use that data to tell you what to patch. In 2026 that assumption broke. CVE volumes are rising faster than any single public body can analyze, NIST has formally narrowed what it enriches, and the governance of the CVE Program itself went through a near-death experience. This article explains what changed, why it matters for anyone responsible for finding vulnerabilities in their estate, and how to build a vulnerability intelligence stack that does not depend on a single feed.

What Changed: Three Shocks in Eighteen Months

1. The CVE Program funding scare

In April 2025, MITRE warned the CVE Board that its federal contract to operate the CVE Program was about to expire. CISA exercised an option period at the last minute, buying an 11-month extension to March 2026, and several board members launched the nonprofit CVE Foundation to reduce dependence on a single government sponsor. According to Le Monde Informatique, the board was told in January 2026 that there would be no interruption in March, and the program reportedly moved to a protected line in CISA’s budget. That is good news, but the episode showed that the identifier system the whole industry depends on has a thin institutional base, and contract terms remain largely undisclosed even to board members.

2. NIST stops enriching everything

Effective April 15, 2026, NIST changed how it operates the NVD. It now prioritizes enrichment for three groups of CVEs: those in CISA’s Known Exploited Vulnerabilities (KEV) catalog, with a goal of one business day; those affecting software used in the federal government; and those affecting “critical software” as defined under Executive Order 14028. Everything else still appears in the NVD but is labeled as lowest priority and not scheduled for immediate enrichment. Backlogged CVEs published before March 1, 2026 moved into a “Not Scheduled” category, and NIST no longer routinely adds its own severity score when the CVE Numbering Authority (CNA) has already provided one.

NIST was candid about the reason. It reports that CVE submissions grew 263% between 2020 and 2025 and that it enriched nearly 42,000 CVEs in 2025, more than in any previous year, yet still could not keep up.

3. Volumes accelerate, partly because of AI

In February 2026 FIRST forecast a median of roughly 59,000 CVEs for the year; in June it raised the forecast to about 66,000, noting that disclosures through April were running well above its earlier model. FIRST attributed part of the increase to AI-assisted discovery, citing a sharp rise in disclosures from the Mozilla CNA tied to AI tooling, alongside growth in GitHub Security Advisories and in activity from newer CNAs. Crucially, FIRST stressed that the subset of vulnerabilities posing immediate risk, measured by KEV listings and high EPSS scores, has not grown nearly as fast.

More CVEs do not mean more risk. They mean more noise around the same small set of vulnerabilities that attackers actually use, and a program built on a single enrichment feed will miss some of them.

Why This Matters for Vulnerability Identification

The NVD change is not a cosmetic policy update. Many tools quietly depend on NVD-derived data, and the Cloud Security Alliance has pointed out several concrete failure modes:

• Silent misses in scanners. Tools that match installed software to vulnerabilities using only NVD CPE data cannot match an unenriched CVE to a product, so no finding is raised. The asset looks clean when it is not.
• Broken prioritization. Risk and patch management platforms that sort by NVD CVSS scores will treat unscored CVEs as unknown or low, pushing them to the bottom of the queue.
• Downstream contamination. SIEM rules, zero trust posture checks and compliance attestations that consume scanner output inherit the same gaps, sometimes granting access to devices that are actually vulnerable.
• Divergent scores. CNA-supplied CVSS scores and historical NIST scores can differ significantly, so the same CVE may be “high” in one tool and “critical” in another.
• Blind spots in AI and open source stacks. Libraries such as machine learning frameworks are unlikely to meet NIST’s priority criteria, yet they sit at the core of many modern applications.

At the same time, the time between disclosure and exploitation keeps shrinking. Trend Micro’s mid-2026 analysis notes that exploitation increasingly begins before a patch is public and that CISA has moved from a flat KEV remediation deadline toward a risk-based model that can require action within days. A program that waits for complete metadata before acting will be late.

The New Reality: The NVD Is One Input, Not the Answer

The practical response is to stop treating any single catalog as the source of truth and to design for gaps. A modern vulnerability intelligence stack has four layers, each answering a different question:

1. Identity: “Which vulnerability is this?” The CVE identifier remains the lingua franca. Add aliases from OSV, GitHub Security Advisories (GHSA) and vendor advisory IDs so that the same flaw is not counted or missed twice. In Europe, the EU Vulnerability Database (EUVD) operated by ENISA under the NIS2 Directive adds another reference point and its own identifiers, while incorporating CVE data.
2. Applicability: “Does it affect anything we run?” This is where NVD CPE data used to do most of the work. Replace or supplement it with package-ecosystem data (OSV, GHSA), vendor advisories and CSAF documents, commercial enrichment feeds, and, most importantly, your own software bill of materials (SBOM) and asset inventory.
3. Threat: “Is anyone exploiting it?” CISA KEV is the sharpest filter for confirmed exploitation. FIRST’s EPSS provides a daily probability of exploitation for the long tail. Threat intelligence from your security vendors and ISACs fills in campaign context.
4. Impact: “How bad would it be here?” Only you can answer this: asset criticality, internet exposure, compensating controls, data sensitivity and the business process the system supports.

The NVD still contributes to layers one and two for high-risk CVEs, and that coverage is valuable. But layers three and four were never the NVD’s job, and they are where most prioritization value now lies.

A Step-by-Step Playbook for the Next 90 Days

Days 1–30: Find out where you depend on the NVD

1. Inventory every tool in the vulnerability pipeline: network and agent scanners, container and cloud scanners, software composition analysis (SCA), CNAPP, patch management, ticketing and dashboards.
2. For each, document where CVE-to-product matching and severity scores come from. Ask vendors directly how they handle CVEs marked “Not Scheduled” or “Lowest Priority,” and whether they ingest CNA scores, OSV, GHSA or commercial enrichment.
3. Pull a sample of recent CVEs affecting technologies you know you run and check whether your tools flagged them. Gaps here are your most urgent finding.
4. Identify CVEs that matter to you but are unlikely to receive priority NIST enrichment, such as niche commercial products, open source libraries and AI frameworks, and route them to manual or alternative triage.

Days 31–60: Add exploitation and context signals

1. Make KEV the first gate in every remediation workflow. A KEV listing on an internet-facing or business-critical asset should trigger an expedited process, not a normal patch cycle.
2. Add EPSS as the second gate for everything not in KEV, and pick thresholds deliberately. Many teams combine a threshold with asset exposure rather than using EPSS alone.
3. Feed asset criticality and exposure into scoring. If your CMDB is unreliable, start with a simple tiering: internet-facing, hosts sensitive data, supports revenue-critical processes, everything else.
4. Consider a decision framework such as SSVC (Stakeholder-Specific Vulnerability Categorization), which turns exploitation status, exposure and impact into clear actions such as track, attend or act, instead of arbitrary CVSS cut-offs.

Days 61–90: Make it resilient and measurable

1. Generate and store SBOMs for the applications you build and request them from key suppliers. SBOMs let you answer “are we affected?” from your own data when public enrichment is missing.
2. Introduce a supplementary enrichment source for the ecosystems you depend on most, and make multi-source enrichment an explicit criterion in your next vulnerability management or exposure platform evaluation.
3. Define fallback actions when no fix exists or exploitation outpaces patching: virtual patching via WAF or IPS, configuration hardening, network isolation or temporary service shutdown.
4. Change what you report. Replace raw CVE counts with metrics such as mean time to remediate KEV-listed vulnerabilities on critical assets, percentage of crown-jewel assets with current SBOMs, and exposure trend by business unit.

Decision Criteria: Choosing and Tuning Your Data Sources

Not every organization needs every feed. Use the following questions to decide where to invest:

• What does your estate actually look like? A software company with large dependency trees benefits most from OSV and GHSA; an enterprise with heavy commercial software benefits from vendor advisories, CSAF and commercial CPE enrichment; an industrial operator needs ICS advisories and OT-aware tools.
• Where are you regulated? Organizations in scope for NIS2 or the EU Cyber Resilience Act should track EUVD alongside CVE, because European authorities will reference it. U.S. federal suppliers should track KEV deadlines closely.
• How fast can you act? If your patch cycle is monthly, more feeds will not help until you have an expedited lane for exploited vulnerabilities.
• How will conflicts be resolved? Decide in advance which source wins when CNA, vendor and third-party scores disagree. A common rule is vendor or CNA data for applicability, KEV and EPSS for threat, and internal context for impact.
• Can the data flow automatically? Manual cross-referencing does not scale to 60,000+ CVEs a year. Favor sources with stable APIs and machine-readable formats.

A Worked Example: One Week of New CVEs

Consider a mid-sized software company running a SaaS platform on Kubernetes in a public cloud, with a few hundred employee laptops and a handful of on-premises systems. In one week, roughly a thousand new CVEs are published, consistent with the annual volumes FIRST forecasts.

Under the old model, the team waited for NVD scores, filtered for CVSS 9.0 and above, and opened tickets. Under the multi-source model, the pipeline works differently:

1. The SCA tool, fed by OSV and GHSA, matches 40 of the new CVEs to libraries in the company’s SBOMs, including several that the NVD has marked as not scheduled for enrichment. The old process would never have seen them.
2. The infrastructure scanners, which ingest vendor advisories and CNA data, match another 25 CVEs to operating systems, container base images and network appliances.
3. One CVE affecting the company’s VPN appliance appears in KEV mid-week. Because the appliance is internet-facing, the expedited lane triggers: the vendor’s mitigation is applied within hours and the patch follows within a day.
4. Of the remaining 64 matches, EPSS and exposure data push eight into the “attend” category for remediation within the sprint. The rest are tracked and bundled into regular maintenance.
5. Three relevant CVEs have no fix yet. The team applies WAF rules for the two web-facing ones and restricts network access to the third, documenting the compensating controls.

The result is fewer urgent tickets than the old CVSS-threshold approach, but better coverage of the issues that matter, including ones the NVD will never enrich.

Common Pitfalls to Avoid

• Assuming “no finding” means “not vulnerable.” Absence of a match may simply mean absence of enrichment. Validate coverage regularly with known test cases.
• Replacing one single source with another. Swapping NVD for a single commercial feed recreates the same fragility. Diversity is the point.
• Over-trusting EPSS for your environment. EPSS estimates exploitation in the wild in general, not the likelihood that your specific asset is attacked. Combine it with exposure.
• Ignoring non-CVE exposures. Misconfigurations, leaked credentials, excessive permissions and unmanaged assets often matter more than the latest CVE and never receive an identifier.
• Reporting volume as progress. Boards hearing “we closed 12,000 vulnerabilities” learn nothing about risk. Report exposure of critical assets and speed on exploited issues instead.

Outlook: What to Expect in 2027

Several trends look durable. CVE volumes will keep rising as AI-assisted discovery spreads among researchers, vendors and attackers alike; FIRST’s mid-year revision suggests forecasting models are still catching up. NIST has said it is building automated systems for long-term sustainability, so NVD coverage may improve, but organizations should plan as if selective enrichment is permanent. The EUVD will mature as NIS2 and the Cyber Resilience Act raise expectations for vulnerability handling in Europe, which may give multinational organizations two partially overlapping reference catalogs to reconcile. And vulnerability identification will continue to converge with broader exposure management, where CVEs are one signal among identity, configuration and attack path data.

The organizations that cope best will treat vulnerability intelligence like any other critical data pipeline: multiple sources, clear lineage, quality checks, and a defined owner.

Conclusion

The NVD did not fail; it was asked to do an impossible job as CVE volumes multiplied. NIST’s April 2026 changes simply made the limits official. For security teams, the lesson is to move from a catalog-driven to a context-driven program: use CVE identifiers as the common language, pull applicability from several sources including your own SBOMs, gate remediation on real exploitation signals, and weigh everything against business impact. Start by auditing where your tools silently depend on NVD data, close the most dangerous gaps, and build an expedited lane for exploited vulnerabilities. That work pays off regardless of what happens to any single database next year.

How Hanoi Technology Can Help

Hanoi Technology helps teams audit their vulnerability toolchain, integrate KEV, EPSS, SBOM and multi-source enrichment, and run vulnerability identification as a project, dedicated team or managed service.

• Vulnerability Identification
• Cyber Threat Detection
• Cyber Protection
• Security Services

Further Reading

• NIST Updates NVD Operations to Address Record CVE Growth – NIST
• NVD Enrichment Triage: Enterprise Vulnerability Programs Must Adapt – Cloud Security Alliance
• FIRST Raises 2026 Vulnerability Forecast to 66,000 CVEs – SecurityBrief
• Making Sense of the Vulnpocalypse – Trend Micro
• Le financement du programme CVE finalement pérennisé – Le Monde Informatique
• ENISA Launches European Vulnerability Database – SecurityWeek