Scanner coverage lags exploit development for critical CVEs

At a glance

What this is: Cogent’s analysis shows scanner coverage is routinely too slow for critical CVEs, with exploits often arriving before detection signatures.

Why it matters: For IAM, PAM, NHI, and broader security teams, this means vulnerability management can no longer depend on scan output as the first or only signal of exposure.

By the numbers:

• 55.7% of critical vulnerabilities never received a scanner detection signature.
• The average time between CVE publication and the first public exploit fell from 125.3 days to 0.5 days.

Context

Scanner coverage and exploit availability are now moving on different clocks. A vulnerability scanner can only detect what its signatures know about, while exploit development can begin as soon as a patch diff or code change gives attackers enough signal to work from.

For identity and access teams, that timing gap matters because exposure is often governed by whether defenders can identify affected assets before attackers can weaponise the flaw. In practice, CVE scanning, asset inventory, and threat intelligence now need to work together, not as sequential controls but as parallel signals.

Cogent’s analysis suggests this is not a corner case. The gap is most consequential at critical severity, where operational urgency is highest and where a delayed detection signal leaves the shortest time to act.

Key questions

Q: What breaks when a scanner finds vulnerabilities but does not fix them?

A: Teams accumulate findings faster than they can close them, so the scanner becomes a reporting layer instead of a control. The result is remediation backlog, developer fatigue, and a weaker security posture because exposure stays live after discovery. In practice, organisations need fix-oriented workflows for high-confidence issues, not just more alerts.

Q: Why does scanner lag matter more for critical CVEs than lower-severity issues?

A: Critical CVEs tend to attract the fastest exploit development because they offer the highest payoff to attackers. When a scanner arrives after exploitation is already possible, the organisation has lost its most valuable warning window. Lower-severity issues still matter, but they are less likely to be weaponised as quickly and at scale.

Q: How do security teams know whether vulnerability assessment is actually working?

A: Teams should look for short triage cycles, high-confidence findings, and a clear link between scan results and remediation action. A working programme reduces uncertainty around what to fix first. If the same issues keep reappearing or the queue is dominated by false alarms, the tool is not helping governance.

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.

Technical breakdown

Why signature-based scanners lag exploit development

Signature-based scanners depend on a vendor first understanding the vulnerable pattern, translating it into a detection rule, and shipping that rule to customers. That pipeline was tolerable when exploit development took weeks or months. It breaks down when AI-assisted analysis can turn a patch diff into working exploit code in hours. The scanner is therefore not a control on the vulnerability itself. It is a visibility mechanism that only works after enough semantic understanding has been encoded into a signature. When attackers move faster than that encoding cycle, the control becomes reactive by design.

Practical implication: Treat signature scanning as one signal in a broader exposure workflow, not as proof that no exploitable condition exists.

Why critical CVEs create the worst visibility gap

Critical vulnerabilities attract the fastest exploit development because they often provide the highest-value access path. That makes the coverage race hardest exactly where the risk is greatest. Cogent’s data shows that the majority of critical CVEs with known exploits were already exploitable before scanner coverage arrived, which means detection lag is not evenly distributed across the risk stack. The problem is not simply scanner speed. It is the mismatch between the pace of exploit creation and the slower pace at which scanner ecosystems can enumerate and classify every new issue, especially in long-tail software and retroactively assigned CVEs.

Practical implication: Prioritise compensating controls for critical CVEs when scanner coverage is absent or delayed, because the highest-risk flaws are the least likely to wait.

What alternative detection mechanisms change the model

The practical alternative is not perfect predictive scanning. It is faster exposure correlation using asset inventory, software version data, SBOMs, and threat intelligence. Those inputs can identify likely affected systems before a scanner signature exists, even if the result includes some false positives. That is a useful trade-off when the alternative is several days of zero visibility. In governance terms, this moves vulnerability management from a signature-confirmation model toward an exposure-assessment model. The question becomes whether an organisation can identify likely blast radius quickly enough to narrow the attacker’s window of opportunity.

Practical implication: Build pre-signature exposure workflows that correlate inventory and version data to likely affected assets as soon as a CVE is disclosed.

Threat narrative

Attacker objective: Exploit vulnerable software before defenders can detect it with scanner signatures, then use that head start to gain access or execute code.

1. Entry begins when a new CVE is published and an attacker uses patch analysis or AI-assisted tooling to derive a working exploit before scanner vendors ship a matching signature.
2. Credential or access abuse follows when the exploit is used against exposed software to gain execution or foothold inside the target environment.
3. Impact occurs before defenders receive scanner-based visibility, leaving security teams blind during the most dangerous part of the exposure window.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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

