Software Supply Chain Attacks: Types, Examples & 5 Defensive Measures

What are Software Supply Chain Attacks?

A software supply chain attack happens when bad actors break into a trusted third-party vendor, tool, or open-source library. Instead of hacking a company’s front door, attackers hide bad code inside routine updates or shared components. This lets them infect every customer who trusts and uses that software.

These attacks can occur at various points in the software lifecycle, such as during development, packaging, or distribution. By injecting malicious code or manipulating legitimate software updates, attackers can bypass traditional security controls. Because these threats often exploit trusted relationships and approved components, they can be difficult to detect and may persist undetected for extended periods, increasing the potential damage and reach of an attack.

Common types of software supply chain attacks:

Compromised software updates: Attackers inject malicious code into trusted vendor updates, allowing malware to spread through legitimate update channels.
Open-source dependency attacks: Malicious code is added to open-source libraries or packages that developers unknowingly include in their applications.
Dependency confusion: Attackers publish public packages with the same names as private internal packages, tricking build systems into installing malicious versions.
Typosquatting: Attackers create packages with names similar to popular libraries, relying on developer typos to trigger malicious installs.
Compromised build systems: Attackers alter CI/CD servers, build scripts, or packaging workflows so official releases include malicious code.
Stolen developer credentials: Compromised developer accounts let attackers push code, change configurations, or publish malicious packages.
Code-signing certificate compromise: Attackers steal signing keys or certificates to make malicious software appear legitimate and trusted.

How to prevent software supply chain attacks:

Maintain a software bill of materials: Keep an updated SBOM that tracks all internal, commercial, open-source, and transitive dependencies in each release.
Apply least-privilege access across development environments: Limit permissions for developers, services, repositories, build systems, and deployment tools to only what is required.
Automate vulnerability triage and remediation: Use automated scanning and remediation workflows to detect vulnerable dependencies and speed up secure updates.
Protect source code repositories and developer accounts: Enforce MFA, code reviews, branch protections, secret scanning, and monitoring for suspicious repository activity.
Prioritize vulnerabilities based on exploitability and risk: Focus remediation on vulnerabilities that are reachable, exploitable, internet-facing, or tied to critical assets.

This is part of a series of articles about software supply chain security.

Why Software Supply Chain Attacks Are Increasing

Software supply chain attacks are increasing because modern development depends on interconnected tools, external code, and automated delivery pipelines. These efficiencies help teams build faster, but they also expand the attack surface and make it harder to verify every component, update, and process involved in delivering software.

Recent data confirms the growing prevalence of software supply chain attacks. The recent Red Hat Product Security Risk Report identified a 54% increase year-over-year in the number of publicly reported software supply chain attacks. The report also found that attackers increasingly targeted package registries, developer accounts, IDE extensions, and automated publishing systems, allowing a single compromise to propagate more broadly and affect more downstream users.

The key reasons supply chain attacks are increasing include:

Growing dependence on third-party software: Organizations rely on external libraries, tools, and packages to speed development and reduce costs. Each dependency introduces risk, especially when teams lack full visibility into what is in their codebase.
Expansion of open-source ecosystems: Open-source software enables rapid innovation but can be difficult to secure at scale. Attackers may inject malicious code into public packages or exploit under-maintained projects that organizations use unknowingly.
Faster DevOps and CI/CD workflows: Automated pipelines accelerate releases but can pull unverified dependencies or run unsafe scripts. Without integrated security controls, attackers can target build systems, deployment tools, and configuration files.

Related content: Read our guide to application security

How Software Supply Chain Attacks Work

Software supply chain attacks exploit the trust organizations place in the software, tools, and services used to build and run applications. Instead of attacking each organization separately, attackers compromise an upstream target such as a package maintainer account, source code repository, build server, CI/CD pipeline, or software vendor. They then use that access to insert malicious code into a component that developers or customers already trust.

The malicious code can enter the supply chain as a modified dependency, build script, compiled binary, or legitimate-looking software update. For example, an attacker who steals a package maintainer’s publishing token may release a compromised version under the package’s real name. Once developers install the package or an automated pipeline pulls the update, the attacker’s code can execute inside downstream environments, where it may steal credentials, create backdoors, or provide access to additional systems.

A typical attack process:

