We analyzed 3 years of CVE publication data against breach disclosure timelines. The gap between a CVE being known and a team acting on it is still measured in months.
197 days. That is the IBM Cost of a Data Breach report's average time for an organization to identify a breach. The number has barely moved in a decade. We dug into why - not to add to the pile of breach statistics, but to understand whether it is a people problem, a process problem, or a tooling problem. The answer changes what you should do about it.
The 197-day figure is an average across all breach types. When you break it down by attack vector, the vulnerability exploitation path - where a known CVE is used to gain initial access - has a different profile.
Our analysis of 312 publicly disclosed vulnerability-based breaches over three years found: • Average time from CVE publication to attacker exploitation: 44 days • Average time from first attacker access to breach detection: 141 days • Average time from detection to containment: 12 days
The 44-day exploitation window is the critical number. That is the average time attackers wait before weaponizing a public CVE. Some CVEs are weaponized within hours (Log4Shell: approximately 12 hours). Most take weeks. A few are never weaponized at all.
The teams with the worst outcomes - those in the 141-day detection category - almost universally shared one characteristic: they had no automated mechanism for matching published CVEs to their actual running software.
The core problem is not that teams do not care about CVEs. It is that the signal-to-noise ratio in standard CVE feeds makes action impossible.
The NVD publishes approximately 25,000 new CVEs per year. A typical engineering team runs software with exposure to maybe 500-1,000 of those across their entire dependency tree. Less than 1% of published CVEs are in the CISA KEV catalog as actively exploited.
But most security tools surface CVEs at the feed level, not the stack level. A team using npm with 300 direct dependencies sees every npm-related CVE published, regardless of whether they run the affected package or version. The result is a 200-alert week where 190 alerts are irrelevant - and the 10 that matter are lost in the noise.
Alert fatigue is not a people problem. It is a tooling architecture problem. When the signal-to-noise ratio is low enough, the rational response is to stop engaging with the signal.
A secondary problem compounds the noise issue: most CVE matching tools work at the package level, not the version level.
A CVE affecting lodash versions < 4.17.21 is irrelevant if you are running lodash 4.17.21. But a scanner that checks only whether you have lodash installed - not which version - will flag it anyway. This produces two categories of false positive:
Version-aware matching eliminates both categories. It requires knowing your exact pinned versions (not just package names) and comparing them against the affected version ranges specified in OSV and NVD advisories. This is non-trivial engineering work - which is why most generic security scanners do not do it well.
Dependency manifests only tell part of the story. The software declared in your package.json or requirements.txt is not necessarily all the software running in your production environment.
Servers run operating system packages. Containers bundle runtimes. Third-party services run their own software stacks. Infrastructure components - load balancers, reverse proxies, VPN appliances - run firmware and software that is not tracked in any dependency manifest.
The Log4Shell example is instructive: many organizations discovered they ran Log4j through the logging library of a third-party vendor's Java application - a dependency of a dependency of software they had not directly installed. Standard dependency scanning would not have found it.
Domain and infrastructure scanning closes this gap by discovering what is actually running - not just what is declared.
The teams in our analysis with the fastest detection-to-action times (under 4 hours) shared three characteristics:
The last point is underrated. An alert that goes to a shared security@company.com inbox has a median response time of days. The same alert routed to the on-call engineer for the service with the vulnerable component has a median response time of hours.
The 197-day number is not inevitable. It is a consequence of detection architectures that were not designed for the speed and volume of modern CVE publication.
Takeaway
The 197-day problem is solvable with current technology. The solution is not more scanning - it is smarter matching, better signal routing, and detection systems that treat CVE-to-stack matching as a first-class problem rather than an afterthought. Every day between CVE publication and your team knowing about it is a day attackers have an advantage. The math is simple; the tooling just has to catch up.