NIST’s NVD Changes: A Wake-Up Call for CVE-Driven Security

Security programs have been built around a simple assumption: track the CVEs, prioritize by score, patch what matters. It's a reasonable model on paper, but the problem is that attacks don’t happen on paper. Attackers operate at the technique level.

A single exploitation method, such as insecure deserialization, can be applied across hundreds of CVEs, and  a zero-day by definition has no CVE at all. Novel attack patterns get exploited in the wild before they're catalogued, scored, or assigned an identifier. This means that a program built entirely around CVE analysis is structurally a step behind.

The recent NVD enrichment changes make this gap harder to ignore.

What NIST changed

CVE submissions increased 263% between 2020 and 2025, representing an already staggering pace prior to a sharp uptick in AI-driven vulnerability submissions.  Submissions in the first three months of 2026 are running nearly one-third higher than the same period last year. NIST enriched close to 42,000 CVEs in 2025, its highest output ever, but it still couldn't keep pace.

So on April 15, 2026, NIST announced a new prioritization model. Going forward, enrichment will be prioritized for CVEs appearing in CISA's Known Exploited Vulnerabilities catalog, software used within the federal government, and software defined as critical under Executive Order 14028. Everything else gets labeled "Not Scheduled."

For teams running CVE-centric programs, this compounds an existing problem. Scoring data is how work gets triaged, assigned, and prioritized. When a significant share of new CVEs arrive without NIST-provided CVSS scores or CPE mappings, the signal degrades. At the same time, AI-assisted exploit development has compressed the window between disclosure and active exploitation from months to under 24 hours in some cases. The net-net is that there is now less data to work with and less time to act on it.

But the more important question is not how to compensate for missing metadata. It's whether CVE metadata was ever the right foundation for measuring real risk.

The key shift: from CVE tracking to execution reality

CVE enumeration tells you what vulnerabilities exist in your software. It does not tell you whether those vulnerabilities are reachable, whether the vulnerable code actually runs in production, or whether an attacker is actively exploiting a technique that affects your environment right now. 

You know what does tell you that? Runtime context. 

Oligo monitors which libraries are executed down to the function level in production. The result is exploitability evidence grounded in what your software is doing, not in what a database says about it. A vulnerability with no CVSS score that runs in production is more dangerous than a 9.8 that never actually executes. Security teams that deploy Oligo consistently see 90% or greater reductions in actionable vulnerabilities within 48 hours. Not because CVEs disappear, but because the vast majority exist in code that never runs and thus can’t actually be exploited.

A data strategy that doesn't depend on NVD

For the CVEs that do require attention, Oligo's Runtime Vulnerability Management capabilities don't rely on a single enrichment pipeline. Beyond NVD, we take a layered approach:

1. EPSS Exploit (Prediction Scoring System) enrichment: Oligo enriches every CVE with EPSS scores independently of NVD to enrich the static data with estimates of exploitability probability. 
2. Exploit maturity signals: On top of EPSS, Oligo layers exploit maturity signals from CNAS, public exploit refferences, KEV data, dark web monitoring, other sources where NVD has not provided enrichment.
3. Cross-referenced advisory sources, not a single pipeline: Oligo aggregates across multiple advisory databases and CNAs directly, pulling EPSS scores, exploit maturity data, and CNA-supplied severity ratings into a unified view. The GitHub Security Advisory database is one concrete example: an independent, actively maintained source covering the open source ecosystem where most application dependencies live. When NVD enrichment is absent, the program keeps running.

This system enriches vulnerability data from multiple sources simultaneously, while runtime exploitability context serves as the ultimate risk indicator. Patch what runs, not what shows up in a static scan. 

Detection and blocking that don't require a CVE at all

Oligo Cloud Application Detection and Response (CADR) monitors how applications actually execute: which syscalls libraries invoke, what network connections they initiate, where behavior deviates from baseline. When something anomalous occurs at the application layer, CADR detects it regardless of whether the underlying technique has been assigned a CVE, scored by NIST, or catalogued anywhere for that matter.

Attackers reuse techniques. A single method can be used to exploit dozens or hundreds of vulnerabilities across different CVE identifiers. Oligo observes the behavior at runtime to deliver protection that scales with attack technique coverage rather than patch velocity or database completeness. 

When a vulnerability is actively exploitable and a patch doesn't exist yet, Oligo blocks the malicious syscall directly from the kernel, enabling real-time protection against zero-day attacks without breaking production.  

Considerations going forward

The NVD enrichment changes are a signal worth paying attention to, but the reality is that the CVE system was not built for 310,000-plus annual submissions, AI-accelerated vulnerability discovery, or exploitation timelines measured in minutes. NIST made a rational triage decision. The structural pressure behind it is not going away.

But the deeper issue predates this announcement. Security programs that center entirely on CVE analysis are measuring a representation of risk rather than definitive risk.. A CVE may or may not map to code that runs. A score may or may not reflect what attackers are actually doing. The enrichment may or may not arrive before exploitation occurs.

Runtime is the direct measurement. Oligo sees running code to prioritize, detect, and prevent attacks, with or without a CVE to reference.