NVD prioritization exposes the limits of CVE-centric security

At a glance

What this is: This analysis argues that NVD’s new prioritization model makes CVE-centric security harder to sustain because vulnerability metadata is arriving faster than it can be enriched and used for triage.

Why it matters: For IAM and NHI practitioners, the lesson is that any security model built on incomplete identifiers and delayed scoring will miss technique-level abuse, especially where machine identities and runtime exposure drive actual risk.

By the numbers:

• 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.

👉 Read Oligo Security's analysis of NVD enrichment changes and runtime risk

Context

Security teams often treat vulnerability management as an indexing problem, but attacks happen at the technique level, not the identifier level. A CVE may describe a flaw, yet it says little about whether the vulnerable code runs in production, whether the exploit is already in the wild, or whether the issue is reachable from the paths an attacker can actually use. For NHI governance, that distinction matters because service accounts, tokens, and automated workflows are often assessed indirectly through the software they depend on, not through runtime evidence.

NIST’s April 15, 2026 change to NVD enrichment priorities makes that gap visible. The practical effect is that many new CVEs will not receive the same metadata support teams have depended on for triage, which forces security programmes to decide whether they are managing risk or merely managing records. Oligo Security uses the shift to argue for runtime context over static enumeration, and that framing is directionally correct for modern IAM and NHI operations.

The baseline challenge is not unique to one vendor or one vulnerability workflow. It is typical of organisations that have built patch governance around scorecards, while attackers increasingly move faster than metadata pipelines can keep up.

Key questions

Q: How should security teams prioritise vulnerabilities when CVE metadata is incomplete?

A: Prioritise by runtime exposure, exploitability, and reachability, not by CVE presence alone. If the affected code runs in production and an attacker can reach it, it deserves more attention than a higher-scoring issue that never executes. Teams should combine scanning with live telemetry, KEV data, and business context to make the queue reflect actual risk.

Q: Why is CVE-centric security becoming less reliable?

A: CVE-centric security is less reliable because identifier volume is rising faster than enrichment can keep up, while attackers exploit technique patterns before databases are complete. A program that waits for perfect metadata will always lag. The practical answer is to govern by execution reality, not by the speed of the catalog.

Q: What is the difference between static vulnerability scanning and runtime risk management?

A: Static scanning tells you what vulnerable code exists. Runtime risk management tells you whether that code actually runs, whether it is reachable, and whether behaviour suggests active abuse. The first is useful for inventory. The second is necessary for prioritisation, especially in cloud and NHI-heavy environments.

Q: When should teams treat missing enrichment as a priority signal?

A: Treat missing enrichment as a priority signal when the affected software is exposed, business-critical, or tied to automated identities that can move fast. Missing metadata means the queue is incomplete, not that the risk is low. In those cases, use compensating signals such as exploit activity, runtime execution, and privilege scope.

Technical breakdown

Why CVE metadata breaks down under runtime conditions

CVE data is a catalogue of known issues, not a measurement of exposure. It can tell a team that a flaw exists, but not whether the vulnerable code executes in production, whether the attack path is reachable, or whether the application is actually using the affected library or function. That distinction is especially important in modern environments where automation, embedded dependencies, and ephemeral workloads produce large amounts of unused code. Once NVD enrichment lags, teams are left with identifiers that no longer reliably support urgency decisions. For NHI governance, static metadata is an incomplete control signal because machine identities often interact with the exact systems whose runtime state determines exploitability. Practical implication: prioritise runtime evidence over identifier completeness.

Practical implication: Use runtime execution data to decide what to patch first, especially where service accounts or automated workloads depend on third-party code.

How exploitation techniques outpace vulnerability scoring

Attackers do not need a unique CVE for every campaign. They reuse techniques such as deserialisation abuse, credential theft, or code execution paths across many identifiers, and some zero-days have no CVE at the moment they are exploited. That means a vulnerability management process based on score arrival is always behind any actor who can move from disclosure to exploitation in hours. In practice, the risk is not only missing scores, but also missing the technique itself because a database has not yet caught up. This is the same structural weakness that NHI programmes face when they depend on inventories without runtime verification. Practical implication: build detection and blocking around behaviour patterns, not just published identifiers.

Practical implication: Map controls to observable behaviour so a new exploit path can still be detected before the CVE record is complete.

Why runtime context is a better risk signal than static scans

Runtime context shows what software actually does in production. If a library never executes, the vulnerability inside it may be irrelevant in that environment, even if the scan flags it. If a syscall or network action is anomalous at runtime, the issue may matter immediately even when no CVE exists. This is why exploitability evidence rooted in execution is more useful than broad static findings, particularly for distributed applications and automated identity flows. For NHI and IAM teams, the same logic applies to service accounts and tokens: what matters is not merely that they exist, but whether they are active, over-privileged, and reachable at the moment of misuse. Practical implication: align vulnerability triage with live execution telemetry.

Practical implication: Tie triage to live execution telemetry so you can distinguish theoretical exposure from active attack surface.

Threat narrative

Attacker objective: The attacker wants to turn technique-level vulnerability into active execution before the defender's patch and scoring workflow can respond.