Identify a trusted target: Attackers look for software vendors, open-source packages, developer accounts, build systems, or other components used by many downstream organizations.
Gain initial access: They exploit vulnerabilities, steal developer credentials, compromise maintainer accounts, or abuse weak access controls to enter the development environment.
Insert malicious code: Attackers modify source code, dependencies, build scripts, packages, or compiled binaries. The malicious changes may include credential stealers, backdoors, or code that downloads additional malware.
Abuse trusted build or signing processes: Malicious code may pass through legitimate build pipelines or be signed with trusted certificates. This can make the compromised software appear authentic to users and security tools.
Distribute the compromised software: The altered component reaches victims through software updates, package registries, CI/CD pipelines, or other normal distribution channels.
Execute in downstream environments: When developers install the package or users update the affected software, the malicious code runs with the permissions available to the compromised application or process.
Perform follow-on activity: Attackers may steal credentials and data, establish persistent access, move through connected systems, or use newly compromised accounts to spread malicious code to additional packages or applications.

Common Types of Software Supply Chain Attacks

Compromised Software Updates

Attackers target the update mechanisms of legitimate software, injecting malicious code into official updates distributed by trusted vendors. This approach exploits the trust users and organizations have in software providers, allowing malware to spread quickly and efficiently. Well-known incidents, such as the SolarWinds attack, have demonstrated the wide-reaching impact of compromised software updates, as a single tainted update can affect thousands of organizations simultaneously.

The complexity of software supply chains makes it difficult to verify the integrity of every update. Attackers often gain access to build servers or update distribution platforms, embedding malicious payloads before updates are signed and released. Because users expect updates to improve security and functionality, they are likely to install them promptly, unwittingly introducing threats into their environments.

Open-Source Dependency Attacks

Open-source dependency attacks occur when attackers introduce malicious code into widely used open-source libraries or packages. Developers who incorporate these compromised dependencies into their projects inadvertently propagate the attacker’s code to downstream applications. Since open-source repositories are often trusted and widely used, a single compromised library can have far-reaching consequences across multiple organizations and products.

Maintainers of open-source projects may lack the resources to thoroughly vet contributions or monitor for malicious changes, making these ecosystems attractive targets. Attackers may submit seemingly benign updates or exploit vulnerabilities in package management workflows to gain access and introduce harmful code. Without stringent controls and monitoring, these attacks can go undetected for extended periods.

Related content: Read our guide to SCA security

Dependency Confusion

Dependency confusion attacks exploit the way package managers resolve dependencies between public and private repositories. Attackers publish malicious packages to public repositories using names that match internal packages used by organizations. If the package manager prioritizes the public version, the attacker’s code is automatically downloaded and executed in place of the intended internal package, granting the attacker access to internal systems or sensitive data.

These attacks highlight the risks of misconfigured build environments and the importance of correctly managing private package namespaces. Organizations that fail to properly segregate internal and external dependencies are particularly vulnerable, as attackers can easily discover and hijack package names through open-source intelligence or leaked documentation.

Typosquatting

Typosquatting attacks involve registering packages with names similar to popular libraries, banking on the likelihood that developers will make typographical errors when specifying dependencies. When a typo is made, the attacker’s malicious package is installed instead of the intended legitimate one, allowing malware or backdoors to be introduced into the development pipeline.

The effectiveness of typosquatting is amplified by the sheer volume of dependencies used in modern software projects. Attackers often automate the creation of hundreds or thousands of similarly named packages to increase the chances of accidental installation. These attacks exploit both human error and the lack of automated safeguards in package management systems.

Compromised Build Systems

Attackers target build systems and continuous integration servers, injecting malicious code during the software compilation or packaging process. By compromising these systems, attackers can ensure that every build or release contains their payload, which is then distributed to end users as part of the official software product.

Securing build systems is challenging due to their complexity and the wide range of tools and plugins they integrate with. Attackers may exploit weak access controls, unpatched vulnerabilities, or exposed secrets to gain entry. Once inside, they can manipulate build scripts, alter environment variables, or substitute legitimate binaries with malicious ones.

Stolen Developer Credentials

Attackers frequently target developer accounts to gain access to source code repositories, build systems, or package registries. Compromised credentials allow attackers to push malicious code, alter configurations, or escalate privileges within development environments. These breaches are often the result of phishing, credential stuffing, or weak password practices.

