Software Supply Chain Attack Statistics 2026: Open Source, Dependencies & CI/CD

Executive Benchmark: Software Supply Chain Attack Statistics for 2026

Methodology and Source Confidence

This research prioritizes primary reports, official incident disclosures, standards bodies and regulators. Each statistic stays attached to its original unit, period and denominator.

• Malicious package: a package identified as containing or delivering malicious behavior.
• Package version: one published release of a package; one package can have many versions.
• Download or request: a registry retrieval event; automated builds create many of them.
• Attack: a distinct malicious campaign or compromise, counted by each source’s own rules.
• Incident: a security event reported by an organization or survey respondent; it does not always mean data was exposed.
• Breach: confirmed unauthorized access to or disclosure of data.
• Affected organization: a downstream entity impacted by an upstream compromise.

How Common Are Software Supply Chain Attacks?

No defensible single percentage answers “how many software supply chain attacks occur.” The strongest current sources observe different layers of the ecosystem, so each answers a different question.

StepSecurity tracked 56 confirmed attacks in 12 months

StepSecurity counted 56 distinct supply chain attacks between August 2025 and August 2026, each backed by a Threat Center alert. Six fell in the first six months (August 2025 to January 2026) and 50 from February 2026 onward, which the report calls more than an 8x increase. Monthly counts it lists include 13 in March, 9 in April, 9 in May, 10 in June and 6 in July. Since March 2026 the report puts the pace at roughly one attack every three days.

The corpus covers npm, PyPI, RubyGems, Composer and crates.io, plus poisoned GitHub Action tags and IDE extensions. It excludes vulnerability disclosures, unconfirmed events and brand-new typosquats, so it counts only attacks on components developers already trusted.

77% of surveyed organizations reported a supply chain incident

Omdia surveyed 400 IT, cybersecurity and application professionals across North America in February 2026 for Docker. 77% said their organization had a software supply chain incident in the prior 12 months, and the most common type (38%) involved exploitation of known vulnerabilities in third-party software. This is self-reported survey evidence, not a confirmed-breach corpus.

Third-party involvement reached 48% of breaches in the 2026 DBIR

Verizon’s 2026 DBIR, built on 31,000+ incidents and 22,000+ confirmed breaches in 145 countries, found third-party involvement in 48% of breaches, up 60% on last year’s dataset. Verizon links the rise to growing reliance on third parties for services and software. It measures any third-party involvement, so it should not be quoted as the share of breaches caused by software supply chain attacks. For the full vendor-risk picture, see ScanTitan’s third-party data breach statistics.

Supply Chain Attacks vs. Malicious Packages vs. Vulnerable Dependencies

These four terms are routinely mixed together even though they describe different risks.

The distinction matters for incidents such as Log4Shell. A vulnerable third-party dependency can create massive shared exposure without any malicious package campaign, while a self-propagating npm worm is a true supply chain attack even if it never produces a reportable data breach at every installation it touches.

Open-Source Malware Statistics in 2026

Sonatype’s quarterly indexes give the clearest current view of malicious-package activity. The pattern changed fast during 2026, which makes annualizing a single quarter risky.

Q1 2026: 21,764 malicious packages, 75% on npm

Sonatype identified 21,764 malicious packages in Q1 2026, bringing its cumulative total to 1,346,867, and put npm at 75% of the quarter. It described this as one new malicious package every six minutes.

Q2 2026: npm reached 96.6% of malicious-package volume

By the end of Q2 Sonatype’s catalog passed 1.8 million packages and npm represented 96.6% of the quarter. Among non-npm activity, nearly 87% sat in two ecosystems: PyPI (48.5%) and NuGet (38.0%).

Q3 2026: 149,329 packages in one quarter

Sonatype logged 149,329 malicious packages in Q3, taking the cumulative total to 1,960,846. npm held 89.5% (133,579 packages). Of 27,618 packages with at least one overtly malicious behavior, Sonatype states 74.5% involved droppers, secrets exfiltration or both. Its threat-type table lists 14,665 droppers and 9,863 secrets-exfiltration packages and a separate 68.1% figure without a stated denominator, so do not compare the two percentages.

What malicious packages actually do: repository abuse leads 2025

Across all malicious packages Sonatype logged in 2025, 55.9% showed repository abuse such as spam or squatting. The behavior shares it lists are shown below as published.

