Safeguard
DevSecOps

Why NVD alone is not enough: the case for multi-source vulnerability intelligence

NIST now fully enriches a fraction of CVEs — on April 15, 2026 it moved to a triage model that leaves most of 2025's 48,185 published CVEs without a timely severity score.

Safeguard Research Team
Research
7 min read

On April 15, 2026, NIST quietly ended one of the assumptions that vulnerability management programs have run on for over two decades: that every published CVE would eventually receive full National Vulnerability Database enrichment, including a CVSS score, CPE mappings, and a severity classification. In its place, NIST introduced a prioritized triage model that reserves full enrichment for CVEs meeting narrow criteria — and the shift didn't come out of nowhere. In 2025, 48,185 CVEs were published, and NVD fully enriched roughly 42,000 of them, a workload Snyk's research team has characterized as running about 45% heavier than the year before. Zoom out further and the pressure is structural: CVE submission volume climbed 263% between 2020 and 2025, from around 18,000 a year to more than 48,000, while the enrichment team doing the analysis did not grow anywhere near that fast. The result is a database that was already straining before the policy change, and will now formally deprioritize the vast majority of new disclosures. For any team that treats "not in NVD yet" as "not urgent yet," that's a dangerous assumption to keep making. This piece looks at what actually changed, why it happened, and what a resilient vulnerability intelligence practice needs to look like now that a single government database can no longer be the whole story.

What exactly did NIST change in April 2026?

NIST replaced its prior universal-enrichment mandate — the implicit expectation that every CVE would eventually get a full NVD writeup — with an explicit triage policy that only guarantees full enrichment to CVEs meeting one of three conditions: the vulnerability appears in CISA's Known Exploited Vulnerabilities (KEV) catalog, it affects U.S. federal government software, or it affects "critical software" as defined under Executive Order 14028. For KEV entries specifically, NIST has set a target of same-business-day enrichment, which is a meaningful improvement for that narrow slice. But everything outside those three buckets now competes for leftover analyst time with no committed turnaround. NIST also pulled back on independent scoring: if the CNA that submitted a CVE already attached a CVSS number, NIST's enrichment team generally won't second-guess it with a fresh calculation of its own, and a CVE that's already been enriched only gets a second look when NIST becomes aware of a change judged to "materially impact the enrichment data." Snyk's research and content team, which tracks NVD operational data closely, framed this as NIST formally acknowledging a capacity problem rather than continuing to promise coverage it could not deliver.

How big is the gap between "published" and "prioritized"?

The gap is large once you look at the actual numbers behind the new triage tiers. Of the 48,185 CVEs published in 2025, only about 245 new entries were added to the CISA KEV catalog across the same year — meaning the fastest, most reliable enrichment lane NIST now offers covers roughly half of one percent of everything disclosed. Federal-software and "critical software" CVEs add more volume, but nowhere near enough to close the gap; the overwhelming majority of CVEs affecting the open-source packages, libraries, and vendor products that most organizations actually run fall outside all three priority tiers. That doesn't mean those CVEs are harmless — plenty of high-impact, widely exploited vulnerabilities never make the KEV catalog quickly, if at all, because KEV requires confirmed evidence of active exploitation before CISA lists it. A vulnerability can be trivially exploitable and still sit for weeks or months without a KEV listing, a federal designation, or a fresh CVSS score, which is exactly the blind spot teams relying purely on NVD data now inherit.

Why is CVSS scoring becoming less consistent across the ecosystem?

CVSS scoring is becoming less consistent because CVE numbering has become genuinely decentralized, and NIST's new policy leans further into that decentralization rather than correcting for it. More than 500 independent CNAs now operate globally — vendors, open-source foundations, bug bounty platforms, and regional CERTs among them — each authorized to assign CVE IDs and, increasingly, their own CVSS scores for vulnerabilities in their own scope. That was always a source of some scoring variance, since different organizations apply the CVSS rubric with different judgment calls about attack complexity or scope. NIST's decision to stop recalculating a CVSS score whenever a CNA has already supplied one removes what used to function as a normalizing backstop. In practice, this means the severity number attached to a CVE increasingly reflects the scoring philosophy of whichever CNA happened to file it, not a uniform, independently verified assessment — so two vulnerabilities with genuinely comparable real-world risk can carry meaningfully different CVSS scores depending on who filed the paperwork.

What does a multi-source vulnerability intelligence approach actually look like?

A multi-source approach treats NVD as one input among several rather than the authoritative record, and pulls signal from wherever a vulnerability first surfaces. Snyk describes its own approach as combining in-house security research with threat-intelligence signals — exploit activity, proof-of-concept publication, and even relevant social media chatter — alongside direct submissions from the open-source maintainer and responsible-disclosure community, academic security research collaborations, and an AI-assisted triage process with human validation before anything is published. The common thread across serious multi-source programs is the same: vendor security advisories, GitHub Security Advisories, the OSV database, and CISA KEV each surface certain classes of vulnerability faster or more completely than NVD does on its own, and cross-referencing them catches disclosures that would otherwise sit in NVD's unenriched backlog indefinitely. No single feed, including NVD, has ever had full ecosystem coverage — the April 2026 policy change just made that gap official policy instead of an occasional operational lag.

How should teams adjust their vulnerability management workflow now?

Teams should stop treating an absent or stale CVSS score as evidence of low risk and instead build workflows that pull exploitability and reachability signals independent of NVD's enrichment timeline. That means tracking EPSS (Exploit Prediction Scoring System) probabilities alongside — or instead of — a static CVSS number, checking CISA KEV directly rather than waiting for NVD to reflect a KEV listing, and ingesting vendor bulletins and GitHub Security Advisories for the specific ecosystems a team actually depends on, since those often post fix guidance well before NVD enrichment lands. It also means re-scoping what "unscored" means internally: a CVE with no NVD-assigned CVSS is not a CVE with no severity, it's a CVE where the organization now needs another source, or another method, to establish severity itself. Given that only a sliver of 2025's 48,185 CVEs made it into a fast-lane enrichment tier, any program still gating remediation priority purely on NVD's CVSS field is going to systematically under-prioritize real risk for the rest of 2026 and beyond.

How Safeguard helps

Safeguard's vulnerability engine was built around the assumption that no single feed is sufficient, aggregating findings from NVD, GitHub Security Advisories, OSV, CISA KEV, vendor security bulletins, and researcher disclosures into one normalized view rather than waiting on any one source's enrichment queue. Every vulnerability surfaces with both a CVSS score and an EPSS exploit-probability score side by side, so a CVE that NIST hasn't gotten around to re-scoring under the new triage model still gets ranked against real exploitation likelihood. Griffin AI layers reachability analysis and business context on top of that aggregated data to tell teams which findings actually matter in their codebase, regardless of whether NVD has caught up yet. And because Safeguard's own research pipeline identifies certain classes of vulnerabilities ahead of public CVE feeds entirely, teams aren't limited to reacting only once a disclosure clears someone else's enrichment backlog — multi-source intelligence and independent discovery work together to close the exact gap NIST's April 2026 policy just widened.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.