How Secure Is Open Source Software? (2026 Data, Trends & Statistics)

Each application has an average of 911 open-source components, many of which are pulled in indirectly through dependency chains. This growing complexity is one reason why teams are shifting toward practices like hardened Docker containers to reduce unnecessary exposure at the infrastructure level.

What stands out in 2026 is not just how many vulnerabilities exist, but how fast they are growing. For the first time in the history of the OSSRA report, the mean number of open source vulnerabilities per codebase has more than doubled in a single year, rising 107% to an average of 581 vulnerabilities.

As adoption grows, so does the question every security team is asking: how secure is open source software really? Let’s look at the data.

Open Source Security Statistics: Usage, Vulnerabilities, and Exposure

Open source software is deeply embedded in modern development. Before looking at security risks, it helps to understand just how widely it is used and how much of today’s software depends on it.

How Widely Is Open Source Used in Commercial Software?

Open source software is not a small part of modern development. It is the foundation most applications are built on.

97% of commercial codebases contain open source, and on average, 70% of scanned code has open source origins. This means that for every 10 lines of code in the average commercial product, 7 were written by the open source community.

The average app today contains three times as many open source files as it did just four years ago. That growth is driven by faster release cycles, more third-party libraries, and AI coding tools that pull in dependencies automatically.

Research commissioned by Canonical and IDC found that seven out of ten organizations consider open source to be “extremely important” for running their mission-critical workloads.

Source: Black Duck OSSRA 2025; Canonical/IDC Research

How Many Open Source Components Have Vulnerabilities?

The majority of applications carry at least one known vulnerability in their open source dependencies. 86% of applications examined in the 2025 OSSRA report contained vulnerable open source components, and 81% had high or critical-risk vulnerabilities.

Mean vulnerabilities per codebase rose from 280 to 581 over the course of a year, more than doubling. The spread between the mean and median points to a long tail of heavily burdened applications, including extreme outliers with tens of thousands of findings.

Not every finding represents equal risk. Most vulnerabilities are medium severity, and many affect code paths that are not reachable at runtime. 

Only around 0.2% of published vulnerabilities are used in ransomware attacks or by advanced persistent threat groups. However, 24.2% of organizations were still exposed to that small subset in 2024.

Source: Black Duck OSSRA 2025 and 2026; Bitsight 2025

Vulnerability Growth Statistics: CVE Trends Over Time

The number of reported vulnerabilities continues to grow each year. This increase is not just about security risks, but also about how much software is being produced and how actively it is being analyzed.

How Many CVEs Are Published Each Year?

The number of publicly disclosed vulnerabilities has increased every year for nearly a decade.

In 2025, 48,185 CVEs were published, a 20.6% increase from 2024’s 39,962. The total number of CVEs since 1999 now stands at 308,920.

2024 marked a 38% jump over 2023, with an average of 108 CVEs published every single day. That volume makes manual vulnerability triage nearly impossible for most security teams, especially given the scale of modern threats highlighted by recent cyberattack statistics. 

Here is how annual CVE volumes have grown year over year:

Source: CVEDetails.com; JerryGamblin.com 2025 CVE Review

Why Are CVE Counts Rising So Fast?

The surge is not purely a sign that software is getting less secure. Several structural factors are driving the increase.

• More code, produced faster. The mean number of files per codebase grew by 74% year-over-year. Roughly 85% of organizations are now using AI-powered coding assistants, reflecting the rapid rise of AI adoption across industries. 76% of companies that explicitly prohibit these tools acknowledge their developers are using them anyway.

• More reporting entities. In 2025, 365 unique CVE Numbering Authorities (CNAs) assigned CVEs. Patchstack alone assigned 7,007 that year, reflecting intense scrutiny on the third-party plugin ecosystem.

• Open source transparency. The Linux Kernel had 3,649 CVEs in 2025, the most of any single product. This reflects the open, transparent nature of kernel development, where every fix is often assigned a CVE, unlike closed-source systems that may bundle or quietly ship fixes.

Dependency Risk Statistics: The Hidden Attack Surface

As applications grow, so does the number of dependencies they rely on. Many of these are introduced indirectly, which can make them difficult to see and control.