Source: Sonatype 2026 State of the Software Supply Chain. Categories are reported by Sonatype and may overlap, so do not sum them.

How Large Is the Open-Source Ecosystem?

Software reuse amplifies the attack surface. Sonatype recorded 9.8 trillion downloads or requests in 2025 across Maven Central, PyPI, npm and NuGet. That is registry traffic, not 9.8 trillion unique packages or developers, because automated pipelines repeatedly resolve the same dependencies.

Source: Sonatype 2026, Software Infrastructure Growth.

Sonatype vs. ReversingLabs: Why Package Counts and npm Shares Differ

Sonatype identified 454,600+ malicious packages in 2025. ReversingLabs separately reported a 73% increase in detections of malicious open-source packages in 2025, with npm up more than 100% to 10,819 packages, nearly 90% of its detections across platforms. It also reported malware detected on PyPI and NuGet fell 43% and 60%.

The same gap appears in the npm share. Sonatype’s annual report says over 99% of the open-source malware it logged in 2025 was on npm, while its quarterly shares for 2026 were 75%, 96.6% and 89.5%, and ReversingLabs says nearly 90%. These are different windows and different detection systems.

Which Package Ecosystems Are Most Targeted?

npm is the strongest concentration point in every dataset reviewed. StepSecurity also calls npm the biggest target, and Sonatype’s 2026 shares range from 75% to 96.6% by quarter.

Why npm attracts so much supply chain abuse

Several features make npm attractive: huge package and download volume, automated dependency installation, install-time scripts, deep transitive dependency trees, and developer credentials and registry tokens that live in build environments. The point is concentration of trust, not that npm is uniquely unsafe: a stolen maintainer account or compromised release inherits the original package’s reputation and reach. For the technical mechanics, see ScanTitan’s JavaScript npm supply chain attack guide.

How Software Supply Chain Attacks Happen

Software supply chain compromise is better understood as a taxonomy of attack paths than as one vulnerability class.

1. Maintainer and publisher account takeover

Attackers steal registry, GitHub or developer credentials and use legitimate publishing rights to release malicious versions that keep the package’s name and history.

2. Compromised legitimate packages

A package can keep working while malicious code runs at install or build time, so historical reputation does not prove the exact version being installed is safe.

3. Dependency confusion

Attackers publish public packages that mimic internal dependency names, often with very high version numbers. Sonatype documented a May 2026 campaign of 176 malicious npm packages, many at version 99.99.99, built to win automated resolution races. Their install scripts collected environment variables and CI/CD secrets before fetching a second-stage binary.

4. Typosquatting and brandjacking

Lookalike package names remain a familiar technique, now often combined with credential theft. StepSecurity excludes brand-new typosquats from its confirmed-attack count, which is one reason its total is far below package-level counts.

5. CI/CD and build-system compromise

An attacker who controls a build runner, workflow or release job can weaponize software without obviously altering source code. Build systems hold repository tokens, cloud credentials and registry secrets.

6. Mutable GitHub Actions and build dependencies

GitHub’s Actions security roadmap cites incidents involving tj-actions/changed-files, Nx and trivy-action and describes attackers targeting CI/CD automation itself. Workflows that reference mutable tags can run code that changed after review.

7. Software update and distribution compromise

SolarWinds remains the canonical case: malicious code entered a trusted update path, so customers received it through an expected channel.

8. Double supply chain attacks

In the 3CX case, Mandiant traced the compromise to an employee installing trojanized X_TRADER software on a personal computer, after which attackers reached 3CX’s build environments.

CI/CD and GitHub Actions Supply Chain Attacks

Build systems combine code execution with privileged credentials, which makes CI/CD one of the most important trust boundaries. GitHub’s March 2026 roadmap describes a repeating playbook: untrusted code reaches workflows, malicious workflows run without observability, compromised dependencies spread across repositories, and over-permissioned credentials are stolen through unrestricted network access.

tj-actions/changed-files exposed secrets in workflow logs in March 2025

