Software supply chain attacks surged at the end of 2025, with 41 attacks uncovered in October alone. And there was an unmistakable pattern. Attackers stopped trying to breach organizations directly and instead focused on opportunities for widespread impact. 

Why pick one lock when you can compromise a widely-used library and walk through thousands of doors at once? From npm worms to GitHub Actions attacks, we got a clear view of where software supply chain defense is headed.

The Top Software Supply Chain Attacks of 2025

The five most consequential attacks of 2025 exploited vendors, dependencies, and build systems. The economics favor attackers here. The multiplier effect made software supply chain attacks a preferred vector for both nation-state actors and ransomware groups throughout 2025.

1. Cl0p Exploitation of Cleo File Transfer Zero-Day

The Cl0p ransomware group exploited a zero-day vulnerability in Cleo’s file transfer products, affecting at least 66 confirmed organizations, though the actual number is likely higher. The attack targeted a core enterprise platform used across IT services, manufacturing, and logistics.

What made this incident particularly damaging was the lack of visibility. Organizations discovered they had no idea which business processes depended on the compromised platform, leading to chaotic, slow incident response. A single vulnerability in widely-deployed enterprise software created a massive blast radius.

2. Shai-Hulud npm Worm and Ecosystem Compromises

The first successful self-propagating npm worm compromised maintainer accounts and auto-published malicious versions of over 500 packages. The attack spread to hundreds of GitHub repositories and even reached a Maven mirror.

For context, npm is the package manager for JavaScript—the world’s most popular programming language. When attackers poison npm packages, they inject malicious code into applications used by millions of people. 

The Shai-Hulud worm specifically targeted developer environments, stealing secrets and poisoning dependencies across multiple ecosystems. It was a worm that kept on spreading.

“What unfolded was a demonstration of how a single point of compromise, when paired with today’s automated build and publishing pipelines, can snowball into an ecosystem-spanning attack,” said Joseph M. Saunders, RunSafe Security Founder and CEO, about Shai-Hulud 2.0.

3. tj-actions GitHub Actions Supply Chain Breach

Popular GitHub Action tags were repointed to a malicious commit that exfiltrated CI/CD secrets from any build depending on those tags. GitHub Actions are reusable automation components that organizations embed in their build pipelines, often without reviewing the underlying code.

The attack exploited a fundamental trust assumption: that tagged releases remain immutable. When attackers modified what a tag pointed to, every organization using that Action unknowingly pulled malicious code into their builds. The breach demonstrated how CI/CD infrastructure has become a high-value target.

4. GlassWorm VS Code Extension Attack

GlassWorm became the first known worm designed to spread via the VS Code extension supply chain. It used invisible Unicode-based code injection to hide malicious logic in otherwise normal-looking extension source code.

Once installed, compromised extensions stole credentials for npm, GitHub, and Git, then dropped a remote-access trojan. Because VS Code extensions auto-update by default, the malware spread silently through developer workstations. The attack established command-and-control using Solana blockchain transactions and Google Calendar events, making takedown extremely difficult.

5. PhantomRaven npm Campaign

The PhantomRaven campaign deployed 126 malicious npm packages using “slopsquatting” names, or typos of popular packages that developers might accidentally install. The packages accumulated roughly 86,000 downloads before detection.

Unlike the explosive Shai-Hulud worm, PhantomRaven operated quietly, stealing npm tokens and CI/CD secrets to seed long-lived compromise into development pipelines. The patient approach made detection harder and extended the window of exposure considerably.

Software Supply Chain Attack Examples Across the Years

While 2025 marked an inflection point for software supply chain risk, it was not the beginning. Many of today’s attack patterns were previewed in earlier, high-profile software supply chain attack examples that are shaping how the security community thinks about trust, dependencies, and upstream risk.

NotPetya via MeDoc Software Updates (2017)

One of the earliest and most destructive software supply chain attack examples occurred in 2017, when attackers compromised MeDoc, a widely used Ukrainian tax accounting application.

The attack caused massive global disruption at organizations including Maersk, Merck, FedEx (TNT Express), and Mondelez, with total damages estimated at over $10 billion.

Why it mattered:
NotPetya demonstrated that software supply chain attacks could be both highly scalable and irreversibly destructive, establishing the modern blueprint for abusing trusted software updates.

ASUS Live Update Utility Compromise (ShadowHammer) (2018–2019)

In the ShadowHammer campaign, attackers compromised the ASUS Live Update Utility, inserting malicious code into signed firmware and software updates distributed to customers worldwide.

Because the updates were signed with legitimate ASUS certificates, the malware bypassed traditional endpoint defenses. The attack was also highly targeted, activating only on systems with specific MAC addresses.