What Is the Dependency Explosion Problem?

The 911-component average does not reflect the 911 packages that a development team deliberately chose. Most of them arrived without anyone asking.

64% of open source components in applications are transitive dependencies, meaning they were pulled in by other packages rather than directly imported. Most are near impossible to locate or track without an automated tool.

A team may carefully vet 50 direct libraries. Those 50 libraries quietly bring along hundreds more. Each carries its own vulnerability history and its own update cadence.

According to Chris Hughes, chief security advisor at Endor Labs, the number of vulnerabilities has grown “to where it’s becoming a tax on developers to even navigate what needs to be fixed and what order of priority.”

Source: Black Duck OSSRA 2025

How Does Maintenance Debt Increase Risk?

Outdated components are not just a technical inconvenience. They are a direct vulnerability pathway.

90% of applications audited in the 2025 OSSRA report contain open source components that are more than 10 versions behind the current release. 79% contain components with no development activity in the last 24 months, meaning no maintainer is actively watching for or patching security issues.

An abandoned component does not stop receiving CVEs. It just stops receiving fixes. Over time, unpatched dependencies accumulate known exploits with no remediation path available.

Eight of the top 10 high-risk vulnerabilities found in the 2025 audit were in jQuery, not because jQuery is uniquely insecure, but because so many applications are still running outdated versions of it.

Modern Infrastructure and Emerging Security Challenges

Modern applications are increasingly built using microservices, where functionality is split across many smaller services. This shows how the broader infrastructure expansion is seen in the latest data center and infrastructure statistics.

The approach improves scalability and flexibility, but it also increases the number of components, dependencies, and communication paths that need to be secured.

At the same time, faster development and deployment cycles mean less time for thorough security checks. Updates are shipped more frequently, which can introduce vulnerabilities or leave little room to catch configuration issues before release.

In addition to vulnerabilities in code, misconfigurations have become a common source of risk. Incorrect settings, exposed services, or overly permissive access controls can create security gaps even when the underlying components are secure.

These services are typically packaged and deployed using containers, which concentrate many of these risks into a single unit.

Container Image Security Statistics

Container images combine an application with its dependencies as well as system components. This makes them easy to work with but also increases the security risk.

How Vulnerable Are Docker Container Images?

Container images bundle the operating system, runtime, and application dependencies into a single artifact. That convenience comes with a concentrated security cost.

A 2024 study by NetRise found that commonly used Docker Hub containers contained an average of 604 known vulnerabilities, with more than 45% of them more than two years old.

An analysis of scientific container images published in GigaScience reported a mean of 460 vulnerabilities per image. The authors noted that many images included full operating system distributions and additional unnecessary packages that were rarely updated, creating a much larger attack surface than the application itself required.

Source: NetRise 2024; GigaScience analysis via Chainguard

Where Do Most Container CVEs Actually Live?

The distribution of container vulnerabilities is heavily skewed toward the long tail of lesser-known images, where governance is hardest to enforce.

Chainguard found that only around 2% of CVE instances that were remediated occurred in the top 20 most popular images. The remaining 98% of CVE instances were in images outside that set.

This means the images most organizations rely on for their everyday workloads, the ones outside the well-monitored top 20, are where the bulk of unaddressed risk accumulates. For every CVE fixed in a top-20 image, roughly 50 remain in the long tail.

Selecting a well-known base image does not mean selecting a secure one. Being official and being hardened are not the same thing.

How Organizations Are Reducing Open Source Security Risk

What Approaches Are Most Effective?

Open source security risk is not a fixed condition. It responds directly to the practices organizations adopt.

• Cutting unnecessary dependencies. Every package not present in the codebase cannot be exploited. Auditing and removing unused dependencies reduces the attack surface before scanning begins.

• Starting with minimal base images. Minimal container images, also known as distroless or chiseled images, omit components like shells or package managers that are not needed at runtime. The fewer components in an image, the fewer potential vulnerabilities exist.

• Automating patching workflows. All vulnerabilities found in the 2025 OSSRA audit can be fixed by updating to newer versions of the components. Automated dependency updates close the gap between disclosure and remediation faster than any manual process.

