NVD backlog exposes the limits of traditional vulnerability management

At a glance

What this is: This analysis argues that the NVD backlog is exposing a structural limit in traditional vulnerability management, where disclosure volume and software complexity are moving faster than centralised analysis can keep pace.

Why it matters: It matters because identity and security programmes that rely on static prioritisation, including systems with third-party access, secrets and runtime dependencies, need faster decision models to prevent blind spots.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 17 minutes.

👉 Read NowSecure's analysis of the NVD backlog and vulnerability management strain

Context

The primary issue is not simply a backlog. It is the widening gap between vulnerability disclosure and the point at which a team can make a defensible risk decision. That gap matters across application security, cloud security and identity governance because exposure often sits in dependencies, secrets, third-party components and runtime pathways rather than in the CVE record alone.

In practical terms, vulnerability management now intersects with identity control because many exploitation paths depend on credentials, tokens, service accounts or third-party access. When analysis slows, attacker advantage grows. That makes exploitability, asset criticality and dependency visibility more useful than severity scores alone for prioritisation.

The article's starting position is increasingly typical: many security teams still depend on a workflow built for a slower software ecosystem, even as AI-assisted development and supply-chain complexity are increasing the number of issues that never receive full central analysis.

Key questions

Q: How should security teams prioritise vulnerabilities when remediation capacity is limited?

A: Prioritise by exposure, business criticality, and the identities attached to the affected asset. A remotely reachable flaw on a system with privileged access or sensitive data deserves earlier attention than a technically severe issue on an isolated low-value system. Tie severity scoring to ownership, exploitability, and blast radius so remediation decisions reflect real risk, not just scanner output.

Q: Why do third-party SDKs create blind spots in vulnerability management?

A: Third-party SDKs can introduce behavioural, privacy and supply-chain risks that never become a CVE. If a component is not assigned a record, traditional vulnerability workflows may never see it. Teams therefore need inventory, runtime observation and software composition analysis to detect exposure that sits outside the database-driven model.

Q: What do security teams get wrong about CVE coverage?

A: They often assume that if a risk matters, it will appear in a database and receive equal analysis. In practice, many important issues are delayed, deprioritised or never scheduled at all. The mistake is treating vulnerability management as a complete map of exposure instead of one input into wider risk governance.

Q: How can teams reduce exposure while waiting for full vulnerability analysis?

A: Teams should isolate high-risk assets, reduce reachable attack surface, and apply compensating controls such as virtual patching, segmentation and privilege reduction before remediation is complete. This is especially important where the issue affects third-party components or applications that cannot be patched immediately.

Technical breakdown

Why the CVE-to-priority pipeline is breaking down

Traditional vulnerability management assumes a linear workflow: discover, assign, enrich, prioritise and remediate. That model depends on a central analysis function that can keep pace with disclosure volume. Once backlog growth outstrips enrichment capacity, teams are forced to act on partial information. NVD narrowing its coverage toward KEVs and federal software is a sign that the old expectation of equal treatment for every CVE is no longer sustainable. The real mechanism is triage under scarcity, where exploit intelligence, asset context and dependency exposure matter more than a complete record for every issue.

Practical implication: replace single-source prioritisation with an exploitability-first triage model that uses KEV and EPSS alongside asset context.

Why software supply chains create non-CVE risk

Modern applications depend on third-party SDKs, open-source packages, APIs and commercial components that can introduce harmful behaviour without generating a CVE. Some issues are functional, behavioural or privacy-related rather than conventional software flaws, which means they may never enter NVD workflows. The Mintegral SDK example shows how runtime observation can reveal risk that database enrichment misses. In other words, vulnerability databases describe a subset of exposure, not the full attack surface.

Practical implication: pair CVE monitoring with runtime testing and software composition analysis that can detect risky third-party behaviour.

How AI-assisted development changes vulnerability economics

AI-assisted coding increases software output, which increases dependency count, code churn and the number of issues entering the ecosystem. That does not just create more vulnerabilities. It also compresses the time available to validate, enrich and remediate them. As a result, the security problem shifts from completeness to speed of decision. Teams that wait for full enrichment before acting will lose ground to the rate at which new software and new exposure are produced.

Practical implication: automate continuous testing and pre-production checks so new code paths are assessed before backlog pressure accumulates.

Threat narrative

Attacker objective: The objective is to exploit the time gap between disclosure and prioritisation so weaknesses remain usable long enough to cause compromise or data exposure.

1. Entry occurs when rapidly produced software, third-party SDKs or exposed dependencies introduce an unvetted weakness into the environment before security teams have complete analysis.
2. Escalation follows when backlog pressure delays enrichment, leaving exploitability unknown and enabling attackers or risky runtime behaviour to move ahead of remediation.
3. Impact is measured in delayed fixes, blind prioritisation and exposure windows that remain open because teams cannot distinguish high-risk issues quickly enough.