More than 500,000 systems are believed to have received trojanized updates, although only a subset were fully exploited.

Why it mattered:
This software supply chain attack example highlighted that code signing alone is insufficient and that hardware vendors and update tools represent powerful upstream compromise points, especially in firmware and embedded ecosystems.

SolarWinds Orion Attack (2020)

The SolarWinds attack remains one of the most frequently cited software supply chain attacks in history. Threat actors inserted malicious code into updates to the SolarWinds Orion network management platform, which was then distributed to thousands of customers.

Once installed, the backdoor enabled long-term espionage across government agencies and major enterprises.

Why it mattered:
SolarWinds elevated software supply chain security to a board-level and regulatory priority, driving zero-trust adoption and renewed scrutiny of vendor trust.

Log4Shell (Log4j) Vulnerability (2021)

The Log4j vulnerability exposed a critical weakness in the Apache Log4j logging library, a dependency embedded in countless Java applications.

Attackers could achieve remote code execution simply by sending crafted log messages, often without authentication.

Why it mattered:
Log4j underscored the visibility crisis in software supply chains, as many organizations did not know where Log4j was running, accelerating demand for SBOMs and dependency inventories.

CircleCI CI/CD Breach (2023)

Attackers compromised CircleCI’s internal systems, exposing customer secrets stored in CI/CD pipelines and forcing mass credential rotation.

Why it mattered:
This incident showed that build systems and CI/CD platforms are prime software supply chain targets, as they grant access to production secrets and downstream environments.

MOVEit Transfer Exploitation (2023)

The Cl0p ransomware group exploited vulnerabilities in MOVEit Transfer, a widely deployed managed file transfer solution.

Over 620 organizations were affected, including airlines, financial institutions, and government entities.

Why it mattered:
MOVEit reinforced how attackers increasingly target enterprise infrastructure software to achieve scale through a single upstream compromise.

Okta Support System Breach (2023)

Threat actors accessed Okta’s customer support environment using stolen credentials and stole sensitive data uploaded to support cases while remaining undetected for weeks.

Why it mattered:
This supply chain attack example expanded the definition of supply chain risk beyond code to include SaaS platforms and operational tooling.

JetBrains TeamCity CI/CD Attack (2023)

Attackers exploited an authentication bypass vulnerability in JetBrains TeamCity, enabling remote code execution and administrative control of CI/CD servers.

Thousands of exposed instances were identified globally.

Why it mattered:
The incident reinforced the danger of internet-exposed build infrastructure and slow patch adoption in CI/CD environments.

XZ Utils Backdoor (2024)

A malicious contributor inserted a stealthy backdoor into XZ Utils, a low-level compression library used by major Linux distributions.

The backdoor enabled unauthorized SSH access and was narrowly discovered before widespread exploitation.

Why it mattered:
XZ Utils demonstrated how low-level open-source components can become high-impact supply-chain attack vectors, even without widespread exploitation.

Malicious npm Package Campaigns (2024)

Attackers published malicious npm packages designed to steal SSH keys, credentials, and tokens from developers, in some cases attempting post-exploitation activity.

Why it mattered:
These campaigns foreshadowed the self-propagating npm worms of 2025, highlighting the persistent fragility of developer package ecosystems.

How Attackers Break the Software Supply Chain

Across incidents in 2025 and prior years, attackers exploited the same structural weaknesses in modern development and delivery pipelines.

The table below summarizes the most common attack vectors, their primary targets, and representative incidents.

CI/CD Pipeline and Build System Compromise

CI/CD systems are force multipliers. When attackers inject malicious code into a build pipeline, every downstream artifact inherits the compromise. Because these systems are implicitly trusted, tampering often goes unnoticed until distribution is already complete.

The tj-actions breach illustrated this clearly: by hijacking a widely reused GitHub Action, attackers exfiltrated secrets from countless downstream builds. Organizations lacked sufficient integrity checks, signed builds, or provenance validation to detect the manipulation early.

Dependency Confusion, Typosquatting, and Registry Abuse

Modern software relies heavily on third-party packages, which are automatically resolved by package managers. Dependency confusion exploits this trust by tricking systems into pulling malicious packages from public registries, while typosquatting relies on simple naming mistakes by developers.

The Shai-Hulud worm demonstrated how these techniques scale when combined with automation. Once a malicious package entered the ecosystem, CI/CD pipelines and publishing scripts rapidly propagated it across hundreds of projects, long before defenders could react.

OAuth Token Theft and SaaS Integration Abuse

