Scanner coverage lags exploit development for critical CVEs

At a glance

What this is: This analysis shows that exploit development is now outrunning vulnerability scanner coverage for most critical CVEs, creating a visibility gap that often opens before defenders can react.

Why it matters: For IAM and security teams, the finding matters because vulnerability management, access control, and asset inventory now need to work together when scanners cannot be treated as the first line of truth.

By the numbers:

• 62.0% of critical vulnerabilities with a known exploit had that exploit circulating before any scanner released a detection signature.
• Average time between CVE publication and the first public exploit fell from 125.3 days to 0.5 days.
• 54.0% of CVEs published since January 2025 have no detection signature from any of the three scanners analyzed.
• 83.2% of critical vulnerabilities either never had scanner coverage or were exploitable before coverage arrived.

👉 Read Cogent's analysis of exploit timing versus scanner coverage for critical CVEs

Context

CVE scanning is only useful when detection arrives before exposure becomes exploitable. This article shows the opposite pattern: exploit timelines are shrinking faster than scanner coverage can catch up, which means many teams are finding out about risk after attackers already have working code. For security programmes that depend on vulnerability scanners as the main source of truth, that gap changes the operating model.

The identity angle is indirect but real. When exploitation windows collapse, privileged systems, service accounts, and workload identities become easier to target before defenders can complete remediation cycles. That makes asset inventory, access scope, and compensating controls more important than waiting for a scanner signature to appear.

Key questions

Q: How should security teams handle critical CVEs before scanner signatures exist?

A: They should move from signature-driven response to exposure-driven response. Use software inventory, SBOMs, internet exposure data, and threat intelligence to identify likely affected assets immediately, then narrow the blast radius by reducing privilege, isolating exposed services, and accelerating patch validation on the highest-risk systems.

Q: Why do scanners miss the most dangerous vulnerabilities in time?

A: Because exploit development is compressing faster than detection engineering. A scanner needs a stable signature before it can alert reliably, while an attacker only needs one working exploit path. In fast-moving CVEs, that means the first warning often arrives after exploitation has already begun.

Q: What breaks when vulnerability management is limited to scan results?

A: Teams end up triaging large numbers of findings without knowing which ones can be chained into a working attack. That creates remediation noise, slows response to genuine exposure, and leaves identity, session, and workflow weaknesses under-prioritised until they are already being abused.

Q: Who is accountable when an internet-facing server exposes a critical CVE?

A: Accountability usually spans infrastructure, platform, and application owners, because reachability, configuration, and patching all influence risk. Frameworks such as the NIST Cybersecurity Framework support that shared responsibility model by tying identify, protect, detect, and respond together.

Technical breakdown

Why scanner signatures lag exploit development

Scanner vendors ship detection logic after a vulnerability is disclosed and after a rule can be written with enough confidence to avoid excessive false positives. Exploit developers, by contrast, can use patch diffs, code changes, and AI-assisted analysis to generate proof-of-concept code quickly. That creates a structural race: the offensive side only needs one working exploit path, while the defensive side needs a reliable signature that can be safely deployed at scale. The result is that vulnerability visibility is often retrospective rather than preventive.

Practical implication: teams need compensating controls that identify exposed software before scanner signatures exist.

Why critical CVEs are the hardest to cover in time

Critical vulnerabilities attract the fastest attacker attention because they usually offer direct privilege gain, remote execution, or broad compromise potential. That means the most dangerous CVEs are also the ones most likely to be weaponised before detection rules are available. Even scanners with relatively fast median response times can still lose on the specific vulnerabilities that matter most. In practice, the severity label does not guarantee visibility, and it certainly does not guarantee that a detection rule will arrive before exploitation begins.

Practical implication: prioritisation must be driven by exploitability and exposure, not by scan status alone.

What to use when scanners cannot be the primary control

When signatures lag, organisations need an alternate way to identify likely affected systems quickly. Software inventory, SBOM correlation, configuration baselines, and threat intelligence matching can narrow the blast radius from minutes after disclosure, even if they do not provide the exact same precision as a scanner verdict. This approach shifts the question from 'can we detect the vuln?' to 'where is this software present, and how exposed is it?' That is a more operationally useful control posture during the early hours of a CVE lifecycle.

Practical implication: build exposure mapping from inventory and SBOM data into your vulnerability workflow.

Threat narrative

Attacker objective: The attacker wants to exploit exposed software before defenders can identify it through scanner coverage, then use that head start to compromise systems at scale.

1. Entry occurs when a public CVE is rapidly converted into working exploit code before defensive detections exist.
2. Escalation follows when attackers use the exploit against exposed software to gain code execution or higher privilege.
3. Impact is the compromise of systems that scanners had not yet flagged, leaving defenders blind during the highest-risk window.

NHI Mgmt Group analysis