CISA tracked the compromise as CVE-2025-30066, which allowed information disclosure of secrets. Versions used between 12 March 2025 00:00 UTC and 15 March 2025 12:00 UTC were affected. CISA listed leaked credential types including access keys, GitHub personal access tokens, npm tokens and private RSA keys, noted the payload could hide as double-encoded base64, and added both this CVE and the related reviewdog/action-setup compromise (CVE-2025-30154) to its Known Exploited Vulnerabilities catalog. The patched version is v46.0.1. CISA gives no count of affected repositories or leaked secrets, so none is quoted here.

Useful controls include pinning dependencies to immutable commit SHAs or digests, minimizing token permissions, using short-lived credentials, restricting runner network access, verifying artifacts and keeping an inventory of third-party workflow dependencies.

Self-Propagating Package Malware and Supply Chain Worms

One of the biggest changes in 2025 and 2026 is package malware that uses stolen credentials to compromise more trusted packages. ReversingLabs reported that Shai-Hulud compromised more than 1,000 npm packages across two campaigns and exposed an estimated 25,000 GitHub repositories.

Shai-Hulud Miasma reached 304 components within two days

Sonatype’s 4 June 2026 post cited 281 malicious package versions, and its 5 June update raised the total to 304 impacted components. The malware searched for GitHub access tokens, registry authentication tokens and cloud secrets, checked whether stolen credentials worked, and used maintainer credentials to publish malicious artifacts.

Mini Shai-Hulud: 2,225 component versions tracked in August 2026

After Shai-Hulud re-emerged on 4 August 2026 in the keyv and cacheable ecosystems on npm, Sonatype tracked 2,225 component versions and called the count a current snapshot, not a final tally. The malware runs through a preinstall hook, steals npm, GitHub, cloud, Kubernetes, Vault and CI/CD credentials, then republishes other packages with the same hook.

Vulnerable Open-Source Dependencies: The Larger, Quieter Exposure

Most dependency risk is not malicious. It is ordinary vulnerabilities in legitimate components that applications inherit. Black Duck’s 2026 OSSRA audited 947 codebases submitted between November 2024 and October 2025.

Source: Black Duck 2026 OSSRA.

Log4j: 13% of 2025 downloads were still vulnerable versions

Sonatype reports that vulnerable Log4j versions made up 13% of all Log4j downloads worldwide in 2025, and that 14% of Log4Shell-affected artifacts are now end of life, representing more than 619 million downloads. Its 2024-edition analysis found about 95% of vulnerable component downloads already had a fix available. Checking whether your own software has reached end of life is a quick first step; ScanTitan’s software end of life checker does that.

About 65% of open-source CVEs had no NVD severity score

Sonatype’s analysis found about 65% of open-source CVEs had no NVD-assigned CVSS score, NVD’s median time to score was 41 days, and Sonatype rated 46% of the unscored CVEs High or Critical. Scanners that depend only on NVD scores can therefore miss severity signals for a long time.

Exploitation and Time to Patch

The 2026 DBIR makes the dependency problem concrete. Exploitation of vulnerabilities is now the most common initial access vector for breaches at 31%, ahead of credential abuse at 13%. Phishing stayed at 16% of all breaches and pretexting reached 6%.

Source: Verizon 2026 DBIR Executive Summary. These figures cover all organizations and all vulnerabilities in KEV, not only supply chain components.

Prioritizing by exploitation evidence rather than raw CVSS is the practical consequence. ScanTitan’s CVE priority checker is built for that kind of triage.

Third-Party Breach Share by Industry

Verizon’s executive summary reports third-party involvement per industry. The shares differ widely, partly because industries rely on outsourced software and services to different degrees.

Source: Verizon 2026 DBIR Executive Summary. Each share is within that industry’s breach dataset.

How Much Does a Software Supply Chain Breach Cost?

IBM’s Cost of a Data Breach Report 2026 studied 602 breached organizations with breaches between March 2025 and February 2026, conducted by Ponemon Institute. It names supply chain compromise, meaning attacks that use trusted third-party software or other resources, as the second most common initial attack vector, after phishing for the fourth year running.

Sources: IBM Cost of a Data Breach Report 2026; IBM, What Is an Attack Vector for the 2025 value.

These are benchmarks for IBM’s supply chain compromise category. They are not the average cost of a malicious npm package or of every software supply chain attack.

Enterprise Software Supply Chain Survey Statistics

The Omdia study sponsored by Docker adds an organizational view that malware telemetry cannot. It surveyed 400 professionals in North America in February 2026.

