{"slug": "nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence", "title": "NVD in the AI Era: The Case for Multi-Source Vulnerability Intelligence", "summary": "The National Institute of Standards and Technology (NIST) announced on April 15, 2026, that the National Vulnerability Database (NVD) will adopt a risk-based triage model, abandoning universal enrichment of all CVEs due to unsustainable submission volumes. Snyk, a security company, stated it does not rely solely on NVD and will continue using a multi-source intelligence approach, including in-house research, threat intelligence, and AI-assisted human validation, to provide vulnerability data to customers.", "body_md": "# NVD in the AI Era: The Case for Multi-Source Vulnerability Intelligence\n\nJune 25, 2026\n\n0 mins readFor over twenty years, the global security community has operated under a single, comfortable assumption: that a centralized public source could help track, analyze, and enrich the world’s software vulnerabilities at the pace the industry needed.\n\nWhen the [National Vulnerability Database](https://nvd.nist.gov/) (NVD) was established, the open source vulnerability lifecycle moved at a radically different pace. Open source ecosystems were smaller, release cycles were slower, and the volume of publicly disclosed vulnerabilities was easier to manage through centralized enrichment.\n\nBut the modern software ecosystem has officially outgrown that legacy paradigm. [On April 15, 2026](https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth), the National Institute of Standards and Technology (NIST) recalibrated its operational approach, evolving its longstanding mandate for universal vulnerability enrichment. Faced with an unsustainable influx of submissions, the agency announced a prioritized triage model, explicitly stating that full enrichment of every CVE is no longer a realistic goal with current resources.\n\n## How this affects us at Snyk\n\n### General impact: Operating independently\n\nSnyk does not rely solely on the NVD for vulnerability enrichment, so the NIST announcement does not change our approach to vulnerability intelligence. Rather, it reinforces the approach we have taken for years, as we previously explained in [\" How Snyk users avoid NVD delays\"](/blog/snyk-users-dont-have-to-worry-about-nvd-delays/), NVD remains an important source, but it is one part of a broader intelligence ecosystem that includes multiple vulnerability sources, security analyst validation, and open source context.\n\nThat approach helps customers continue making informed prioritization decisions even as public enrichment models evolve.\n\nRather than relying on public-sector validation loops, our data is enriched through multi-layered internal processes. Where applicable, we provide NVD CVSS vectors right alongside our own CVSS assessments to help you understand how a vulnerability is evaluated across different sources. Snyk Intelligence is designed to help customers understand not just whether a CVE exists, but what it means in the context of open source software. It provides critical clarity on which package versions are vulnerable, whether a fix is available, how the risk is assessed across sources, and exactly how to prioritize remediation.\n\nIn addition to collecting vulnerability advisories from a diverse set of sources, Snyk enhances and continually reassesses and updates the security database via:\n\n**In-house security research****Threat intelligence integration:** A range of signals, including exploit activity, social media mentions, and PoC publication**Community contributions:** Responsible disclosures from the open source community, including independent researchers and project maintainers**Academic and research collaborations****Customer-centric prioritization:** Helping customers move from raw vulnerability data to actionable intelligence that supports developer and AppSec prioritization workflows**AI-assisted, human-validated intelligence:** As vulnerability volume grows, Snyk uses AI-assisted workflows and automation to help collect, filter, prioritize, and enrich high-volume vulnerability signals at scale. But automation alone is not enough. Snyk maintains a human-in-the-loop approach, where trained security analysts validate and approve AI-generated suggestions to help ensure customers receive trusted, accurate, and actionable vulnerability intelligence.\n\n## The new era of threat data\n\n### What exactly are the details of this change?\n\nThe NVD has transitioned to a risk-based triage model, moving away from the previous goal of universal, immediate vulnerability enrichment. This structural shift may create significant industry blind spots, particularly for legacy scanners that rely heavily on NVD data for CVSS scores and for enriching software that is no longer deemed a priority. Under this newly implemented approach, the NVD will now prioritize full enrichment for CVEs that meet any of the following criteria:\n\nCVEs appearing in\n\n[CISA's Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)(with a target to enrich these within one business day of receipt).CVEs for software used within the U.S. federal government.\n\nCVEs for\n\n[critical software](https://www.nist.gov/system/files/documents/2026/04/15/EO%2014028%20Critical%20FINAL.pdf)as defined by Executive Order 14028.\n\nAny CVE falling outside these categories is systematically relegated to a \"Lowest Priority - not scheduled for immediate enrichment\" status. To put this coverage gap into perspective, consider the math: while [48,185 unique CVEs were published in 2025 alone](https://jerrygamblin.com/2026/01/01/2025-cve-data-review/), CISA’s Known Exploited Vulnerabilities (KEV) catalog tracks about [245 new](https://cyble.com/blog/cisa-kev-2025-exploited-vulnerabilities-growth/) entries by the end of 2025. For additional context on 2026 vulnerability volume and KEV trends, see [CISA Known Exploited Vulnerabilities Surged 20% in 2025](https://cyble.com/blog/cisa-kev-2025-exploited-vulnerabilities-growth/).\n\nRelying strictly on this public framework means organizations are tuning their scanners to a highly targeted, government-approved list. In doing so, they risk missing critical context on the vast universe of open source packages that, while not currently classified as critical or actively exploited, still form the foundation of modern application security.\n\nFurthermore, a significant portion of historical CVEs published before March 1, 2026, has been categorized under “[Not Scheduled](https://nvd.nist.gov/general/nvd-dashboard#:~:text=1321-,CVE%20Status%20Count,-Total),” and many more have been classified as “Modified After Enrichment,” a state indicating that they will not necessarily be reassessed, as they would have in the old model. This reflects the reclassification of previously backlogged vulnerabilities as part of the updated enrichment model, highlighting the scale of backlog management now embedded into the new approach.\n\nCrucially, NIST has also introduced a significant operational change to how it handles scoring and modifications to reduce duplication of effort:\n\n**Streamlining Severity Scores****:** NIST will no longer routinely provide a separate severity score when the submitting CVE Numbering Authority (CNA) - such as the software vendor or package maintainer - has already supplied one.**Handling of Modified CVEs****:** Rather than reanalyzing all modified CVEs as previously dictated by policy, NIST will now do so only if they is aware of a modification that materially impacts the enrichment data.\n\nThis creates a stronger need for security teams to understand the source and context behind vulnerability enrichment. When NIST does not provide an additional independent severity score, organizations may need to rely more heavily on CNA-provided scoring, vendor-provided metadata, and other enrichment sources. While CNA-provided data is valuable and often comes from maintainers closest to the affected software, it can also introduce differences in scoring methodologies, risk interpretations, disclosure incentives, or operational pressures, such as remediation timelines and SLA expectations.\n\nThat makes source transparency, independent validation, and multi-source vulnerability intelligence more important than ever.\n\n### This was inevitable\n\nThis shift did not happen overnight; it is the culmination of stress on the de facto vulnerability management machinery that was years in the making. When annual CVE submissions surged by [263% from approximately 18,000 entries in 2020](https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth) to more than 48,000 in 2025, the math simply stopped working for the NVD's pipelines. This was due to structural changes to the CVE system, which adopted a federated rather than centralized model of CVE assignment - removing an administrative bottleneck while enabling a far larger and more diverse set of assigners to contribute to the pool of publicly cataloged vulnerabilities. At the same time, AI is forcing a change in the pace of vulnerability research. AI is helping researchers move faster across multiple stages of the research process, from discovery and validation to proof-of-concept creation and reporting. This does not mean every AI-generated report is of high quality, but it does mean the volume and velocity of vulnerability signals are likely to keep increasing.\n\nNIST’s update reflects this reality. Even after enriching nearly [42,000 CVEs in 2025](https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth) - 45% more than any prior year - NIST stated that increased productivity was still not enough to keep up with growing submissions.\n\nThe new risk-based model is intended to help NIST focus on the most critical CVEs while stabilizing the program and developing the automated systems and workflow improvements needed for long-term sustainability. So, although the responsibility for inputting high-quality data into the vulnerability management pipeline is shifted back towards software suppliers and vulnerability reporters, the burden of making sense of it all rests on the end users and the tools they employ.\n\n### Why is this happening now?\n\nThe core catalyst behind this exponential spike in CVEs can be summarized in two letters: **AI**.\n\nAs highlighted in our deep dive on “[Vulnerability Research in the Age of AI](https://labs.snyk.io/resources/AI-vulnerability-research/#the-research-process)”, artificial intelligence has completely rewritten the economics of bug hunting. Automated, AI-driven discovery tools can autonomously analyze codebases, uncover flaws, and generate thousands of raw vulnerability reports in a fraction of the time a human researcher would require to produce the same results.\n\nThis creates a continuous feedback loop where AI detection tools are ramping up and scanning existing codebases comprehensively, introducing an unprecedented volume of data into the vulnerability landscape.\n\nHowever, this volume isn't just an AI story; it is also the result of a massive operational shift in how vulnerabilities are reported. The exponential growth actually started years earlier with the explosion of the federated CVE model. In 2018, the program was decentralized by rapidly expanding its network of CVE Numbering Authorities (CNAs). Where a small handful of organizations used to handle data entry, there are now more than 500 independent CNAs, including software vendors, package maintainers, and cloud providers, all publishing disclosures directly to the global pool simultaneously.\n\nAt Snyk, we see this as part of the reason vulnerability intelligence needs to evolve. The challenge is not merely collecting more data. The real challenge is contextualizing, validating, enriching, and prioritizing that data so security and development teams can focus on the issues that actually matter.\n\n### Quality over noise\n\nSecurity and development teams need vulnerability intelligence they can trust, understand, and act on.\n\nSnyk believes in **precise vulnerability mapping**. Instead of assigning the risk to an entire open source project, Snyk Open Source identifies the specific affected package, vulnerable version range, relevant component, or code path where possible, available fix, and supporting evidence behind the advisory. This helps reduce unnecessary noise and gives developers and remediation agents clearer guidance on what actually needs to be remediated.\n\nAs noted earlier, AI-generated reports can help surface useful leads, but in our experience, they also frequently produce incomplete analysis, duplicated findings, and low-quality signals that require careful validation. We've repeatedly seen vulnerability reports generated with insufficient evidence, unclear impact assessments, or findings that ultimately do not withstand maintainer review. For example, when a vulnerability report is rejected by a project maintainer, Snyk applies additional review before deciding whether and how it should be represented in Snyk’s vulnerability intelligence.\n\nThis deliberate focus on evidence, attribution, and validation helps reduce alert fatigue and allows engineering and AppSec teams to focus on vulnerabilities that are accurate, relevant, and actionable.\n\n## Looking ahead\n\nThe NVD update is a clear signal that vulnerability management has entered a new phase. CVE remains a critical shared identifier, and NVD remains an important public source of vulnerability enrichment. But as vulnerability volume grows and AI accelerates the discovery, validation, and reporting of vulnerabilities, security teams can no longer rely on a single enrichment source or a static severity score alone.\n\nThe future of vulnerability intelligence will be defined by context, prioritization, and actionability. The goal is no longer to assess vulnerabilities one at a time, but to provide humans and AI agents with a continuously updated view of the attack surface, highlighting the risks that matter most and the interventions most likely to reduce overall exposure.\n\nFor Snyk, this is exactly where intelligence needs to go. Snyk combines multi-source enrichment, open source ecosystem context, AI-assisted workflows, and human security expertise to help customers move from raw vulnerability volume to informed, prioritized action.\n\nAs the vulnerability landscape continues to evolve, vulnerability intelligence must evolve with it - moving beyond enrichment and severity scoring to become the foundation for faster, more informed security decisions.\n\nSNYK RESEARCH\n\n## Inside the Agentic Development Supply Chain\n\nAnonymized telemetry from nearly 10,000 developer environments, plus agent skill analysis across enterprise environments", "url": "https://wpnews.pro/news/nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence", "canonical_source": "https://snyk.io/blog/nvd-multi-source-vulnerability-intelligence/", "published_at": "2026-06-25 00:00:00+00:00", "updated_at": "2026-06-25 15:50:58.630116+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-research", "ai-tools", "ai-infrastructure"], "entities": ["NIST", "NVD", "Snyk", "CVE", "CVSS"], "alternates": {"html": "https://wpnews.pro/news/nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence", "markdown": "https://wpnews.pro/news/nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence.md", "text": "https://wpnews.pro/news/nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence.txt", "jsonld": "https://wpnews.pro/news/nvd-in-the-ai-era-the-case-for-multi-source-vulnerability-intelligence.jsonld"}}