Open Source Security Statistics Guide: Vulnerabilities, Malware and Maintainer Risk

Almost every commercial application is built on open source, but most organisations cannot say how many vulnerable, outdated or abandoned components they ship. This page collects open source security figures we could trace to their publishers: Black Duck's 2026 Open Source Security and Risk Analysis (OSSRA), Sonatype's 2026 State of the Software Supply Chain, GitHub's Octoverse 2025, the Tidelift 2024 State of the Open Source Maintainer Report, the Linux Foundation and Harvard Census III, and CISA. It covers vulnerable and outdated components, ecosystem scale, maintainer capacity and remediation speed. Malicious package counts are covered in the Supply Chain Attack Statistics Guide and only summarised here. Nearly every figure is vendor research, labelled as such in the same row. Written for AppSec leads, platform teams, open source programme offices and security leaders. Last reviewed: November 2026.

Key takeaways

• Open source is in almost everything. Black Duck's 2026 OSSRA found open source in 98% of 947 audited commercial codebases.
• Known vulnerabilities are the norm. 87% of those codebases had at least one open source vulnerability, 78% a high-risk one and 44% a critical-risk one, with a mean of 581 vulnerabilities per codebase, up 107% in a year.
• Stale components are the root cause. 92% of codebases contained components four or more years out of date and only 7% of components in use were the latest version (OSSRA 2026).
• Fixed flaws keep being downloaded. Sonatype counted 42 million downloads of Log4Shell-vulnerable Log4j versions in 2025, years after fixes shipped.
• Maintainer capacity is thin. 60% of maintainers in Tidelift's 2024 survey were unpaid, and unpaid maintainers were far less likely to sign releases or publish a security disclosure plan.

Headline statistics

Statistics by theme

Vulnerable and outdated components

OSSRA codebases come from Black Duck's audits during mergers and acquisitions, so they skew towards software being sold or acquired rather than a random sample. The 17% of components arriving outside package managers matters for defenders: copied-in code, vendored libraries and binaries are invisible to manifest-only dependency scanning and need binary or snippet analysis. See the SBOM Guide.

Ecosystem scale and persistent risk

• Download volume: Sonatype's 2026 report, its eleventh annual edition, puts downloads across the four largest registries at 9.8 trillion in 2025, up 67% year on year, with 86% of Maven Central traffic coming from cloud service providers.
• Log4Shell persistence: Log4Shell-vulnerable versions of Log4j were downloaded 42 million times in 2025 (Sonatype 2026). This is a consumption problem, not a supply problem: fixed versions have been available since December 2021.
• AI-assisted upgrades: in Sonatype's analysis of 37,000 AI-driven upgrade recommendations (June to August 2025), GPT-5 hallucinated 27.8% of component versions. Treat AI-suggested dependency changes as untrusted until validated against the registry.
• Malicious packages: Sonatype logged more than 454,600 new malicious packages in 2025, and 65% of OSSRA 2026 respondents reported a software supply chain attack in the past year (66% of those involved malicious packages, 34% hijacked legitimate ones). Details in the Supply Chain Attack Statistics Guide.

Maintainers and project health

Source for every row: Tidelift, 2024 State of the Open Source Maintainer Report, survey of more than 400 maintainers, published September 2024. The same survey found 60% of maintainers unpaid and 60% had quit or considered quitting. The Linux Foundation and Harvard Census III (December 2024, more than 12 million observations of open source libraries at over 10,000 companies, using data from four software composition analysis vendors) found qualitatively that much of the most widely used open source is developed by only a handful of contributors and that individual developer account security is becoming more important. The XZ Utils Backdoor 2024 shows the risk in practice: a long-running effort to gain a trusted maintainer role put a backdoor into XZ Utils 5.6.0 and 5.6.1 (CVE-2024-3094), and CISA advised downgrading to an uncompromised version such as 5.4.6.

Remediation and tooling on GitHub

The gap between "fix proposed" and "fix shipped" is the useful number: automated pull requests only help if they are merged. See the Dependency Update Automation Guide and the OpenSSF Scorecard Guide.

Licence and AI-related risk

• Licence conflicts: 68% of OSSRA 2026 codebases had open source licence conflicts, up from 56%, the largest single-year rise the study has recorded; one codebase had 2,675 conflicts. See the Open Source Licence Compliance Guide.
• AI coding assistants: about 85% of organisations in OSSRA 2026 used AI coding assistants, and 76% of those that prohibit them reported developers using them anyway. Only 54% evaluated AI-generated code for IP and licensing risk.
• Open source AI models: 97% of OSSRA 2026 respondent organisations used open source AI models in development.