• Deploying SBOMs. A Software Bill of Materials makes it possible to identify whether a newly disclosed CVE affects a given codebase within minutes, instead of spending days tracing dependency trees.

What Are Minimal and Hardened Container Images?

Some providers have built products specifically to address container CVE exposure through image minimization.

Minimus builds images from scratch, directly from upstream project sources, with only what is needed to run the application. Minimus claims its secure, minimal images deliver over 97% fewer CVEs, with default alignment to CIS and NIST benchmarks and compatibility with FIPS 140-3 and STIG workloads. 

At KubeCon North America 2025, the company showcased contractually guaranteed zero CVEs at delivery and 48-hour remediation commitments for new upstream vulnerabilities.

Chainguard takes a comparable approach. During a three-month window in late 2025, Chainguard achieved an average remediation time of under 20 hours for critical CVEs, with 63.5% addressed within 24 hours and 97.6% within two days.

Key Takeaways

• 97% of commercial codebases contain open source software. This makes open source security a universal concern, not a niche one.
• The average application has 911 open source components. Most of them were never explicitly chosen by the development team.
• 86% of applications contain at least one vulnerable open source component. 81% of those have high or critical-severity findings.
• CVE publication hit 48,185 in 2025. That is a 20.6% increase year over year and nearly triple the volume recorded in 2019.
• Mean vulnerabilities per codebase doubled in one year. The figure climbed from 280 to 581, driven largely by AI-accelerated code production.
• Container images are a concentrated risk point. Commonly used Docker Hub images contain an average of 604 known vulnerabilities, with 45% of them over two years old.
• Minimal and hardened images can reduce CVE exposure by over 97%. Providers like Minimus and Chainguard are cutting remediation times to under 24 hours for critical findings.

Conclusion

Open source software is widely used, often complex, and not always well-maintained. Many applications depend on components with known vulnerabilities, but most of these issues can be resolved through regular updates and better visibility.

The challenge is not the availability of fixes, but the processes used to manage them. Organizations that track their dependencies, reduce unnecessary components, and keep systems up to date are better positioned to manage risk.

Open source is not something to avoid. It is something to use responsibly.

FAQs

What percentage of applications contain open source software? 

97% of commercial codebases contain open source, according to the 2025 OSSRA report. Open source is the default foundation of modern software development, not an optional addition.

How many vulnerabilities does the average application have? 

As of the 2026 OSSRA report, the average codebase contains 581 open source vulnerabilities, more than double the 280 recorded the previous year.

Are most open source vulnerabilities critical? 

Not all are equally dangerous. While 81% of audited applications have high or critical-risk vulnerabilities, only about 0.2% of published CVEs are actively used in ransomware attacks or by advanced threat groups. Severity and exploitability context matter when prioritizing remediation.

How many CVEs were published in 2025? 

48,185 CVEs were published in 2025, a 20.6% increase over 2024. The total CVE count since 1999 now stands at 308,920.

Why do container images have so many vulnerabilities? 

Most container images are built on full operating system distributions that include packages the application never uses. Commonly used Docker Hub images average 604 known vulnerabilities, with over 45% of them more than two years old. Switching to minimal or distroless base images is the most direct way to reduce this exposure.

Can open source security risk be reduced significantly? 

Yes. Providers like Minimus report that minimal, source-built container images deliver over 97% fewer CVEs compared to standard alternatives, while also reducing the operational burden of ongoing vulnerability management.

Sources: 

• Black Duck OSSRA 2025
• Black Duck OSSRA 2026
• CVEDetails.com 
• JerryGamblin.com 
• 2025 CVE Data Review
• Canonical/IDC Research
• Chainguard State of Trusted Open Source Report (Q4 2025)
• NetRise Docker Hub Study 2024
• Minimus Help Net Security
• Bitsight 2025 CVE Predictions
• TechRepublic/Endor Labs
• The New Stack
• InfoQ

By Harsha Kiran

Harsha Kiran is the founder and innovator of Techjury.net. He started it as a personal passion project in 2019 to share expertise in internet marketing and experiences with gadgets and it soon turned into a full-scale tech blog with specialization in security, privacy, web dev, and cloud computing.