San Francisco — July 6, 2026. Five years after the SolarWinds breach put the phrase "software supply chain attack" into boardroom vocabulary, the trend line has not bent downward — it has steepened. Open-source ecosystem monitoring, breach-disclosure databases, and vendor telemetry all point to the same conclusion: attackers have industrialized the process of compromising software before it ever reaches production, and the volume of malicious packages, poisoned build pipelines, and compromised CI/CD credentials is now measured in the tens of thousands per year rather than dozens.
This report pulls together the statistics security teams need to understand the current threat landscape, the incidents that defined the last twelve months, and what the data suggests about where attackers are heading next.
The Numbers Behind the Surge
The headline figure that security teams keep returning to is growth rate, not just raw volume. Sonatype's annual State of the Software Supply Chain research has tracked triple-digit year-over-year increases in malicious open-source packages for four consecutive years, with cumulative malicious package counts across npm, PyPI, and other major registries now well into six figures since tracking began. That growth has outpaced the growth of legitimate package publishing by a wide margin, meaning malicious content is becoming a larger share of the overall ecosystem, not just a larger absolute number.
A few figures worth anchoring on:
- Registry-hosted malware. Automated scanning of npm and PyPI consistently surfaces thousands of net-new malicious or typosquatted packages every month — credential stealers, cryptominers, and dependency-confusion payloads dominate the mix.
- Time to exploitation. For high-severity vulnerabilities in widely used open-source components, the window between public disclosure and observed mass exploitation attempts has continued to shrink, in many cases to under 72 hours, driven by automated scanners that attackers run against the same CVE feeds defenders use.
- Dependency depth. Industry analyses of enterprise codebases consistently find that the majority of exploitable vulnerabilities live two or more levels deep in the dependency tree — components pulled in transitively, without an engineer ever having chosen or reviewed them directly.
- Breach attribution. Multiple annual breach reports now attribute a meaningful and growing share of confirmed intrusions to a third-party or supply-chain vector rather than direct exploitation of the victim's own code, a share that has climbed steadily since 2021.
- Gartner's forward-looking estimate — that a substantial share of organizations globally will have experienced a software supply chain attack by the mid-2020s — is widely cited because it reframed supply chain risk as a "when," not an "if," planning assumption for security leaders, and current incident volume is broadly consistent with that trajectory.
Taken together, the data supports a simple thesis: the software supply chain is no longer a niche attack surface. It is now one of the primary vectors attackers use to reach high-value targets, precisely because it lets them compromise once and propagate to hundreds or thousands of downstream victims.
Anatomy of the Attacks That Defined the Trend
Statistics matter, but the incidents behind them show how the tactics have evolved:
- SolarWinds (December 2020) demonstrated that a nation-state actor could compromise a build system and ship a trojanized update signed with a legitimate certificate, reaching roughly 18,000 downstream organizations.
- Log4Shell (December 2021) showed the blast radius of a single vulnerable open-source library embedded transitively across an enormous share of enterprise Java applications, many of which security teams could not even enumerate at the time of disclosure.
- 3CX (March 2023) was a rare documented case of a "double supply chain compromise" — attackers compromised a software vendor via a trojanized application from an earlier, separate supply chain attack, then used that foothold to poison 3CX's own build pipeline and desktop client.
- The XZ Utils backdoor (discovered March 2024) was arguably the most sophisticated case yet: a threat actor spent roughly two years building trust as a co-maintainer of a widely used compression library before inserting a deliberately obfuscated backdoor into the build process, targeting SSH authentication on Linux systems. It was caught by chance — a Microsoft engineer noticed anomalous CPU usage — not by tooling, which has become the industry's most-cited cautionary tale about maintainer-trust exploitation.
- Polyfill.io (mid-2024) showed the same dynamic playing out in the frontend supply chain: a popular CDN-hosted JavaScript library was acquired and then modified to serve malware to an estimated hundreds of thousands of websites that had embedded a simple script tag years earlier and never revisited it.
The common thread across all five: none of them required attackers to find a novel zero-day in the target's own code. Each one exploited trust — in a vendor, a maintainer, a signed build, or a CDN — that downstream consumers had implicitly extended and never continuously re-verified.
Where the Risk Concentrates
Aggregating incident data from the past several years reveals consistent concentration patterns rather than random distribution:
Build and CI/CD infrastructure is now a preferred target in its own right. Compromising a CI runner, a build-pipeline secret, or a package-publishing token gives an attacker the ability to inject malicious code at the moment of compilation or packaging — a stage most organizations monitor far less rigorously than source code.
Maintainer account takeover — via phishing, credential reuse, or social engineering to obtain publish rights — has become a lower-effort alternative to technical exploitation for reaching downstream victims at scale.
Typosquatting and dependency confusion remain persistently effective because developer tooling still resolves package names with limited friction, and internal package names occasionally collide with public registry namespaces.
SBOM and provenance gaps compound all of the above: numerous post-incident retrospectives across the industry note that affected organizations could not quickly determine whether — or where — a compromised component was in use, extending time-to-containment from hours to weeks.
What the Data Suggests for 2026 and Beyond
Two shifts are visible in more recent telemetry. First, attackers are increasingly targeting the tooling layer — CI/CD platforms, artifact registries, and AI-assisted coding tools — rather than individual application code, because compromising infrastructure shared across many projects yields a far higher return per successful attack. Second, the rise of AI-generated and AI-assisted code has introduced a new variant of dependency risk: coding assistants have been observed suggesting or "hallucinating" package names that do not exist, which threat actors have started pre-registering with malicious payloads — a technique researchers have termed "slopsquatting."
Regulatory pressure is also accelerating in response. Executive Order 14028 and its successor guidance in the U.S., the EU Cyber Resilience Act, and sector-specific SBOM mandates are pushing SBOM generation and vulnerability disclosure from "best practice" to compliance requirement, which is itself changing the statistics — more visibility is now surfacing risk that previously went undetected simply because no one was measuring it.
Why Traditional Scanning Falls Short
Most of the growth in these statistics has happened despite widespread adoption of software composition analysis (SCA) tooling over the past several years — which points to a structural gap rather than a coverage gap. Legacy SCA tools are effective at enumerating known-vulnerable dependencies, but they generally cannot answer the question that actually determines exploitability: is the vulnerable code path in a given dependency actually reachable from the application's own code at runtime? Industry estimates consistently suggest that a large majority of flagged CVEs in a typical dependency tree are not reachable in practice, which means teams chasing raw CVE counts are spending remediation effort on the wrong findings while the small number of truly exploitable issues get lost in the noise.
How Safeguard Helps
Safeguard is built around the gap this report highlights: knowing that a vulnerability exists is not the same as knowing it matters. Safeguard's reachability analysis traces whether vulnerable functions in open-source dependencies are actually callable from your application code, cutting through inflated CVE counts to surface the small fraction of findings that represent real, exploitable risk. Griffin, Safeguard's AI security analyst, continuously correlates that reachability data with runtime context, exposure, and exploit intelligence to prioritize and explain findings the way a senior engineer would. Safeguard generates and ingests SBOMs automatically across your build pipeline, giving teams the provenance visibility that was missing during incidents like XZ Utils and Log4Shell, so a compromised or vulnerable component can be located in minutes rather than weeks. And when a fix is available, Safeguard opens auto-fix pull requests with the minimal, verified change needed — turning remediation from a backlog item into a merge decision.