What the numbers mean for defenders

• Measure age, not just CVEs: with 92% of codebases carrying components four or more years old, version lag predicts tomorrow's vulnerabilities. Track it alongside CVE counts and plan regular upgrade windows.
• Find what manifests miss: the 17% of components outside package managers needs binary and snippet scanning, and SBOMs for third-party software.
• Close the merge gap: only about one in three Dependabot fixes ships in the month proposed. Auto-merge low-risk patch updates with tests, and set service levels for critical fixes.
• Block known-bad versions at intake: the Log4Shell figure shows that developers keep pulling vulnerable versions. A repository proxy that blocks versions with critical known vulnerabilities and known malicious packages stops the problem at source. See the Open Source Security Guide.
• Assess project health before adoption: use OpenSSF Scorecard, maintainer count, release signing and disclosure policy as selection criteria, and fund or replace critical projects with one maintainer.

Using the numbers by organisation size

• Small teams: the OSSRA and Sonatype figures still apply because the same registries and libraries are used. Free platform tooling (dependency alerts, automated update pull requests, Scorecard) closes most of the gap; the work is merging the fixes.
• Mid-sized organisations: add a repository proxy, a software composition analysis tool across all repositories and a policy for maximum component age. The 92% outdated figure is the one to beat.
• Large enterprises and software vendors: add SBOM production and exchange, binary analysis for vendored code, an open source programme office and, where you sell products with digital elements into the EU, obligations under the Cyber Resilience Act. See the EU Cyber Resilience Act Guide.

Questions the statistics should prompt

Where identity fits

Many open source compromises are credential compromises: a maintainer's npm or PyPI publishing token, a CI bot's GitHub token or a contributor account that was never removed. Tidelift found two-factor authentication at only 68% among unpaid maintainers and secrets management at 39%. Consumers should prefer packages published with trusted publishing and provenance, and treat their own CI publishing tokens as privileged non-human identities. The Shai-Hulud npm Worm 2025 shows stolen publishing tokens spreading malware across packages. See the Open Source Maintainer Security Guide.

Framework mapping

Common failure patterns when using open source statistics

• Treating OSSRA as a random sample: its codebases come from audits, mostly in transactions. Describe it as "audited commercial codebases".
• Mixing vulnerability and malware counts: a CVE in a legitimate library and a malicious package are different problems with different controls. Keep them in separate rows.
• Quoting downloads as installations: registry download counts include CI rebuilds and mirrors, so 42 million vulnerable Log4j downloads is not 42 million vulnerable systems.
• Comparing vendor figures across publishers: Black Duck, Sonatype and GitHub count different things. Compare a publisher with its own previous edition.
• Reading GitHub fix times as industry fix times: Octoverse measures repositories on GitHub with alerts enabled, a population that already uses tooling.

Methodology notes and caveats

Metrics to track in your own programme

• Critical open source vulnerabilities in production: count and age, with a fix service level.
• Version lag: share of components more than two major versions or four years behind current.
• SBOM coverage: share of production applications with a current SBOM, including third-party software.
• Merge rate of automated fixes: share of dependency update pull requests merged within 30 days.
• Blocked components at intake: monthly count of known-vulnerable or malicious versions blocked by the proxy.
• Single-maintainer critical dependencies: number of critical components with one active maintainer.

Practitioner checklist

• Cite every open source figure with publisher, report, edition and population, and label vendor research.
• Keep vulnerability statistics and malicious package statistics separate.
• Generate SBOMs for your software and request them for critical third-party software.
• Scan binaries and vendored code, not only package manifests.
• Route all package downloads through a proxy that blocks known-vulnerable and malicious versions.
• Set service levels for critical open source fixes and auto-merge tested patch updates.
• Score critical dependencies with OpenSSF Scorecard and review single-maintainer projects.
• Use trusted publishing and short-lived tokens for your own package releases.
• Validate AI-suggested dependency versions against the registry before merging.

Standards and references

• CISA: Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• Linux Foundation: Census III of Free and Open Source Software
• Black Duck: 2026 Open Source Security and Risk Analysis Trends
• Black Duck: Open Source Vulnerabilities Have Doubled as AI Accelerates Code Creation (press release)
• Sonatype: 2026 State of the Software Supply Chain press release
• GitHub: Octoverse 2025
• Tidelift: 2024 State of the Open Source Maintainer Report release

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Top 10 Open Source Software Risks · Vulnerability and Exploitation Statistics Guide · Application Security Statistics Guide · Malicious Open Source Package Response Playbook