Source: Docker, Omdia 2026 report findings. Percentages describe respondents, not global breach statistics.

SBOM and Software Supply Chain Visibility Statistics

A Software Bill of Materials (SBOM) is an inventory of the components in a software artifact. Its security value is visibility: without it, answering “are we running the compromised version” takes days.

Among Omdia respondents whose organizations generate SBOMs, only 42% do so as a mandatory step for every application, while 55% generate them case by case. Respondents associated SBOMs with these benefits (the survey does not state the base for these three):

• 73%: more efficient vulnerability mitigation
• 72%: implementing security controls and processes
• 68%: meeting compliance requirements

An SBOM does not prove a component is safe. It provides the inventory needed to ask whether this exact component, version or build artifact is affected.

AI and Software Supply Chain Risk

In the Omdia survey, 40% ranked AI technology as the top software supply chain risk, slightly ahead of third-party and open-source code (39%) and software dependencies (38%). That is risk perception, not incident data.

GPT-5 hallucinated 27.8% of component versions in Sonatype’s test

Sonatype analyzed 37,000 AI-driven dependency upgrade recommendations from June to August 2025 and reported that GPT-5 hallucinated 27.8% of component versions and suggested actual malware packages when operating without real-time intelligence. The result applies to that condition and that test, not to AI coding assistants in general, and Sonatype reports its results as point-in-time snapshots.

The concern is speed: AI-assisted development can add dependencies and change build workflows faster than manual review. Dependency verification, provenance and policy enforcement matter more as the pace rises.

Major Software Supply Chain Attacks in 2025 and 2026

Trivy: a security scanner became the delivery path

Docker reported that Docker Hub customers who pulled aquasec/trivy tags 0.69.4, 0.69.5, 0.69.6 or latest between 18:24 UTC on 19 March and 01:36 UTC on 23 March 2026 may have exposed CI/CD secrets, cloud credentials, SSH keys and Docker configuration. Docker said its own infrastructure and other images were not compromised and that the issue was isolated to Aqua Security’s images. The last known clean release was 0.69.3. A trusted security tool executing in CI/CD can reach exactly the secrets attackers want.

Most Important Historical Software Supply Chain Attacks

Historical cases are most useful when they show different trust failures, not when ranked by one headline number.

SolarWinds: up to 18,000 could have received the update, fewer than 100 were hacked

SolarWinds first reported up to 18,000 customers could have been vulnerable to SUNBURST, based on downloads of the affected Orion versions, and later estimated that fewer than 100 were actually hacked. It said the larger group included customers who never installed the download and those whose servers could not reach the command-and-control server. It is the clearest example of why distribution counts are not compromise counts.

Codecov: CI/CD secrets were the prize

Codecov said attackers modified its Bash Uploader so it extracted git remote origin URLs and environment variables. The root cause was an HMAC key for a Google Cloud Storage service account extracted from an intermediate Docker image layer and used to alter the uploader. Codecov was alerted on 1 April 2021 after a customer noticed a checksum mismatch.

Kaseya: fewer than 60 direct victims, fewer than 1,500 downstream businesses

Kaseya said attackers exploited zero-day vulnerabilities in VSA on-premises to bypass authentication and run arbitrary commands, then used VSA’s own functionality to deploy ransomware. Kaseya reported fewer than 60 directly compromised customers and fewer than 1,500 downstream businesses, and found no evidence its VSA codebase was maliciously modified. The ratio shows how management tooling multiplies reach.

3CX: one supply chain attack caused another

Mandiant found the 3CX compromise began in 2022 when an employee installed trojanized X_TRADER software on a personal computer. The attackers stole the employee’s corporate credentials, reached 3CX through the VPN two days later, and compromised both the Windows and macOS build environments.

XZ Utils: malicious code lived only in the release tarballs

Red Hat documents malicious code in xz upstream tarballs from versions 5.6.0 and 5.6.1, scored CVSS 10 (CVE-2024-3094). The code was in the downloadable tarball and not in the Git source, a reminder that a release artifact can differ from the repository it claims to come from.

Software Supply Chain Regulations and Standards in 2026

CRA reporting started on 11 September 2026

