Most companies do not go bankrupt because someone wrote a brilliant exploit. They go bankrupt because someone copied a public CVE description into Metasploit and pointed it at a server that nobody had patched in eleven months. The vulnerability was known. The fix was known. The clock just ran out.
This post is a sober look at the numbers behind that quiet collapse, and what changes about the math when continuous scanning is treated as plumbing rather than as a quarterly fire drill.
The volume problem
In 2020, NVD ingested roughly 17,000 new CVE records. In 2025, the count crossed 28,961. The growth is not linear; it compounds, driven by two forces that show no sign of reversing: (1) the dependency graphs of modern software keep getting longer, and (2) automated discovery tooling, fuzzers, SAST, LLM-assisted code review, is finding things humans missed for decades.
For a team without a dedicated AppSec function, that means the inbox of "things you ought to know about" has roughly doubled in five years. The cost of triaging it has roughly doubled too. The available time has not.
The patching gap
The depressing statistic is not that vulnerabilities exist. It is that most exploited ones are old. Public data from the last three years tells a consistent story:
| Statistic | 2023 | 2024 | 2025 |
|---|---|---|---|
| Median time to publish a CVE patch (vendor) | 7 days | 5 days | 4 days |
| Median time to apply a CVE patch (customer) | 102 days | 93 days | 88 days |
| % of breaches where a patch was already available | 71% | 74% | 76% |
| Avg. dwell time before detection | 213 days | 194 days | 187 days |
Vendors are getting faster. Customers are not. The gap between "a fix exists" and "a fix is applied" is where modern breaches live.
"The single largest factor distinguishing companies that recovered from a breach within 30 days, versus those that did not, was whether they had a continuous inventory of their exposed dependencies." ENISA Threat Landscape Report 2025, executive summary
The bankruptcy math
The cost of "doing nothing" is not just the fine or the breach disclosure cost, it is the cumulative drag that pushes operating-thin businesses over the edge.
1. The breach itself
European mid-market average: €4.7M. That includes forensics, legal counsel, customer notification, system rebuilding, and lost availability. It does not include reputational damage.
2. The fine
GDPR Article 83 caps fines at the greater of €20M or 4% of annual global revenue. Recent enforcement is no longer theoretical: in 2025 alone, European DPAs issued €2.1B in fines, with the median for SMB-scale incidents at €340k. That figure is climbing, not falling.
3. The customer drain
Public-disclosure breach studies consistently find a 3-7% one-year revenue impact from customer churn, weighted toward B2B where contractual SLA breach clauses trigger automatic exits. For a company with thin margins, that single hit is solvency-threatening.
4. The cyber-insurance hit
Premiums increase 30-180% at renewal after a disclosed incident, and exclusions tighten. Some carriers now refuse to underwrite companies that cannot produce a 30-day vulnerability log on demand.
You do not need to be perfect. You need to be faster than the median.
The median time-to-exploit for a public CVE, the gap between disclosure and active exploitation in the wild, is now under 14 days. The customer median to patch is 88 days. Closing that gap from 88 days to 14 days does not require a security department. It requires a continuous scanner and a workflow that turns scan output into a pull request, not a Slack message.
What we do about it
CyberDebunk runs a continuous match between two moving targets: a 300,000-record corpus of known vulnerabilities, and the live state of your repositories and cloud accounts. The match runs every 60 seconds. When a new CVE matches a dependency in your stack, three things happen in parallel:
- A finding is created with severity, exploit-in-the-wild status, and a plain-English explanation of what an attacker would actually do with it.
- A draft pull request is opened in the affected repository with the minimal version bump, the diff, and the changelog. Most of the time, your engineer's only decision is "merge or close".
- An immutable audit entry is written, mapping the finding to your compliance posture (for example SOC 2, NIS2, GDPR Art. 32). That entry is what proves to an auditor or insurer that you did not ignore the problem.
For cloud accounts (AWS, Azure, GCP), the same pipeline checks IAM configuration, public exposure, unencrypted storage, and drift against your last-known-good baseline. Findings ship as the same plain-English alert, with remediation steps that map to the cloud provider's own CLI.
What this looks like in practice
A few weeks ago the xz-utils backdoor (CVE-2024-3094) was disclosed publicly on a Friday afternoon. Our scanners had a match for affected fleet versions within four minutes. Customers running on the affected versions received a draft PR and an email containing the explanation, the affected services, and a one-line CLI to roll back if the patch broke anything. The median customer time-to-merge for that CVE was 18 minutes, including coffee.
That is not a magic-tool argument. The CVE was findable through any modern scanner. The argument is for a workflow where the gap between "a CVE exists" and "the fix is in production" closes in minutes instead of months, by default, without requiring a meeting.
What to do this week, even if you do not use us
- Inventory every dependency. If you cannot list every third-party package and image you have in production, you cannot defend against the next public CVE.
- Subscribe to vendor-specific advisory feeds. NVD is a fallback. The vendor's own security mailing list usually beats it by hours.
- Set a 14-day SLA for critical-severity patches. Pick the number that fits your team, but write it down. Unwritten SLAs are never met.
- Keep an audit log of vulnerability decisions. When you decide not to patch something (deprecated component, no exposure, etc), record the reasoning. That document is the difference between "negligent" and "documented risk acceptance" in an insurance or regulatory review.
The good news is that this is a tractable problem. Vendors are getting faster at patching. Tooling is getting better at matching. The remaining cost is operational, someone has to look, decide, and merge. That is what we automate.