1. Entry occurs through a reusable exploitation technique that can apply across many CVEs, including cases where the vulnerable component has no current CVE identifier.
2. Escalation happens when teams rely on delayed enrichment or incomplete metadata, leaving exploitable code and reachable runtime paths unprioritised.
3. Impact follows when malicious behaviour is executed at the application layer before scoring or cataloguing catches up.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CVE-centric security is now a risk representation problem, not a risk management solution. NVD and CVE records still have value, but they are incomplete proxies for whether an issue is reachable, exploitable, or operationally relevant. Once enrichment falls behind submission volume, teams are triaging by paperwork instead of by exposure. For NHI governance, this is a familiar failure mode because identity inventories without runtime context create the same false confidence. Practitioner conclusion: treat CVE data as one input, not the control plane.

Runtime exploitability is the more durable security primitive for modern environments. The strongest signal is not whether a flaw exists in a database, but whether vulnerable code executes in production and whether the attacker can reach it. That is a better fit for cloud applications, automation, and NHI-heavy systems where static inventories age quickly. This shifts the discipline from patch velocity to blast-radius control. Practitioner conclusion: make runtime visibility part of core security governance.

Technique-level defence should replace identifier-level dependence wherever possible. Attackers reuse methods, not CVE names, and that means detection and blocking logic must understand behaviour patterns, network actions, and abnormal application execution. The same logic applies to NHI abuse, where the identity is often less important than the privilege path and execution context. Practitioner conclusion: build controls that survive metadata delay.

Runtime governances creates an identity blast-radius problem that classic vulnerability programs miss. When automated workloads, tokens, and service accounts interact with vulnerable code, the exposure spreads across both application and identity layers. The named concept here is the runtime execution gap: the difference between what is catalogued and what is actually running. Practitioner conclusion: close that gap before it becomes an incident driver.

Security leaders should expect more prioritisation by exception, not by completeness. NVD’s new model signals that enrichment pipelines will continue to be selective under scale pressure, so programs will need to make decisions with partial data. That does not eliminate CVE workflows, but it does relegate them to supporting evidence. Practitioner conclusion: shift governance to decision-making that tolerates incomplete metadata without losing response speed.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, reinforcing why runtime visibility matters when vulnerability workflows lag.
• Use The 52 NHI breaches Report to connect exploitability gaps with real breach patterns and remediation timing.

What this signals

The next planning shift for security teams is to assume that vulnerability metadata will remain incomplete in high-volume environments. That means the control question changes from how fast can we patch every finding to how well can we prove what is actually running, reachable, and privileged at the moment of exposure.

Runtime execution gap: the distance between what a scanner identifies and what production code is really doing. For IAM and NHI teams, closing that gap requires tying identity privileges, workload telemetry, and remediation queues together so risk decisions are based on live context rather than delayed records. This is the operating model that modern programs will need.

Teams that still separate vulnerability management from identity governance will keep missing the combined blast radius of code and credential exposure. In practice, that means one workflow for runtime evidence, one for secrets and service-account oversight, and one for response decisions tied to business-critical paths.

For practitioners

• Adopt runtime-first vulnerability triage Prioritise issues based on whether the affected code actually runs in production, not only on CVSS or catalog status. Feed execution telemetry into patch queues so reachable libraries, functions, and syscalls rise above dormant findings.
• Correlate vulnerability data with identity exposure Check which service accounts, tokens, and automated jobs can reach vulnerable components before assigning remediation priority. This narrows the blast radius analysis to the identities that can actually trigger the code path.
• Treat enrichment delays as a control gap Assume that some CVEs will remain unscheduled or partially enriched, and create fallback rules for missing metadata. Use KEV status, exploitability signals, and runtime observability together rather than depending on one source.
• Instrument application behaviour at runtime Monitor syscalls, network connections, and library execution so that malicious activity can be blocked even when no CVE has been assigned. This is especially important where automated workloads can execute quickly across many environments.

Key takeaways

• NVD prioritization exposes a broader problem: CVE data is useful for inventory, but insufficient for measuring exploitability in real environments.
• As vulnerability volume rises and enrichment slows, runtime execution data becomes the more dependable signal for triage and response.
• For IAM and NHI teams, the operational shift is clear: govern the identities and code paths that are actually active, reachable, and privileged.

Key terms

• Runtime Vulnerability Management: Runtime Vulnerability Management prioritises flaws based on what software actually does in production, not only on static scan results or catalogue entries. It combines execution telemetry, reachability, and exploit signals to determine whether a finding is genuinely actionable in the current environment.
• 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.
• Technique-Level Attacks: Technique-level attacks reuse the same exploitation method across many vulnerabilities instead of depending on a single CVE. This makes identifier-driven defence brittle because the method can appear in different products, versions, or zero-day conditions before the catalog catches up.
• Runtime Execution Gap: The runtime execution gap is the distance between what security tools record and what production systems are actually doing. It becomes dangerous when teams trust inventory or scoring data without confirming whether vulnerable code, privileged identities, or malicious behaviour are active right now.

Deepen your knowledge

Runtime exploitability and identity-aware prioritisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern automated access in environments where metadata is always incomplete, it is worth exploring.

This post draws on content published by Oligo Security: NIST’s NVD changes and the limits of CVE-driven security. Read the original.