TL;DR: With 48,000+ CVEs published in 2025 and NIST shifting NVD prioritisation toward risk-based backlog handling, scanner quality now depends on intelligence depth, reachability analysis, and pre-CVE visibility, according to Aikido. Databases alone no longer provide enough coverage for modern software supply chains, and the right scanner increasingly has to separate exploitability from noise.
At a glance
What this is: Aikido argues that modern CVE scanning is now an intelligence challenge, with database coverage, pre-CVE signal, and reachability analysis determining whether findings are actionable.
Why it matters: This matters to security and IAM practitioners because vulnerability prioritisation now depends on whether scanners can distinguish exploitable risk from noise across code, dependencies, containers, and supply chain touchpoints.
By the numbers:
- 131 new vulnerabilities a day were disclosed in 2025, which raises the burden on scanners that depend on manual enrichment.
- Aikido says 67% of the vulnerabilities it found were never reported to any public database, exposing the limits of database-only coverage.
- Aikido says the average time from patch to CVE assignment was 27 days, leaving a gap where exploitability may already exist before disclosure is indexed.
Context
CVE scanning is no longer just a lookup problem. The operational issue is whether a security programme can see vulnerabilities early enough, rank them correctly, and avoid drowning teams in findings that cannot be exploited in context.
In software supply chains, the value of a scanner now depends on intelligence quality as much as catalogue coverage. That creates a governance problem for vulnerability management, because the right control is increasingly the one that can separate real attack paths from theoretical exposure.
Key questions
A: Security teams should treat CVEs as one input, not the control plane. When disclosure lags exploitation, they need runtime detection, exploit blocking, and application layer telemetry to identify malicious behavior before a formal record exists. That means prioritising controls that observe what software is doing now, then using CVE data to enrich response and patching decisions.
Q: Why do database-only CVE scanners miss real risk?
A: Because databases are limited by disclosure timing, enrichment backlog, and incomplete metadata. A scanner that relies on a single source can only see what has already been published, while real attackers often exploit weaknesses before formal records are available. That creates blind spots in fast-moving software supply chains.
Q: What are the signs that a CVE scanner is producing too much noise?
A: Common signs include large volumes of findings with no production execution path, repeated alerts on test-only code, and backlog growth that outpaces triage capacity. If engineers ignore scanner output because too many items are unexploitable, the tool is reducing confidence instead of improving security.
Q: How should security teams choose between developer-native and infrastructure CVE scanners?
A: Use developer-native scanners for code, dependencies, and CI/CD remediation, and infrastructure scanners for asset-level coverage, compliance reporting, and scheduled environment checks. The choice should follow the control point you need to govern, not the vendor category or the number of CVEs a product claims to cover.
Technical breakdown
Why database-only CVE coverage breaks down at scale
Public CVE databases are indexing systems, not complete threat intelligence platforms. They depend on disclosure timing, enrichment throughput, and consistent metadata, all of which lag behind real-world exploitation. When disclosure volume spikes, databases become incomplete by design: some records are delayed, some remain unenriched, and some never fully capture reachability or exploit context. That means a scanner built to trust a single feed inherits the feed’s blind spots. In practice, the problem is not just missing CVEs. It is the delay between a weakness being exploitable and the record becoming operationally useful for defenders.
Practical implication: treat database coverage as a baseline and test whether your scanner can see vulnerabilities before they are formally indexed.
How reachability analysis turns findings into exploit signals
Reachability analysis evaluates whether vulnerable code is actually callable from a real execution path in the target environment. This matters because many scanners flag every matching package or line of code even when the vulnerable function sits behind dead code, test-only logic, or an input path that never occurs in production. By tracing call graphs and dependency paths, reachability analysis reduces false positives and turns static exposure into contextual risk. The result is not fewer vulnerabilities in theory, but fewer irrelevant findings competing for remediation capacity. For teams with limited engineering time, that distinction is often the difference between backlog and action.
Practical implication: use reachability filtering to prioritise only findings that can be reached through a production execution path.
Why pre-CVE intelligence is becoming a separate control plane
Pre-CVE intelligence is the capability to detect signals of vulnerability before a CVE exists. It relies on changelog monitoring, release-note analysis, advisory correlation, and often human validation to turn weak signals into actionable findings. This is materially different from waiting for formal disclosure, because exploitation and remediation rarely align with CVE publication timelines. In modern development environments, the control plane is shifting from reactive catalog matching to proactive threat discovery. That shift matters across code, dependencies, containers, and supply chain inputs, because the earliest credible warning is now part of the security decision itself.
Practical implication: require pre-CVE detection for high-change dependency and build pipelines, not only post-disclosure scanning.
Threat narrative
Attacker objective: The attacker’s objective is to exploit vulnerable software before defenders can reliably identify, prioritise, and remediate it.
- Entry occurs when vulnerable code, packages, or infrastructure components are present in the software stack but not yet matched to a disclosed CVE or trusted intelligence source.
- Credential access is not the primary stage here; the main abuse path is exposure of exploitable software weakness before scanners can classify it accurately.
- Impact follows when teams miss reachable vulnerabilities, leaving exploitable code in production longer than their vulnerability process assumes.
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.
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
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
Coverage is no longer the differentiator, intelligence is. The scanner market has moved past the question of whether a tool can read a database. What matters now is whether it can assemble a timely, validated view of exploitability across multiple intelligence sources and production contexts. For practitioners, that means scanner selection is becoming a governance decision about evidence quality, not just feature breadth.
Reachability is the control that turns inventory into risk. A long list of matched CVEs is operationally weak if most of them cannot be reached in the running environment. This is where vulnerability management overlaps with application and cloud governance: teams need to know which findings are actually traversable from an execution path. The practical conclusion is that remediation queues should be driven by attack path relevance, not raw match count.
Pre-CVE detection is becoming part of baseline exposure management. Waiting for formal CVE assignment is increasingly incompatible with the speed of modern release cycles. The gap between patch availability and CVE publication can leave defenders blind for weeks, which means the organisation’s risk posture depends on sources that can surface early signals with enough confidence to act. Practitioners should now judge scanners on whether they compress that gap or merely report it.
Software supply chain governance now depends on signal orchestration. The best scanner is not the one with the longest feed list, but the one that can reconcile public advisories, proprietary research, and local execution context into a usable decision. This is especially relevant where code, containers, and third-party dependencies converge. Teams should treat signal orchestration as a core control, not a reporting convenience.
What this signals
Signal of change: vulnerability governance is shifting from catalogue management to evidence management. Teams need scanners that can combine advisory data, local execution context, and supply chain telemetry into a defensible priority queue.
Scanner intelligence debt: organisations that still treat CVE lookup as the primary control are accumulating blind spots wherever disclosure lags exploitation. The practical response is to measure whether the tool can detect and suppress unreachable issues before they consume engineering capacity.
For practitioners
- Map scanner coverage to real attack surface Verify that your scanner sees source code, dependencies, containers, IaC, and runtime assets, not just a single package database.
- Prioritise reachability over raw match counts Require the tool to show whether a vulnerable function is callable in production before you assign remediation priority.
- Test for pre-CVE visibility Ask vendors how they detect vulnerabilities before CVE assignment and what validation they use to suppress noisy early signals.
- Separate developer and infrastructure workflows Use developer-native scanning for code and dependency remediation, and infrastructure scanning for scheduled asset-level coverage.
- Measure alert quality as a governance metric Track false positives, suppression rates, and time-to-triage so vulnerability management reflects actionable risk rather than scan volume.
Key takeaways
- CVE scanning now depends on intelligence quality, not just database size, because disclosure speed and enrichment lag create predictable blind spots.
- Reachability analysis matters because a finding that cannot be executed in production is not an actionable priority.
- Teams should evaluate scanners on pre-CVE detection, signal quality, and stack breadth across code, dependencies, containers, and supply chain inputs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007 — Discovery | Discovery and exploitable exposure are central to deciding whether CVE findings matter in context. |
| Recommendation — Map scanner output to discovery context and suppress findings that lack a real production attack path. | ||
| NIST CSF 2.0 | DE.CM-09 — Vulnerability Monitoring and Scanning | The article is about how organisations monitor vulnerabilities across a changing software estate. |
| Recommendation — Use DE.CM-09 to validate that scanning covers the assets, code paths, and dependencies that matter. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Continuous vulnerability management is the operational discipline under discussion throughout the article. |
| Recommendation — Apply CIS-7 to ensure vulnerability identification and prioritisation keep pace with release velocity. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article repeatedly shows that incomplete inventories and blind spots drive missed vulnerability coverage. |
| Recommendation — Use API9-style inventory discipline to ensure scanners account for the full asset and dependency surface. | ||
| SLSA | L2 — Build Integrity | Supply chain coverage and dependency trust are part of the scanner selection criteria discussed here. |
| Recommendation — Adopt SLSA-aligned provenance checks so vulnerability signals are paired with build integrity evidence. | ||
Key terms
- Pre-CVE intelligence: Threat information that identifies vulnerable software before a formal CVE has been assigned. It is valuable because disclosure, exploitation, and database enrichment often happen at different times, so teams need signals that can surface risk before public records catch up.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Signal-to-Noise Ratio: The balance between meaningful security events and routine activity in detection tooling. A weak ratio makes analysts spend more time filtering alerts and less time identifying real attacks, which is why architecture quality strongly affects SOC effectiveness.
- Vulnerability Intelligence: Vulnerability intelligence is the information used to identify, prioritise, and remediate software flaws across an environment. It includes identifiers, severity data, advisories, and affected-product details that feed patching and risk workflows.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to strengthen governance across identity and access programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org