Patching Won't Save You

The security industry has spent thirty years optimizing for the same response: find the vulnerability, ship the fix, apply the patch, repeat. It's a reasonable loop when vulnerabilities were counted in the hundreds per year and attackers took weeks to weaponize a new CVE.

That world is gone.

In 2020, there were 18,323 CVEs published. In 2025, there were 48,185. That's a 163% increase in five years. FIRST's median forecast for 2026 is nearly 60,000 CVEs, and with new AI models, some people are predicting more than 100,000 CVEs. The Linux kernel accounted for 5,530 CVEs in 2025, at a pace of 8–9 new vulnerabilities per day.

There are so many new vulnerabilities that NIST isn't even going to categorize all of them anymore. You're on your own to figure out severity for your environment. Even if you could patch faster, it wont matter because the attackers are already ahead of you.

In 2020, the average time between a CVE disclosure and active exploitation was 30 days. That was already a narrow window for most organizations, whose patch cycles are 30 to 90 days. By 2025, the median time to exploit was under 5 days — and 28% of vulnerabilities were being exploited on the same day as disclosure or before a patch was available.

Over one in four actively exploited vulnerabilities in 2025 were being weaponized before there was anything to patch. The average time to exploit for that subset was negative one day. The fix didn't exist yet.

This is no longer a patching problem. This is a structural problem. And patching faster won't protect you.

The security industry isn't ignoring the crisis. Vendors are racing to shrink patch latency. Chainguard announced a one-day SLA for any CVE added to CISA's Known Exploited Vulnerabilities catalog, the first explicit KEV commitment from any container vendor.

But a vendor shipping a fix in under 24 hours doesn't change the full picture. The patch is available. A security alert fires. A ticket opens. That ticket enters a sprint queue, a change advisory board review, a maintenance window. The infrastructure team validates the update against production workloads, the rollout happens in waves, and by the time that one-day vendor patch reaches a live system, 14 to 60 days have elapsed. And that's for a well-run organization.

This cycle exists for a reason. A kernel update can conflict with a customer driver; a dependency upgrade can alter production behavior; an aggressive patch deployed without testing will cause the very outage it was meant to prevent. Organizations average 88 days to remediate a critical vulnerability after a patch is available, and 50% of CISA KEV entries remain unpatched 55 days after a fix ships.

Attackers exploit in hours. Organizations remediate in months. No change advisory board runs at machine speed.

The average enterprise application has hundreds of direct dependencies and thousands of transitive ones. A typical container image ships dozens of packages the application never actually calls. A base OS image designed to be "general purpose" carries libraries, interpreters, tools, and drivers for use cases that will never materialize in your environment.

Every package in your repositories and on your systems is a liability.

Systems never get less complex, and exploits always get better. The industry's response has been to build better tools for tracking and releasing patches faster. Vulnerability scanners. SBOMs. Real-time CVE feeds. One-day KEV SLAs. These are all tools to build better mousetraps, which assumes a steady supply of mice.

The alternative is to shrink the surface area. If a package isn't present, it cannot be exploited. If a library isn't shipped, the CVEs against it don't apply to you. You cannot be breached through software you don't run.

Distroless containers were right all along. The concept of an image containing only the application and its direct runtime dependencies, with no shell, no package manager, no debugging tools has existed for years and was largely dismissed as too operationally inconvenient.

But at 131 CVEs per day, with exploits arriving before patches and organizations taking 88 days to remediate, the operational inconvenience of a distroless image is trivial compared to the exposure cost of a bloated one. Every package you remove is a CVE category that simply stops applying to you.

The same logic applies to the OS. Talos Linux is purpose-built by Sidero Labs exclusively for running Kubernetes. It's what happens when you take minimalism seriously as an architectural principle. Talos ships with fewer than 50 binaries: no shell, SSH, package manager, or systemd. Management happens entirely through a cryptographically authenticated gRPC API with no interactive access layer for an attacker to target.

The filesystem is immutable, eliminating an entire class of persistence techniques. The kernel ships pre-hardened with KSPP mechanisms that make exploitation of the CVEs that apply dramatically harder. Upgrades are atomic with rollback, which largely dissolves the testing-versus-speed tradeoff that haunts traditional patch management.

The result is an environment where the vast majority of CVEs simply don't apply. While the world was patching for a sophisticated attack on xz-utils in 2024, Talos Linux didn't have any required changes. This is what proactive security looks like. Not faster reactions to known vulnerabilities, but an architecture that makes whole categories of attack structurally impossible.

Patching will remain necessary, but it will never be sufficient.

The industry has spent decades optimizing reactive vulnerability management. That model made sense when the CVE rate was manageable and exploit timelines were measured in weeks. Neither is true anymore. The organizations that will navigate the next five years without major breaches or emergency patching are not the ones with the fastest patch pipelines. They're the ones that have made aggressive, deliberate decisions to run less software and have built infrastructure where the attack surface is small by design, not by accident.

The answer isn't to patch faster. The answer is to have less to patch.

Just take a look at how Talos Linux handled Copy Fail.

Statistics referenced in this post draw on data from NIST NVD, CISA's Known Exploited Vulnerabilities catalog, FIRST's 2026 Vulnerability Forecast, Edgescan's 2025 Vulnerability Statistics Report, Mandiant M-Trends 2026, and Red Hat's Product Security Risk Report 2025.