The impact of stolen credentials can be severe, as attackers can act with the same permissions as legitimate developers. This makes their actions harder to detect and allows them to blend in with regular development activities. Multi-factor authentication and strong credential hygiene are essential to reducing this risk.

Code-Signing Certificate Compromise

Code-signing certificates are used to verify the authenticity and integrity of software. When attackers obtain or compromise these certificates, they can sign malicious code, making it appear legitimate to users and security tools. This undermines trust in the software supply chain and can facilitate widespread distribution of malware.

Compromising a code-signing certificate often involves stealing private keys or exploiting weaknesses in certificate management practices. Once obtained, attackers can distribute malware that bypasses many security controls, as signed software is often implicitly trusted by operating systems and endpoint protection solutions. Robust certificate management and monitoring are critical for defending against these attacks.

Recent Software Supply Chain Attack Examples

Recent incidents show how software supply chain attacks have shifted toward widely used open-source packages, developer tools, and CI/CD workflows. By compromising a single trusted component or maintainer account, attackers can distribute malicious code across thousands of downstream projects before the compromise is detected.

Attack	What Happened	Impact	Lessons Learned
ChainDrop npm Attack (2026)	Microsoft identified a large-scale, self-propagating npm supply chain attack affecting 400+ packages across multiple publishers. Malicious npm `preinstall` scripts stole credentials, then modified and republished other packages accessible to compromised accounts.	Enabled rapid spread across the npm ecosystem through stolen maintainer credentials and automated package republishing.	Protect npm publisher accounts with MFA, monitor install scripts, limit token permissions, rotate credentials quickly, and detect unusual package publishing behavior.
Axios npm Compromise (2026)	Attackers compromised a maintainer account for the widely used Axios library and published malicious releases containing the `plain-crypto-js` dependency. Installation triggered a cross-platform backdoor on Windows, macOS, and Linux.	Axios normally receives 100M+ weekly downloads, making the compromise potentially very widespread.	High-popularity dependencies are high-value targets. Use dependency pinning, package integrity checks, maintainer account hardening, and rapid dependency monitoring.
Shai-Hulud npm Campaign (2025)	A coordinated campaign targeted npm maintainers and publishing workflows. Compromised credentials were used to inject malicious install scripts into legitimate packages.	Malware stole npm, CI/CD, cloud, and other credentials, then used some of them to compromise additional packages.	Secure CI/CD secrets, enforce least-privilege tokens, monitor for malicious lifecycle scripts, and separate publishing permissions from general developer credentials.
Tj-actions / changed-files Compromise (2025)	Attackers compromised the popular `tj-actions/changed-files` GitHub Action and changed existing version tags to point to malicious code.	The malicious code extracted secrets from GitHub Actions runner memory and exposed them in workflow logs. More than 23,000 repositories were potentially affected.	Pin GitHub Actions to commit SHAs instead of mutable tags, restrict workflow secrets, review third-party Actions, and monitor workflow logs for secret exposure.
XZ Utils Backdoor (2024)	Malicious code was introduced into XZ Utils versions 5.6.0 and 5.6.1. The backdoor targeted certain Linux systems and was designed to interfere with SSH authentication.	Could have enabled unauthorized remote access, but was discovered before broad deployment in major stable Linux distributions.	Open-source project governance, maintainer trust, reproducible builds, code review, and anomaly detection are critical for widely used low-level dependencies.
3CX Desktop App Attack (2023)	Attackers compromised 3CX’s software supply chain and distributed trojanized desktop app versions through legitimate update channels.	Customer systems received malicious software from a trusted vendor update mechanism, enabling multi-stage infections.	Vendor update channels require strong code-signing, build pipeline security, endpoint monitoring, and rapid incident response for downstream customers.

How to Prevent Software Supply Chain Attacks

1. Maintain a Software Bill of Materials (SBOM)

Maintain an up-to-date SBOM that lists the open-source, commercial, and internally developed components included in each software release. The inventory should include direct and transitive dependencies, package versions, and other identifiers needed to match components against vulnerability and threat intelligence.

Integrate SBOM generation into CI/CD pipelines so the inventory changes with each build. Security teams can use this data to identify affected applications when a vulnerable or compromised package is discovered, reducing the time required to assess exposure and begin remediation.

