NVD prioritization exposes the limits of CVE-centric security

At a glance

What this is: This analysis argues that NIST's NVD prioritization makes CVE-centric vulnerability management harder to sustain because database coverage is thinning while exploitation timelines shorten.

Why it matters: IAM and security teams need a risk model that reflects what actually runs, because static vulnerability records do not reliably capture reachable exposure, exploited technique reuse, or business impact.

Context

CVE-driven security assumes that vulnerability listings, severity scores, and patch queues are a sufficient model of risk. That assumption breaks when exploitation happens at the technique level, zero-days have no CVE at all, and the vulnerable code may never execute in production.

Oligo Security's article uses NIST's April 2026 NVD changes to show that enrichment is now being concentrated on KEV, federal, and critical-software CVEs while the broader queue is marked Not Scheduled. The governance problem is not only slower metadata delivery but the limits of treating a static identifier as a complete risk signal.

For identity and access teams, the lesson is broader than vulnerability management. Runtime exposure, execution context, and privilege pathways are the conditions that determine whether a flaw can actually be used, which is why asset and identity governance need to align with live execution rather than only catalogue data.

Key questions

Q: What breaks when vulnerability management is based only on CVSS scores?

A: CVSS-only prioritisation breaks when several lower-scoring flaws can be combined into a complete exploit path. In that model, the real risk is not one critical CVE but the sequence of reachable weaknesses across connected assets. Teams need to rank exposure by exploit path and blast radius, not by a flat severity list alone.

Q: Why does missing NVD enrichment create operational risk?

A: Missing enrichment degrades the scoring and mapping data many teams use to triage, assign, and justify work. When large numbers of CVEs are marked Not Scheduled, the programme has less context to separate urgent exposure from noise, so local telemetry and alternative advisory sources become necessary to preserve decision quality.

Q: How do teams know whether a vulnerability is actually dangerous in production?

A: They confirm whether the vulnerable code runs, whether the path is reachable, and whether the behaviour appears in live execution. Runtime context is the clearest indicator because it ties the flaw to real exposure rather than to catalogue status or theoretical severity. If the code is dormant, the operational priority should usually be lower.

Q: What should security teams do when a CVE has no patch yet?

A: Focus on containment around the exploit behaviour itself. If the vulnerability is being actively abused, use blocking, isolation, or compensating controls against the runtime action instead of waiting for a full remediation cycle. The aim is to reduce exposure before exploitation can continue or recur.

Technical breakdown

Why CVE lists fail as a risk model

A CVE is an identifier for a vulnerability, not proof of exploitability. Teams often treat CVSS, CPE mappings, and enrichment status as if they described live risk, but those fields only tell you that a flaw exists and has been catalogued. They do not answer whether the vulnerable code runs in production, whether the path is reachable, or whether attackers are already using the same technique across multiple weaknesses. Once AI-assisted exploit development compresses the time from disclosure to active abuse, database completeness becomes a lagging indicator rather than a control plane.

Practical implication: Treat CVE data as input to triage, not as the risk decision itself.

What NVD prioritization changes operationally

NIST's new prioritization model concentrates enrichment on CVEs in CISA's Known Exploited Vulnerabilities catalog, federal software, and software deemed critical under Executive Order 14028. Everything else is labeled Not Scheduled, which means many programs will receive less metadata precisely when submission volume is increasing. That does not remove the vulnerability. It removes a layer of decision support that security teams had come to depend on for assignment, scoring, and queue ordering. In practice, this shifts responsibility from the central catalogue to local telemetry, advisory aggregation, and execution-aware validation.

Practical implication: Build a triage model that can keep operating when enrichment is missing or delayed.

Why runtime exploitability outranks static severity

Runtime analysis changes the question from 'does this CVE exist?' to 'is the vulnerable code actually executed here?' That distinction matters because a high-scoring weakness in dormant code creates less immediate exposure than a lower-scoring issue on a live execution path. Oligo Security frames this as monitoring libraries at the function level and using runtime behavior to identify whether attack techniques are present in production. This is not a replacement for vulnerability data, but it is a more faithful measure of exploitability than database status alone.

