Most vulnerability management programs are built on a simple assumption: vulnerabilities are discovered, assigned a CVE, analyzed, prioritized and remediated.
A new federal audit suggests that model is under increasing strain.
The National Vulnerability Database (NVD) backlog isn’t just a government process issue; it’s evidence that vulnerability volume, software supply-chain complexity and shrinking exploitation timelines are beginning to outpace the systems security teams rely on to manage risk.
A May 2026 U.S. Department of Commerce Office of Inspector General (OIG) audit found that NIST’s NVD backlog had grown to more than 27,000 unprocessed vulnerabilities. The report also found that NIST lacked a strategic plan for managing the backlog and projected annual vulnerability disclosures would exceed 60,000 in 2026 alone. NIST concurred with all six recommendations.
The backlog itself may be only the most visible symptom of a larger challenge.
Software supply chains continue to grow more complex. AI-assisted development is accelerating software production and increasing the volume of code, dependencies and potential vulnerabilities entering the ecosystem. As vulnerability disclosures continue to rise, organizations increasingly need to make security decisions in hours rather than days or weeks.
The question facing security teams is no longer whether vulnerabilities can be discovered. It’s whether they can be analyzed and prioritized fast enough to matter.
TL;DR
- A new federal OIG audit found the National Vulnerability Database backlog exceeded 27,000 vulnerabilities and projected annual CVE disclosures will surpass 60,000 in 2026.
- The backlog is a symptom of a larger challenge: vulnerability disclosures, software supply chains and exploitation timelines are growing faster than traditional analysis and prioritization processes can keep up with.
- NIST’s recent decision to narrow NVD coverage signals a shift away from the expectation that every vulnerability will receive the same level of analysis.
- Not every meaningful software risk becomes a CVE. Third-party SDKs, software supply chain exposures and runtime behaviors often fall outside traditional vulnerability management workflows.
- Security teams should prioritize exploitability over severity alone, continuously test software and improve visibility into third-party dependencies and SDKs.
The Vulnerability Management Model Is Under Strain
For decades, vulnerability management followed a predictable workflow.
A vulnerability was disclosed. A CVE was assigned. The NVD added context such as severity scores, affected products and remediation guidance. Security teams then used that information to prioritize remediation.
That model worked when vulnerability volume was manageable. Today, the scale looks very different.
The OIG projects annual vulnerability disclosures will exceed 60,000 in 2026, representing nearly ten times the volume reported a decade ago. Meanwhile, the backlog of vulnerabilities awaiting analysis has continued to grow.
In response, NIST recently narrowed the scope of vulnerabilities it will fully analyze, focusing primarily on Known Exploited Vulnerabilities (KEVs), federal software and software identified under Executive Order 14028. Thousands of vulnerabilities were moved to “Not Scheduled” status, meaning they will not receive the same level of analysis that security teams have historically relied upon.
The challenge isn’t unique to NIST. The broader issue is that vulnerability management increasingly depends on centralized analysis processes that were designed for a smaller, slower software ecosystem. The rise of AI-generated code and AI-assisted development is likely to accelerate this trend, creating more software and dependencies that must be analyzed, prioritized, and monitored.
As software supply chains expand and vulnerability disclosures accelerate, the gap between vulnerability discovery and actionable intelligence continues to widen.
The question facing security teams is no longer whether vulnerabilities can be discovered. It’s whether they can be analyzed and prioritized fast enough to matter.
Not Every Risk Becomes a CVE
Even if the NVD backlog disappeared tomorrow, security teams would still face risks that never enter traditional vulnerability management workflows.
Software supply-chain risk is a good example.
A few years ago, privacy-invasive behavior in the Mintegral advertising SDK affected more than 1,200 iOS applications and hundreds of millions of devices. The SDK monitored user activity and network traffic while actively attempting to avoid detection in common testing environments.
No CVE existed. No NVD record was available to analyze. The issue was identified through direct observation of runtime behavior rather than vulnerability database analysis.
This is increasingly common across modern software ecosystems.
Organizations depend on open-source packages, third-party SDKs, APIs and commercial software that introduce risk in ways traditional vulnerability databases were never designed to track. While some of these issues eventually receive CVE identifiers, many do not.
For security teams, that means vulnerability intelligence remains important — but it is no longer sufficient on its own.
What Security Teams Should Do Next
The answer is not abandoning vulnerability management.
The answer is adapting vulnerability management to a world where disclosures arrive faster than they can be analyzed.
Prioritize Exploitability, Not Just Severity
As vulnerability volume increases, security teams need stronger signals than CVSS scores alone.
Resources such as the Exploit Prediction Scoring System (EPSS) and CISA’s Known Exploited Vulnerabilities (KEV) Catalog help organizations prioritize vulnerabilities based on real-world exploitation activity rather than theoretical severity.
Continuously Test Software
Point-in-time assessments were designed for a slower environment.
Continuous mobile application security testing helps identify vulnerabilities and risky behaviors as software changes rather than months later during scheduled reviews.
This is particularly important for mobile apps and software supply chains, where vulnerabilities often emerge through dependencies and third-party components.
Know Your SDKs
Third-party SDKs have become one of the largest software supply-chain attack surfaces.
Security teams should understand which SDKs exist in their applications, what permissions they require and how they behave at runtime.
Treating SDKs as trusted by default is increasingly difficult to justify.
Expand Visibility to Third-Party Apps
The mobile apps employees use every day introduce many of the same risks as mobile apps developed internally.
Modern security programs need visibility into both the software they build and the software they procure.
Conclusion
The NVD backlog will eventually be addressed. But the OIG report makes clear the underlying challenge won’t be solved by clearing a queue.
Vulnerability volume is accelerating. Software supply chains are growing more complex. Security teams increasingly need to make risk decisions before complete vulnerability analysis is available. The programs built to handle that reality don’t wait for every vulnerability to be fully analyzed. They build continuous testing, exploitability-first prioritization and supply chain visibility into the model itself.
Reach out to NowSecure to explore how mobile app risk management helps identify software supply-chain risks that never appear in vulnerability databases.
Frequently Asked Questions
Why is the NVD backlog important for security teams?
The NVD backlog matters because security teams rely on NVD analysis to prioritize and remediate vulnerabilities. The OIG report found the backlog had grown to more than 27,000 unprocessed vulnerabilities while annual vulnerability disclosures are projected to exceed 60,000 in 2026. Together, those trends raise questions about whether traditional vulnerability analysis models can continue to scale.
What is vulnerability enrichment?
Vulnerability enrichment is the process of adding context to a newly disclosed CVE, including severity scores, affected products, vulnerability classifications and reference information. This analysis helps security teams understand risk and prioritize remediation.
Can vulnerability databases keep pace with modern software supply chains?
That is becoming increasingly difficult. Modern software depends on open-source components, third-party SDKs, APIs and commercial software that create thousands of potential dependencies. At the same time, vulnerability disclosures continue to increase, making analysis and prioritization more challenging.
Why are more organizations prioritizing exploitability over CVSS scores?
Exploitability-focused approaches such as EPSS and CISA’s KEV Catalog help security teams prioritize vulnerabilities based on actual attacker activity rather than theoretical severity. As vulnerability volume grows, these signals become increasingly valuable.
Why are mobile app risks often missing from vulnerability databases?
Many mobile risks involve SDK behavior, supply-chain compromises, privacy issues or runtime activity that never receives a CVE identifier. As a result, these risks may not appear in vulnerability databases even though they create significant exposure.
What does the NVD backlog mean for mobile app security?
The backlog reinforces a lesson mobile security teams have learned for years: vulnerability databases provide valuable intelligence, but they don’t provide complete visibility into mobile risk. Effective mobile security requires continuous testing and visibility into the software supply chain, not just CVE monitoring.