Signature-first vulnerability management is now an obsolete assumption for critical CVEs. The article shows that scanner output often arrives after the exploit window has already opened, which means visibility and safety are no longer synonymous. Organisations that still treat a clean scan as proof of acceptable exposure are confusing detection latency with absence of risk. Practitioners should treat this as a control boundary problem, not a tooling problem.

Critical CVEs now create an exposure race that governance processes were not built to handle. Traditional remediation workflows assume there is time to discover, triage, prioritise, and patch after a signature appears. Cogent’s findings show that assumption fails when exploit development compresses to hours. The implication for vulnerability governance is that asset context and exploit intelligence must be available before scanner coverage, especially for internet-facing systems and high-value workloads.

Exposure correlation is becoming the decisive control pattern. The named concept here is pre-signature exposure gap: the period between a vulnerability becoming exploitable and a scanner being able to detect it. That gap is now large enough to matter operationally and small enough to defeat legacy sequencing models. Security teams should move from waiting for detection to using asset, software, and threat data to infer likely exposure immediately.

NHI and workload governance are affected because many critical vulnerabilities now live in the software fabric that supports identities and automation. Vulnerable control planes, gateways, and service components can expose credentials or privilege pathways long before a scan confirms the issue. That makes identity-adjacent systems part of the vulnerability race, even when the CVE itself is not about authentication. Practitioners need exposure logic that understands which systems can amplify compromise, not just which systems return a finding.

Board reporting on vulnerability risk needs a new metric. Counting scanner coverage alone hides the period when critical assets are exploitable but still invisible to standard tooling. The more meaningful question is how quickly the organisation can identify likely affected systems after disclosure. Security leaders should track time-to-likely-exposure as a governance signal, because it better reflects the real decision window than scanner completion rates do.

What this signals

Pre-signature exposure gap: the useful unit of governance is no longer scanner coverage alone, but the interval between public disclosure and a credible estimate of which assets are likely affected. That is the window defenders must compress if they want vulnerability management to keep pace with exploit generation.

For identity-adjacent infrastructure, this shift matters because vulnerable gateways, control planes, and service components can create privilege amplification paths before standard tooling produces a finding. Exposure intelligence must therefore sit alongside scanning in the operational model, not behind it.

For practitioners

• Build pre-signature exposure workflows Correlate asset inventory, software versions, and SBOM data against newly disclosed CVEs so likely affected systems are identified before scanner signatures arrive.
• Prioritise compensating controls for critical CVEs Use network segmentation, temporary access restriction, and targeted monitoring when a critical vulnerability is known to be exploitable but coverage is still missing.
• Track exploit-to-coverage lag as an operational metric Measure the time between public exploit availability and detection-signature shipment across your scanner estate, then use that lag to set remediation urgency.
• Separate exposure triage from confirmation scanning Treat scanner confirmation as one input, not the trigger for response, so triage begins as soon as credible exploit intelligence or affected-version data appears.

Key takeaways

• Scanner coverage now lags exploit development often enough that organisations cannot treat clean scans as proof of safety.
• Cogent’s analysis shows the problem is structural, not occasional, with most critical CVEs either never covered or exploited before coverage arrived.
• Security teams should respond by correlating asset data and threat intelligence earlier, so they can narrow the blast radius before scanner signatures exist.

Key terms

• Pre-signature Exposure Gap: The period between a vulnerability becoming practically exploitable and detection signatures being available in scanner tools. It describes a governance blind spot, not a product defect, and becomes more dangerous as exploit generation accelerates.
• Exploit-to-coverage lag: The time difference between when a working exploit is publicly available and when security tooling can detect the associated CVE. This lag determines whether teams have a warning window or are already behind the attack curve.
• Exposure Correlation: The process of linking where sensitive data exists to who can access it and through which identity. In practice, this is what turns a data inventory into a security control, because it reveals which permissions and delegated paths create the largest breach surface.
• Signature-Based Detection: Signature-based detection identifies malware by comparing files or patterns against known malicious indicators. It is effective for previously seen threats but weak against polymorphic malware, fileless execution, and attacks that reuse legitimate tools, because the malicious behaviour may never match a stable signature.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps practitioners connect identity control to broader exposure management. It is designed for security and identity teams that need to govern machine access as part of resilient programme design.