Everyone uses open source, but patching still moves too slowly
Enterprise security teams rely on open source across infrastructure, development pipelines, and production applications, even when they do not track it as a separate category of technology. Open source has become a default building block in many environments, and the operational risks now look like standard enterprise security problems: patch delays, version sprawl, and aging platforms that stay online longer than planned.
TuxCare’s 2026 Open Source Landscape Report describes an open source footprint that continues to expand through developer-led adoption, with security incidents still closely tied to unpatched vulnerabilities.
Developer tooling drives adoption
Open source adoption in enterprise environments is driven more by development practices than by operating system strategy. Programming languages and developer frameworks show up as the most widely used open source components across organizations, along with databases, container tooling, and cloud-related infrastructure.
This reflects how open source enters the enterprise in practice. Development teams adopt languages, libraries, and tooling for speed and flexibility, then those components become embedded in production systems. Over time, security teams inherit a large dependency chain that may be difficult to map through traditional asset tracking.
“The biggest gap is not knowing what is vulnerable. It is fixing issues fast without breaking production,” Artem Karasev, senior product marketing manager at TuxCare, told Help Net Security. “Too many teams realize they are exposed long before an incident, but still get hit because patches do not make it into deployment in time.”
Karasev said the challenge often comes down to operational constraints that security teams have struggled with for years. “The answer is to make patching fit uptime realities with staged rollouts, strong monitoring, and rollback plans, and to automate the fix workflow, not just the scanning, by assigning owners, standardizing approvals, and baking testing into the pipeline,” he said.
The result is that open source risk management often becomes a byproduct of application security and DevOps operations, tied directly to how software is built and deployed.
Linux remains widespread, but deployments are usually manageable in size
Most organizations report Linux deployments that are significant enough to matter for patching and lifecycle planning, even if the overall fleet size stays relatively modest.
Many deployments cluster in backend services, infrastructure platforms, and development environments. That kind of footprint tends to grow unevenly, with different teams managing different distributions and patch cycles depending on workload requirements.
This creates a common scaling problem: organizations start with Linux fleets that can be managed informally, then grow into an environment where lifecycle planning and centralized patch governance become necessary.
Ubuntu leads, and older distributions remain embedded
Ubuntu is the most widely used Linux distribution among enterprise respondents, with Debian also holding a strong position. The remaining Linux footprint is spread across a mix of enterprise and legacy platforms.
A notable portion of respondents still rely on CentOS, including versions that have already reached end of life. The report also points to significant adoption of community rebuilds such as AlmaLinux and Rocky Linux, reflecting efforts to stay within familiar Linux ecosystems while maintaining stability and compatibility.
Many organizations report running multiple CentOS versions at the same time, suggesting that migration projects often happen in stages. Older systems may remain in production alongside newer ones for long periods, especially when applications cannot be easily revalidated or rebuilt.
Karasev said that this kind of lifecycle drift tends to create compounding problems across security and operations. “At the same time, organizations need tighter control over dependencies and transitive libraries, lifecycle checks that prevent end-of-life surprises, and a clear governance model for extended support so staying on EOL becomes an intentional risk decision, not an emergency,” he said.
Extended support has become a common path forward
Migration away from CentOS has not produced a single dominant replacement path. Organizations are split between moving to other distributions and purchasing extended lifecycle support to keep existing deployments running longer.
The report ties this pattern to common constraints in enterprise IT. Migration work requires time, testing, and staff availability. Application compatibility issues can slow down platform upgrades, and some workloads remain tied to older operating system versions because of business-critical dependencies.
Extended support, in that context, is often treated as a risk management decision. It allows organizations to maintain patch coverage while they work through longer-term modernization projects.
Karasev said extended support is often used as a bridge, even when teams recognize the long-term goal is migration. In many organizations, platform decisions remain tied to operational stability and change control constraints.
Security incidents remain a routine operational reality
Nearly half of surveyed organizations reported experiencing a cybersecurity incident in the past year. A slightly larger share reported no incident during that period, reflecting how incident exposure varies across environments.
The report also indicates that larger organizations report incidents at higher rates than smaller ones, which aligns with the operational reality of larger attack surfaces and more complex production environments. Larger organizations also tend to have stronger detection and reporting, which can increase visibility into events that smaller companies may miss.
This incident rate suggests that open source security is now part of everyday enterprise security operations across many industries.
Unpatched vulnerabilities still drive compromise
A central theme in the findings is that many incidents continue to involve known vulnerabilities where fixes were already available. About six in 10 incident-affected organizations said their most recent incident occurred when a patch existed but had not been applied, showing little change from the prior year.
In many organizations, patching delays remain one of the main contributors to security exposure. Even when organizations have scanning tools and vulnerability intelligence, deployment is often slowed by change management requirements, downtime windows, and the need to validate patches against production dependencies.
Karasev said the pattern is well understood, yet difficult to change without process discipline. “Too many teams realize they are exposed long before an incident, but still get hit because patches do not make it into deployment in time,” he said. He added that many organizations need patching programs built around production uptime expectations, with staged rollouts and rollback options treated as standard operating practice.
Vulnerability management is often limited by workflow and staffing, not by awareness of what needs to be fixed.
In open source environments, the challenge is amplified by dependency depth, fragmented Linux distributions, and long-lived systems that remain tied to older software stacks. Open source has become a foundational layer of enterprise IT, and many organizations continue to operate with patching processes that struggle to keep up. 
Audit expectations are shifting toward evidence and deeper stack inspection
Patch management programs have long been shaped by regulatory requirements, internal governance rules, and compliance deadlines. The report’s findings suggest that many organizations still struggle to execute patching consistently across open source-heavy environments, especially when production systems depend on aging platforms or sprawling dependency chains.
Karasev said the pressure on patching programs is increasing because auditors and buyers are asking different questions than they did a few years ago. “Patch deadlines are not new, especially in regulated environments. What is changing is what buyers and auditors expect as proof, and how deeply they are willing to inspect the software stack,” he said.
He said organizations are being pushed toward more direct technical validation that patching work is being completed. “The trend is more proof and less paperwork, with growing pressure for system-based evidence that updates were actually deployed on time and that exceptions are handled with discipline,” Karasev said.
That shift is also expanding into software procurement and supply chain controls. “We are also seeing SBOMs and software provenance become real purchasing gates, with contracts demanding clearer component origins and lifecycle commitments,” he said.
Karasev said this scrutiny is increasingly focused on dependency management, where many enterprises still lack strong governance. “And the focus is shifting to the dependency layer, pushing controls into CI/CD and component governance, because that is where open source risk accumulates,” he said. “The details will vary by region, but the direction is the same: tighter supply chain requirements and more buyer-driven security clauses.”
Download: Tines Voice of Security 2026 report