NHI Mgmt Group analysis

Exploitability is becoming the real control plane for vulnerability management: once backlog growth outpaces enrichment, CVSS-only prioritisation stops being operationally useful. Security teams need to decide which issues matter before the database has finished describing them. That changes vulnerability management from a records problem into a decision-speed problem. Practitioners should treat exploitability signals and asset criticality as the primary governance lens.

Third-party dependency visibility is now a governance requirement, not a hygiene task: the article shows that meaningful exposure often sits in SDKs, packages and runtime behaviours that do not always become CVEs. That means traditional vulnerability workflows undercount risk in modern software estates. The practitioner conclusion is clear: if you cannot inventory dependencies and observe their behaviour, you cannot claim complete risk visibility.

AI-assisted development is creating vulnerability volume faster than central review models were designed to absorb: more code output does not just expand attack surface, it compresses the window for analysis. The security organisation that still waits for complete enrichment before prioritisation is assuming a slower ecosystem than the one it actually runs. Teams should redesign controls around continuous validation and faster triage decisions.

Mobile and application security are converging on the same problem of incomplete visibility: whether the risk is a mobile SDK, a third-party package or an injected dependency, the issue is often outside the CVE record at the moment defenders need to act. That makes supply-chain observability part of application governance, not a separate specialist concern. Practitioners should align appSec and vulnerability management on the same risk model.

What this signals

Backlog-driven triage will become the default operating model: security teams should expect vulnerability management to behave more like risk arbitration than queue processing. The organisations that win here will be the ones that can decide quickly which findings deserve immediate containment, which can wait for patching and which need compensating controls.

Control visibility, not just scan coverage, will separate mature programmes from noisy ones: if dependency inventories, runtime observations and exploit signals are disconnected, the team cannot prove where risk really sits. For identity-heavy environments, that matters because third-party access, secrets and service accounts often become the effective path from a software flaw to compromise.

The practical shift is toward continuous validation across the software supply chain. Teams should align vulnerability operations with frameworks such as NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 where dependencies, credentials and runtime behaviour intersect.

For practitioners

• Prioritise exploitability over severity Use EPSS and CISA KEV alongside asset criticality, internet exposure and business impact so the highest-risk issues move first. Severity alone is too slow and too abstract when backlog pressure is high.
• Inventory third-party dependencies and SDKs Maintain an inventory of packages, SDKs, APIs and commercial components in every production app, then map them to business owners and runtime permissions. Without that visibility, security teams are guessing where exposure lives.
• Continuously test software behaviour Add runtime and pre-production testing that looks for unexpected network calls, data collection and privilege use, especially in mobile apps and embedded SDKs. Static scanning alone will miss behaviour that never becomes a CVE.
• Shorten the decision path for new disclosures Create a fast triage path for high-signal findings so teams can decide within hours whether to contain, patch, isolate or monitor. Backlog pressure should not become a reason to defer all action until enrichment is complete.

Key takeaways

• The article shows that vulnerability management is now constrained by decision speed, not just detection volume.
• The NVD backlog and projected disclosure growth expose a gap between finding issues and turning them into actionable risk priorities.
• Teams need exploitability-first triage, runtime testing and dependency visibility to manage exposure before enrichment catches up.

Key terms

• Exploitability-first prioritisation: A vulnerability triage approach that ranks findings by the likelihood of real-world abuse rather than by severity score alone. It uses signals such as active exploitation, exposure, asset criticality and privilege context to decide what should be fixed first when analysis capacity is constrained.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Vulnerability enrichment: The process of adding context to a disclosed vulnerability so teams can prioritise it correctly. Enrichment typically includes severity, affected products, exploitation status, reference intelligence and business context, but it is only useful if the organisation can act on it quickly enough.
• Runtime Observability Gap: The disconnect between what identity systems think was granted and what access systems show was actually used. This gap weakens governance because teams cannot confidently decide whether access is still necessary, especially in hybrid and distributed environments.

What's in the full article

NowSecure's full analysis covers the operational detail this post intentionally leaves for the source:

• How the OIG audit quantified the NVD backlog and the projected disclosure growth rate.
• The article's explanation of why NIST narrowed analysis scope and how that changes prioritisation.
• Examples of software supply-chain exposure that may never receive a CVE, including runtime behaviour cases.
• The practical mobile security testing and dependency visibility measures NowSecure recommends.

👉 NowSecure's full post covers the audit findings, prioritisation shift and mobile supply-chain implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and workload identity. It helps practitioners connect identity controls to broader security and risk programmes.