Manufacturers covered by the EU Cyber Resilience Act must now send an early warning within 24 hours and a full notification within 72 hours of becoming aware of an actively exploited vulnerability or severe incident. The final report is due 14 days after a fix for exploited vulnerabilities, or within a month of the 72-hour notice for severe incidents. Obligations for open-source software stewards begin on 11 December 2027.

OWASP ranks supply chain failures third, with 50% of the community survey putting them first

OWASP Top 10:2025 lists Software Supply Chain Failures as A03. In its community survey exactly 50% of respondents ranked the category first. OWASP’s data shows 215,248 occurrences and maps the category to 6 CWEs and 11 CVEs. The 50% measures what practitioners worry about most, not the share of breaches caused by supply chain failures.

Software Supply Chain Statistics Commonly Misquoted

What the Numbers Mean for a Lean Team

For a small IT or security team, the data points to a short list of controls. First, inventory what you run: an SBOM, or at least a list of direct and transitive dependencies per application. Second, treat build systems as production: pin actions and images to immutable digests, give pipeline tokens the minimum permissions and prefer short-lived credentials. Third, patch by exploitation evidence, since only 26% of KEV vulnerabilities were fully remediated in the DBIR dataset and the median fix took 43 days. Fourth, assume a trusted package can ship a bad version and add checks that look at the exact version and its behavior.

Most of these controls live in your code and pipelines. For the internet-facing side, ScanTitan’s JavaScript vulnerability scanner checks the JavaScript your public sites serve, and ScanTitan’s website security statistics cover internet-facing application exposure. They do not replace dependency scanning, SBOM generation or CI/CD hardening, and broader vulnerability data is in ScanTitan’s vulnerability statistics.

How We Compiled and Verified These Statistics

Every figure on this page was checked against the named source on 15 October 2026. Vendor telemetry (Sonatype, ReversingLabs, StepSecurity, Black Duck) is reported as that vendor’s own measurement, in its own unit, and never combined with another vendor’s. Where a source gives a figure without a stated denominator, the text says so.

• Used: vendor and publisher primary pages, Verizon’s DBIR 2026 executive summary and news release, IBM’s 2026 report, CISA, NIST, the European Commission, OWASP and the original incident disclosures.
• Excluded: third-party summaries of other companies’ research, forecasts (including Gartner and Cybersecurity Ventures projections), and the 267-day and 15% IBM figures that circulate for 2025, because they could not be confirmed in IBM’s own pages.
• Superseded: IBM’s 2025 report is shown only as a prior-year reference now that the 2026 report is published.
• Refresh: Sonatype publishes quarterly, so this page is reviewed every 90 days, with the next check due in January 2027.

Primary Sources

• Sonatype, Q3 2026 Open Source Malware Index
• Sonatype, Q2 2026 Open Source Malware Index
• Sonatype, Q1 2026 Open Source Malware Index
• Sonatype, 2026 State of the Software Supply Chain: Open Source Malware
• Sonatype, 2026 Software Infrastructure Growth
• Sonatype, 2026 Vulnerability Management
• Sonatype, 2026 report press release (AI recommendations)
• Sonatype, 176-package dependency-confusion campaign
• Sonatype, Shai-Hulud Miasma
• Sonatype, Mini Shai-Hulud
• StepSecurity, State of Open Source Supply Chain Attacks
• Docker / Omdia, 2026 Software Supply Chain Security Report
• Docker, Omdia 2026 report findings
• ReversingLabs, 2026 report press release
• ReversingLabs, 2026 report takeaways
• Black Duck, 2026 OSSRA
• Verizon, 2026 DBIR news release
• Verizon, 2026 DBIR Executive Summary
• IBM, Cost of a Data Breach Report 2026
• IBM, What Is an Attack Vector
• OWASP Top 10:2025, A03 Software Supply Chain Failures
• GitHub, Actions 2026 Security Roadmap
• CISA, tj-actions/changed-files compromise (CVE-2025-30066)
• Docker, Trivy supply chain compromise
• Codecov, April 2021 post-mortem
• Kaseya, VSA incident overview
• 3CX, Mandiant initial intrusion vector
• Red Hat, CVE-2024-3094 (XZ Utils)
• SolarWinds, investigative update on SUNBURST
• European Commission, Cyber Resilience Act reporting obligations
• NIST SP 1326, C-SCRM Due Diligence Assessment Quick-Start Guide

Frequently Asked Questions