2. Apply Least-Privilege Access Across Development Environments

Limit access to source code repositories, build systems, package registries, signing infrastructure, and deployment tools based on job requirements. Developers and automated services should receive only the permissions required for their tasks, reducing the damage an attacker can cause with a compromised account or token.

Use separate identities for users and automation, restrict administrative privileges, and regularly review access rights. Short-lived credentials and narrowly scoped tokens can further reduce exposure, especially in CI/CD environments where secrets may otherwise provide broad access to production systems.

3. Automate Vulnerability Triage and Remediation

Integrate software composition analysis and vulnerability scanning into development and CI/CD workflows. Automated tools can identify vulnerable dependencies, outdated packages, and policy violations before software reaches production, while continuous scanning can detect newly disclosed risks in previously released applications.

Connect findings to remediation workflows so affected teams receive actionable information, including the vulnerable component, installed version, available fix, and affected applications. Where appropriate, automate dependency update requests and security tests to shorten remediation times without bypassing review and validation.

4. Protect Source Code Repositories and Developer Accounts

Require multi-factor authentication for developer accounts and enforce strong controls around repository access. Protect high-risk actions such as merging code, changing CI/CD workflows, publishing packages, or modifying branch protections with additional approval requirements and restricted permissions.

Monitor repositories for suspicious commits, unexpected permission changes, exposed secrets, and unusual publishing activity. Use protected branches, mandatory code reviews, signed commits where appropriate, and secret scanning to make unauthorized changes harder to introduce and easier to detect.

5. Prioritize Vulnerabilities Based on Exploitability and Risk

Do not prioritize remediation based only on vulnerability severity scores. Consider whether a vulnerable component is actually present in a deployed application, whether the affected code is reachable, whether a working exploit exists, and whether the application is exposed to potential attackers.

Combine vulnerability data with runtime context, asset criticality, threat intelligence, and sources such as CISA’s Known Exploited Vulnerabilities catalog. This risk-based approach helps security teams focus limited remediation resources on vulnerabilities that are most likely to be exploited or cause significant damage.

Related content: Read our guide to vulnerability prioritization

Securing Your Software Supply Chain with Maze Code

Software supply chain attacks enter through the dependencies your team pulls in and the code your team writes, which is exactly where Maze Code operates. Maze Code is a suite of AI agents that find vulnerabilities across your code and dependencies, investigate each one the way an expert security engineer would, and prove which findings are actually exploitable in your environment rather than simply present or reachable. Findings that matter reach your team with technical context and a fix routed to a developer; the ones that aren’t risky are closed before they hit your backlog.

Key capabilities of Maze Code:

Full-codebase vulnerability discovery: AI agents find every vulnerability in your code and dependencies, and can also ingest and dedupe findings from the scanners you already run.
A software bill of materials that stays current: Maze Code builds a complete inventory of every component in your codebase, direct and transitive, and updates it as your code changes. When the next compromised package hits the news, you know whether you shipped it without waiting on a manual audit.
Deep dependency investigation (AI-SCA): Maze finds every vulnerable dependency, then uses AI-built call graphs that pick up where traditional reachability stops, tracing the full call chain however many hops deep the vulnerability sits.
Exploitability proof, not just reachability: Agents check your runtime and cloud to confirm whether a path can actually be exploited, and close findings that are reachable but not exploitable in practice.
Novel and business-logic flaw detection (AI-SAST): Instead of matching code against known patterns, Maze agents understand what the code does, surfacing novel vulnerabilities and complex business-logic flaws that pattern-based tools miss.
Fixes routed to the right owner: Agents trace where a vulnerability came from, identify the owner, and ship the PR directly to that developer, recommending a mitigation when no fix exists yet.
Developer-native delivery: Maze Code operates in your CI/CD pipeline, surfacing findings when you open a pull request.
Unified code and cloud context: Running on the same platform as Maze Cloud, agents mesh cloud findings with code investigations so you get one unified ticket per issue instead of several.
Evidence-backed verdicts: Every conclusion is grounded in evidence from your code, cloud, and business context, and you can open any verdict to see exactly why Maze reached it.

Book a demo to see how Maze Code investigates, proves, and fixes code vulnerabilities.