Practical implication: Prioritise remediation based on what executes in production, not on what merely appears in a scan.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CVE-centric programs are now measuring representation, not risk. CVE inventories, enrichment status, and severity scores were always abstractions, but the abstraction becomes brittle when attacks land faster than metadata arrives. The deeper failure is governance-by-catalogue: teams confuse description with exposure and end up prioritising records instead of reachable attack surface. The practitioner takeaway is that vulnerability governance must be grounded in execution reality, not just identifier management.

Runtime context is the missing control plane for vulnerability prioritisation. A flaw that never executes is not the same operational problem as a flaw on a live path, even if both carry the same label. Oligo Security's framing is useful here because it separates catalogue status from exploitability evidence. That distinction matters for security operations, patch orchestration, and the way boards interpret remediation progress.

The NVD change exposes a broader trust gap in enrichment pipelines. When a single upstream source is asked to carry triage for too many submissions, the governance model inherits latency, gaps, and uneven coverage. That is not just a NIST issue. It is a reminder that any programme depending on one metadata pipeline is one backlog away from degraded decision quality, so practitioners need diversified evidence sources and live validation.

Execution-aware security is the next defensible baseline for vulnerability governance. A programme that can prove what runs, what is reachable, and what is actually being exercised can make better decisions than one that only knows what exists in a database. That is especially important as exploitation techniques are reused across many CVEs and zero-days bypass cataloguing entirely. The implication is clear: the centre of gravity is moving from scoring to observation.

Runtime exploitability should become the named concept for this category shift. The article is really about moving from identifier-led risk management to evidence-led risk management. That concept is stronger than 'vulnerability prioritisation' because it captures the operational question practitioners now face: what matters is not whether a weakness is known, but whether it is currently exploitable in the environment. The practitioner conclusion is to manage against runtime exploitability, not catalogue completeness.

What this signals

Runtime exploitability is the concept security teams should adopt now. Catalogue completeness is losing value as a primary decision signal because exploitation can arrive before enrichment does. Programmes that can verify what code runs in production will make better calls than programmes that only know what is listed.

The practical shift is from queue management to evidence management. That means diversifying advisory inputs, validating reachability, and treating static vulnerability records as one source among several rather than the final arbiter of priority.

For practitioners

• Separate catalogue signal from exposure signal Use CVE records for inventory and reporting, but require an execution-based check before a vulnerability is elevated into a remediation commitment.
• Diversify enrichment sources Correlate NVD with EPSS, KEV, vendor advisories, CNA data, and other maintained sources so queueing does not fail when one pipeline stops enriching.
• Prioritise running code first Rank vulnerabilities by whether the affected library, function, or service is present in production and reachable from the attack path.
• Use runtime evidence for zero-day defence Where patching is not yet possible, block or monitor the behaviour that indicates active exploitation rather than waiting for a catalogue entry to appear.

Key takeaways

• CVE-centric programmes are increasingly exposed as partial models because they describe vulnerabilities without proving reachability or live exploitability.
• The NVD prioritization change intensifies an existing governance problem by reducing enrichment for large portions of the CVE queue.
• Security teams need runtime evidence, not just catalogue status, to decide what deserves remediation first.

Key terms

• Verified Exploitability: Verified exploitability means a finding has been reproduced in execution, not merely inferred from code. It is the practical threshold that separates a plausible defect from a security issue that should drive severity, remediation priority, and incident response.
• CVE-Centric Security: A CVE-centric security model treats vulnerability counts and severity scores as the main guide for remediation. It often overweights what is easiest to measure and underweights attacker behaviour, access paths, and business context. This can create busy work without materially reducing the organisation’s exposure to compromise.
• Execution Context: Execution context is the live operating state of an application, including which libraries run, which syscalls execute, and which network paths are used. In security practice, it helps separate theoretical exposure from code that is truly reachable and therefore more urgent to remediate.
• Dynamic Enrichment Pipeline: A dynamic enrichment pipeline automatically gathers supporting context from sources such as threat intelligence, IAM, EDR, and CMDB systems when a case is created. The goal is to attach trustworthy evidence early, so analysts can judge severity, business impact, and likely spread with less manual effort.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.