Security

The Patching Paradox Driving Most Breaches

Even when vulnerabilities are detected early, delayed patching leaves systems exposed, allowing known risks to drive a growing share of enterprise breaches.

Nearly 93% of organizations identify vulnerabilities before attackers do — yet many still get breached after fixes are available, fueling a new era of "zombie software" and unmanaged legacy risk.

More than 60% of enterprise breaches now stem from vulnerabilities with available patches, underscoring a breakdown in execution rather than a lack of information.

TuxCare's third annual 2026 Open Source Landscape Report, released last month, confirms that this pattern persists across enterprise environments — and shows little sign of improving.

The report also points to a maturing open-source landscape, as IT teams become more deliberate in how they deploy, manage, and scale open-source software.

Recent high-impact cyber incidents are reshaping how organizations approach risk, trust, testing, and response — while exposing persistent operational gaps. At the same time, enterprises are rethinking how they handle end-of-life (EOL) software, extended usage, and long-term maintenance in environments where upgrades are not always immediate — or even possible.

Artem Karasev, senior product manager at TuxCare, said the issue is not a failure of detection systems like common vulnerabilities and exposures (CVEs), but their limitations when used in isolation.

"CVEs are still useful as signals, but a CVE-and-alert workflow alone is not enough to achieve risk reduction in enterprise environments," he told LinuxInsider.

Rising Incident Signals

Throughout Q4 2025, TuxCare researchers gathered data from a primarily technical respondent base. Software engineers represented the largest segment of participants, followed by tech leads, system administrators, and DevOps professionals.

Among enterprise open-source users who were aware of their organization’s incident status, 47.8% reported experiencing a cybersecurity incident in the past 12 months. According to researchers, the near-even split suggests incidents are neither rare nor universal.

"So the real problem is not that the CVE model is dead. It is that the enterprise security operating model is still too ticket-driven, maintenance-window-driven, and human-gated for the pace of modern vulnerability churn," Karasev said. "They tell you what exists; they do not solve change control, compatibility testing, ownership ambiguity, production risk tolerance, or remediation throughput."

The report shows that cyber incidents are a routine reality for many organizations. Respondents said such incidents are frequent enough to be considered a normal operating risk.

A significant majority — 61.4% — of reported incidents are associated with unapplied but available patches, a slight increase from 60.4% last year. This close split indicates the issue is persistent rather than improving or deteriorating significantly, according to the report.

The lack of material change compared with last year suggests that organizations continue to face similar constraints around patch timing, deployment, and prioritization.

Patching Gap Persists

The report shows that 92.6% of organizations knew they were vulnerable before a security incident occurred. Most incidents tied to known vulnerabilities stemmed from unpatched systems, suggesting operational friction rather than a lack of information.

Dependency complexity also affects software updates and end-of-life reliability. The report noted that most production stacks (37.7%) carry 25–99 direct dependencies, but confidence in the security of deep, transitive dependencies remains low, with only 22.4% of teams feeling very confident.

Organizations are moving away from "hiring their way out" of security debt. They are instead focusing on automation and process discipline to close the gap between vulnerability discovery and patching.

According to Karasev, the primary operational friction respondents cited was downtime constraints, reported by 43.0% of respondents. After that, human error accounted for 31.6%, and a lack of resources to keep up with vulnerability/patch volume accounted for 29.1%.

"Identifying applicable patches promptly has also become a major structural bottleneck as stacks get more fragmented," he added.

Move to Managed OSS

The report suggests Linux is becoming less visible as users deploy it via platform-as-a-service (PaaS) and containers. As OSS moves toward this indirect consumption model, Karasev noted that responsibility shifts but does not disappear.

"Providers take on more of the underlying OS, platform patching, and lifecycle management, but enterprises still own what they deploy, how they configure it, which images and runtimes they trust, and how quickly they absorb provider-driven updates, deprecations, and aging components," he explained.

He sees the main risk changing form. Instead of organizations running Linux directly and patching it themselves, they depend on someone else’s choices about base images, patching, update cadence, deprecation policy, and transparency.

"That is the new dependency. The data suggests many organizations may not fully recognize it because Linux is increasingly consumed indirectly and is less visible as Linux usage at all," said Karasev.

He agreed that this indicates a permanent shift, with a significant portion of the enterprise landscape always running on 'zombie' end-of-life software.

CentOS and Lifecycle Reality

The continuing resilience of legacy Linux systems also blurs the issues. Consider the situation with the industry-wide CentOS Linux distribution, which has become a "zombie" or ghost distribution.

Karasev declined to call it a debacle for open-source software. Rather, TuxCare's analysis suggests it is a market correction after a major lifecycle transition.

"What happened is that many organizations were forced to make explicit decisions about support, migration, and long-term maintenance for systems that had previously operated on implicit assumptions," he countered.

Red Hat and the CentOS Project effectively discontinued CentOS, shifting the OS from a stable downstream clone to an upstream development branch. The data shows a near-perfect split between those migrating from CentOS and those buying extended support, according to Karasev.

"There will likely be a durable EOL-extension segment in enterprise estates. The near-perfect split between migration or planned migration and purchasing or planning to purchase extended support shows that, for many teams, EOL is not a clean cutoff but a managed state," Karasev said.

CentOS Transition Explained

Based on the 2026 report and historical context, here is the breakdown of what happened:

For nearly 20 years, CentOS was a downstream rebuild of Red Hat Enterprise Linux (RHEL). This meant it was a free, bug-for-bug-compatible version of RHEL, ideal for production environments that need stability without the cost of a RHEL subscription.

In December 2020, Red Hat announced a major change that undermined the viability of its community-supported enterprise. The project would no longer produce stable RHEL clones. Instead, CentOS Stream was born. Its focus shifted upstream of RHEL. Instead of being a copy of what is currently in RHEL, it is a preview of what is coming next in RHEL. This made it less ideal for some stable production environments.

"The CentOS shift exposed how dependent enterprises are on stability at the operating-system layer, and it accelerated a more mature conversation about lifecycle ownership," Karasev said.

What Comes Next for OSS

The CentOS survival story poses long-term security implications for the global software supply chain, driven by pragmatic constraints, according to Karasev. The long-term effect is a shift toward a more diversified support model around open source.

"The implication is that the global OSS estate will likely include a persistent underlayer of legacy dependencies, compatibility-pinned systems, and deferred modernization. The real dividing line is whether that usage is governed and patched, or left to decay," he predicted.

But he cautioned that does not mean all extended-use systems are reckless. An important difference exists between unsupported and abandoned systems, and between systems outside mainstream vendor support but still covered by credible extended support.

"Community distributions, commercial vendors, and ELS providers each play a role. The lesson for the ecosystem is that lifecycle predictability matters just as much as technical quality, especially for foundational infrastructure," Karasev concluded.

Jack M. Germain

Jack M. Germain has been an ECT News Network reporter since 2003. His main areas of focus are enterprise IT, Linux and open-source technologies. He is an esteemed reviewer of Linux distros and other open-source software. In addition, Jack extensively covers business technology and privacy issues, as well as developments in e-commerce and consumer electronics. Email Jack.

Leave a Comment

Please sign in to post or reply to a comment. New users create a free account.

More by Jack M. Germain
More in Security

LinuxInsider Channels