OAuth enables productivity by allowing applications to access systems without sharing passwords, but it also creates powerful lateral-movement paths. When attackers compromise a third-party integration with OAuth access, they often gain silent, persistent access across multiple connected platforms.

Salesforce-related breaches in 2025 showed how OAuth token abuse can bypass traditional perimeter defenses and evade detection, especially when security teams assume SaaS platforms are “someone else’s problem.”

IDE and Extension Ecosystem Attacks

Developer workstations are high-value targets because they combine access to source code, credentials, and deployment authority. Compromised IDE extensions offer persistence, often survive reboots, and frequently evade endpoint detection.

GlassWorm confirmed that IDE ecosystems are no longer theoretical attack surfaces. By abusing extension marketplaces and auto-update mechanisms, attackers gained durable access to developer environments and the credentials stored within them.

Firmware and Appliance Software Supply Chain Attacks

Firmware attacks target the lowest layers of software, which is code that runs before the operating system loads. In embedded and appliance environments, updates are infrequent, verification mechanisms are weak, and compromise can persist for years.

Supermicro BMC vulnerabilities and similar incidents highlight how firmware supply chain risk extends beyond enterprise IT into critical infrastructure, where patching delays and long device lifecycles dramatically increase exposure.

Together, these gaps explain why software supply chain attacks are so effective. Attackers are abusing trust, automation, and opacity built into modern development ecosystems.

Closing the Gaps: How Organizations Can Stop the Next Software Supply Chain Attack

Examples of software supply chain attacks make it clear that preventing the next breach requires addressing the systemic weaknesses attackers exploit across development, build, and runtime. 

• Enhance Transparency with SBOMs:  A Software Bill of Materials (SBOM) provides visibility into all software components and dependencies, enabling teams to quickly assess exposure when a vulnerability or software supply chain attack emerges. Automated SBOMs are especially critical for compiled binaries and embedded software, and are increasingly required by regulators like the FDA and the EU Cyber Resilience Act.
• Harden the Build Environment: Compromised build systems can poison every downstream artifact, making CI/CD infrastructure a high-value target. Controls such as network segmentation, immutable build environments, and just-in-time secrets access significantly limit attacker persistence and blast radius.
• Apply Runtime Protection Against Unknown Exploits: Zero-days and malicious packages will inevitably slip through. Runtime protections that block exploitation techniques, rather than relying on known signatures, reduce impact when patching is delayed or impractical, particularly in embedded and critical infrastructure environments.
• Adopt Continuous Monitoring and Incident Response: Continuous monitoring helps detect unexpected dependency changes, newly disclosed vulnerabilities, and anomalous runtime behavior, enabling faster containment and reduced downstream damage.

Where Will Software Supply Chain Security Take Us in 2026?

If 2025 was the year software supply chain attacks went mainstream, 2026 will be the year organizations are judged on how well they adapted.

AI is also accelerating risk. AI-assisted development increases software velocity but also expands the attack surface, introduces opaque dependencies, and makes it easier for adversaries to discover weak links across ecosystems. 

In 2026, software supply chain risk will grow not just in volume, but in speed and complexity.

The organizations that succeed will be those that act on what 2025 made painfully clear:

• Security must be built into software from the start
• Visibility into dependencies, build processes, and runtime behavior is no longer optional
• CI/CD systems, developer tools, and embedded firmware must be treated as high-value attack surfaces
• Runtime protections are essential when patching is delayed or impossible

What steps are you taking to assess and strengthen your software supply chain?

Request a consultation to assess your software supply chain security posture and learn how RunSafe is protecting embedded systems across critical infrastructure against the next attack.

Grab a copy of our white paper: “Reducing Risk in Your Software Supply Chain: Addressing Open Source, Emerging Threats, and Regulatory Shifts.”

Frequently Asked Questions About Software Supply Chain Attacks

How do Software Bills of Materials help organizations respond to software supply chain incidents?

SBOMs provide the inventory needed to quickly identify affected systems when a compromised component is discovered, turning days of investigation into minutes of automated queries.

Which compliance frameworks now require software supply chain security controls?

FDA guidance for medical devices, DoD requirements for defense contractors, and the EU Cyber Resilience Act all mandate supply chain security controls, with SBOM requirements becoming increasingly specific.

How do software supply chain attacks on embedded systems differ from enterprise IT attacks?

Embedded systems face longer device lifecycles, an inability to easily patch deployed units, and safety-critical implications that make compromise potentially life-threatening rather than merely costly.

What are the best software supply chain security tools in 2025?

Leading solutions include Snyk and Sonatype for dependency scanning, Sigstore for artifact signing, and RunSafe Security for embedded software protection. RunSafe particularly focuses on SBOMs for C/C++ code bases.