Signature-first vulnerability management is now a lagging control model. When exploit development moves from days to hours, scanner output becomes evidence of what was already exploitable rather than a reliable early warning system. That does not make scanners useless, but it does mean they cannot remain the primary control boundary for critical exposure decisions. Practitioners should treat signatures as one input in a broader exposure management workflow.

Exploit compression creates a detection-response latency gap. The real issue is not just scanner speed, but the shrinking time between public disclosure and attacker action. That gap is where organisations lose decision quality, because remediation, prioritisation, and verification all depend on information that now arrives too late. The practical conclusion is that exposure intelligence must be built before signature availability, not after it.

Credentialed systems and machine identities inherit the same race condition. Vulnerability timelines do not stop at application code. Once attackers can reach a compromised service, workload identities, service accounts, API keys, and elevated access paths can be used to widen impact quickly. This is why NHI governance belongs in vulnerability response planning, especially where exposed software can touch secrets, tokens, or privileged automation.

Exposure mapping is becoming the named concept that matters most. Scanner coverage once served as the default proof of risk reduction, but the new failure mode is the unscanned, already-exploitable asset. Organisations need a control model that ties vulnerability intelligence to software inventory, SBOMs, and privilege scope so they can see what is likely affected even when detection rules are absent. Practitioners should operationalise exposure mapping as a first-hour response capability.

Attack speed is now a governance issue, not just a tooling issue. If leadership assumes detection will arrive before exploitation, remediation targets, escalation paths, and service owner accountability are all based on the wrong clock. The organisations that adapt fastest will be those that align vulnerability operations with identity, asset, and change control, rather than waiting for scanners to define the pace of response.

What this signals

Exposure intelligence will overtake scanner status as the operational metric that matters. When exploit timelines collapse, practitioners cannot wait for formal detection signatures to decide whether an asset is dangerous. The programme-level shift is toward asset-centric triage, where inventory quality, software provenance, and privilege scope define response speed.

Identity control becomes part of vulnerability operations. Once vulnerable software can expose service accounts, API keys, or workload identities, remediation is no longer only about patching code. Security teams will need tighter links between vulnerability management, PAM, secrets handling, and NHI lifecycle controls so that exploit windows do not translate into broader access paths.

Detection latency now exposes governance debt. Organisations that cannot answer which systems are running a vulnerable package, who owns them, and what those systems can reach will keep losing the first hours of a CVE. That is a process failure as much as a tooling failure, and it should be managed like one.

For practitioners

• Build exposure mapping from inventory and SBOM data Use software inventory, SBOM correlation, and configuration baselines to identify likely affected assets within minutes of CVE disclosure, before scanner signatures arrive.
• Prioritise remediation by exploitability, not scan presence Treat known exploit availability, internet exposure, and privilege-bearing assets as higher priority than systems that simply failed a scanner check.
• Tie vulnerability response to identity and privilege scope Identify which vulnerable systems can reach secrets, tokens, service accounts, or administrative interfaces, then reduce privilege where possible before patching completes.
• Use threat intelligence to pre-stage detections Preload emerging exploit indicators, patch-diff intelligence, and vendor advisory monitoring into your workflow so analysts can act before scanners publish formal signatures.

Key takeaways

• The core problem is not scanner quality alone, but the shrinking window between disclosure and exploitation.
• Cogent’s data shows that most critical CVEs are either never covered or become exploitable before coverage appears.
• Teams need exposure mapping, asset inventory, and identity-aware remediation to stay ahead of scanner lag.

Key terms

• Exploit-Detection Gap: The time between a vulnerability becoming exploitable and defenders receiving a reliable detection signal. In fast-moving environments, this gap can be the difference between preventative action and post-compromise cleanup, especially when signatures lag behind attacker tooling.
• Exposure mapping: A path-based view of how identities, systems, and network connections relate to one another under attack. It goes beyond asset inventory by showing where compromise could travel and which controls would stop it.
• Scanner Coverage: The extent to which vulnerability scanners can recognise a specific CVE or exposed configuration in an environment. Coverage is useful only when it arrives soon enough to inform decisions, and it does not replace inventory or exploit intelligence when the race is already lost.

What's in the full report

Cogent's full research covers the operational detail this post intentionally leaves for the source:

• Methodology for tracking 69,159 CVEs across publication, exploit availability, and signature ship dates.
• Vendor-by-vendor median lag analysis for Tenable, Qualys, and Rapid7 across severity bands.
• Monthly trend breakdown showing how exploit timelines collapsed from 125.3 days to 0.5 days.
• Interpretive guidance on how to use inventory and SBOM correlation when scanner coverage is missing.

👉 Cogent's full post includes the methodology, severity breakdowns, and scanner-by-scanner lag comparisons.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity control to operational risk. It helps security teams apply lifecycle discipline across programmes that depend on privileged access, service accounts, and workload identities.