What Is a Supply Chain Attack? [Overview, Types & Examples]

How does a software supply chain attack work?

A supply chain attack works by compromising something the victim already trusts — a development tool, a software library, an update server — and using that trust as the delivery mechanism. The malicious payload doesn't break in. It gets invited.

Which means the attack surface isn't just your code. It's everything your code depends on, and everything that delivers it to you.

Software follows a lifecycle: design, develop, deploy, maintain. Attackers can compromise any of those stages.

Here's how attackers exploit each one:

At the design stage, some attacks are built in from the beginning.

An attacker with access to a project at the design stage can introduce a backdoor before a single line of legitimate code is written. 

The malicious functionality is embedded in the architecture itself. Not added later, not injected externally. The software ships with it already present.

The development stage is where most supply chain attacks happen. 

This is where code is written, dependencies are pulled in, and build infrastructure turns source code into a distributable product.

Attackers have multiple options here. 

Malicious code injected into an open source library reaches every application that imports it. A compromised SDK contaminates every project built with it. And an attacker who gains access to the build pipeline can insert malicious code directly into the compiled output without touching the source code at all. 

The distributed binary contains the attack. The source code appears clean.

Once software is built, the delivery infrastructure becomes the target.

Compromising an update server is particularly effective. Every user who accepts the next routine update installs the malicious payload without any indication that something is wrong. 

Stolen code-signing certificates make this harder to detect still, because the malicious software arrives with a valid digital signature. 

Distribution channels present a third vector: websites, certificate authorities, and software repositories can all be compromised to intercept software before it reaches end users.

The maintenance phase introduces its own vulnerabilities. 

Software that reaches end-of-life stops receiving security patches. Known vulnerabilities accumulate without remediation. And attackers exploit that exposure.

Open source projects present a related risk. Many critical projects are maintained by small teams (sometimes a single developer) with limited resources. When a maintainer is compromised or a project abandoned, the consequences can be severe.

In documented cases, attackers have spent years building credibility within open source communities before introducing malicious code specifically because that patience makes the attack nearly impossible to detect until it's too late.

What are the different types of software supply chain attacks?

Different types of software supply chain attacks include:

• Dependency confusion
• Typosquatting
• Compromised build pipeline and CI/CD infiltration
• Malicious open source packages
• Compromised software updates
• Stolen code-signing certificates
• SDK and third-party tool compromise
• Humans as an attack vector

Supply chain attacks don't follow a single playbook. Attackers exploit different entry points depending on where the weakest link is. And that weakest link can be anywhere from a misconfigured package manager to a trusted open source maintainer.

The table below covers the most common vectors in more detail. Some target code directly. Others target the infrastructure that builds and delivers it. One targets the humans behind it all.

The common thread across all eight: attackers don't need to break through your defenses. They need to find something your defenses already trust and work through it. In some cases that's a package name. In others it's a build tool, a software update, or a person. The entry point varies. The mechanism doesn't.

Real-world supply chain attack examples

These seven attacks span different entry points, different targets, and different outcomes. What they share is a common thread: in every case, the victim trusted something they had no reason to question.

TeamPCP (2026)

Entry point: Compromised GitHub Actions.

What was compromised: TeamPCP force-pushed malicious commits to 75 of 76 version tags in Aqua Security's Trivy GitHub Action. Any CI/CD workflow referencing those tags executed a credential stealer that harvested secrets from runner memory and AWS cloud credentials via the Instance Metadata Service.

How it propagated: Credentials stolen from the Trivy compromise were used to poison Checkmarx's AST GitHub Action approximately four days later. Each poisoned action used a vendor-specific typosquat domain, making exfiltration traffic appear to originate from the legitimate vendor.

Signals present: Outbound curl POST requests carrying encrypted payloads to external domains, combined with Instance Metadata Service access from the same process lineage. Domain reputation tools missed the attack entirely — the typosquat domains were newly registered with clean scores.

Outcome: Thousands of repositories were exposed across both waves. The cascading compromise demonstrated that a single poisoned CI/CD action can silently propagate through an entire development ecosystem before any infection is identified.

Shai-Hulud (2025)

Entry point: npm and PyPI package registries.

What was compromised: Shai-Hulud was the first documented self-replicating worm targeting open source package registries. Malicious packages published to npm and PyPI carried a credential-stealing payload that actively infected other packages in the victim's environment without further attacker involvement.

How it propagated: The malware executed during the pre-install phase of dependency installation, requiring no user interaction. It scraped CI/CD credentials and cloud tokens, exfiltrated them to attacker-controlled infrastructure, and continued spreading by modifying additional packages. A second wave, Shai-Hulud 2.0, expanded the scope to tens of thousands of GitHub repositories.

Signals present: Unusual pre-install script execution and outbound connections to unauthorized endpoints. By the time any single infection was detected, propagation across connected environments was already underway.

Outcome: The campaign affected tens of thousands of repositories. Stolen credentials were exfiltrated to public GitHub repositories tagged with the identifier "Sha1-Hulud: The Second Coming."

XZ Utils (2024)

Entry point: Open source maintainer

What was compromised: Over nearly two years, an attacker operating under a false identity made legitimate contributions to XZ Utils, which is a widely-used open source compression library present in most Linux distributions. The contributions were genuine. The reputation was built deliberately.

How it propagated: Once trusted, the attacker introduced a backdoor into the library that would have enabled remote code execution via SSH on affected systems. The malicious code was obfuscated across multiple files and build scripts. It passed the standard code review.

Signals present: The signal that caught it wasn’t a security tool. A developer noticed that SSH authentication on systems running the affected version was taking longer than expected. That latency anomaly prompted investigation.

Outcome: The attack was caught before widespread deployment. Had it reached stable Linux distributions at scale, the potential impact was enormous.

FYI: The XZ Utils attacker is believed to have targeted the maintainer specifically because of burnout. The attacker sent supportive messages and offers to help during periods of stress before gradually assuming more control over the project. The social engineering was sustained and deliberate.

3CX (2023)

Entry point: A prior supply chain compromise

What was compromised: The 3CX attack was itself the product of an earlier supply chain attack. An employee had installed compromised software from a third-party application. That gave attackers a foothold inside 3CX's development environment.

How it propagated: Attackers trojanized the official 3CX desktop application installer. The malicious version was signed with a legitimate certificate and distributed through the official update mechanism. The compromised installer deployed an infostealer that communicated with attacker-controlled infrastructure.

Signals present: Security tools flagged unusual behavior, but initial reports were dismissed because the software was signed and came from a trusted vendor.

Outcome: 3CX serves over 600,000 companies. The potential downstream impact was significant.

FYI: 3CX is the first publicly documented case of a supply chain attack being used to execute a second supply chain attack, sometimes called a cascading or chained supply chain compromise. The initial breach of a third-party application was the entry point into 3CX's own build environment.

Kaseya (2021)

Entry point: A vulnerability in managed service provider software.

What was compromised: Attackers exploited an authentication bypass vulnerability in a remote monitoring and management platform used by managed service providers to administer customer environments. By compromising the platform, they gained the ability to push commands to every endpoint under management.

How it propagated: Ransomware was deployed across customer networks simultaneously. The commands came through a trusted management platform. Endpoint security tools did not block them.

Signals present: Minimal. The commands originated from a trusted platform and appeared consistent with normal administrative activity.

Outcome: The attack affected over 1,500 downstream organizations. The attackers demanded $70 million for a universal decryption key.

SolarWinds (2020)

Entry point: Build infrastructure

What was compromised: Attackers gained access to SolarWinds' software build environment and injected malicious code into the compilation process for Orion, a widely-used network monitoring platform. The resulting updates were digitally signed with legitimate certificates and distributed through official channels.

How it propagated: The malicious code, later named SUNBURST, lay dormant for up to two weeks after installation before activating. It was designed to blend with legitimate Orion traffic and communicated with attacker-controlled infrastructure using patterns that fell just within the ranges automated tools were tuned to ignore.

Signals present: Unusual DNS patterns and HTTP traffic at the edge of normal ranges. Security tools missed them.

Outcome: The attack went undetected for months. Approximately 18,000 organizations installed the compromised update. Fewer than 100 were selected for deeper exploitation, including multiple U.S. federal agencies.

FYI: SUNBURST used a dormancy period of up to 14 days after installation before activating specifically to create distance between the initial infection and any behavioral change that might trigger detection. Dwell time was a design feature, not a side effect.

NotPetya (2017)

Entry point: A software update mechanism.

What was compromised: Attackers compromised the update infrastructure of a widely-used accounting application and delivered what appeared to be ransomware through a routine software update. It was not ransomware. It was a wiper — designed to encrypt systems with no viable decryption path.

How it propagated: NotPetya spread laterally using a leaked exploit that enabled it to move across networks without further user interaction. Once inside, it moved fast.

Signals present: Minimal. The update came from a legitimate source. The initial behavior resembled known ransomware. By the time organizations understood what they were dealing with, the damage was done.

Outcome: The estimated global cost exceeded $10 billion. Major shipping, pharmaceutical, and logistics companies lost weeks of operational capacity.

Why are supply chain attacks so hard to detect?

Supply chain attacks are hard to detect because the attack arrives looking exactly like something you trust.

That's not a vague observation. It's the specific technical problem. Every conventional security control is designed to detect something anomalous. Supply chain attacks are designed to be indistinguishable from normal.

Here's how each layer of conventional defense fails.

Code signing and hash verification confirm that software hasn't been modified since it was signed. They say nothing about what the software does when it runs. A perfectly valid signature on a malicious binary is not a contradiction. It's the point.

Static scanning identifies known vulnerabilities in known packages. It can’t detect novel malicious behavior. It can’t flag code that has no prior signature. And it can’t see what a package does at runtime. Only what it contains at rest.

Dormant payloads defeat both. Attackers routinely design malicious code to lie inactive for days or weeks after installation, activating only under specific conditions. By the time behavior changes, the connection to the initial compromise is difficult to establish.

Dwell time compounds everything. For instance, the SolarWinds compromise went undetected for months. The malicious code was present and active in thousands of environments before anyone knew it existed. The longer an attacker operates undetected, the harder attribution becomes and the deeper the damage goes.

The XZ Utils backdoor makes this concrete. It passed every build-time check. Code review. Signing. Static analysis. What caught it was a developer noticing that SSH authentication was taking slightly longer than expected. A latency anomaly. Not a security tool.

The takeaway:

Detection at build time is necessary. It isn't sufficient. What software does at runtime is the only ground truth.

How is AI changing the supply chain attack landscape?

AI is changing the supply chain attack landscape by making existing attack categories faster to execute, cheaper to scale, and harder to attribute.

The most immediate impact is scale. 

Attackers are using large language models to generate convincing malicious packages at a volume no human review process can match. 

Typosquatting campaigns that once required manual effort can now be automated. In 2024, security researchers identified thousands of malicious packages across major registries, including a significant share targeting AI libraries.

State-sponsored actors have also begun leveraging AI for vulnerability research and targeted phishing campaigns aimed at developers and open source maintainers.

The ML model supply chain introduces a newer risk. 

Organizations increasingly pull pre-trained models from public repositories the same way developers pull open source libraries. Those models can contain malicious code embedded in weights or training data. Essentially, payloads that activate on deployment and are invisible to standard scanning tools. 

AI-assisted code contributions to open source projects compound this further. They’re harder to audit and harder to attribute.

However, it’s worth noting:

The defensive side is also moving. 

AI-assisted behavioral detection is improving the ability to identify anomalous patterns at scale: across package behavior, network traffic, and runtime activity. The same technology attackers are using to operate faster is being applied to detection pipelines that no human analyst could run manually.

Regulators are responding as well. The EU AI Act and recent executive orders on software supply chain integrity are beginning to establish formal expectations around AI component transparency, including model provenance and software bills of materials for AI systems.

How to protect against supply chain attacks

Protecting against supply chain attacks requires three layers: runtime behavioral detection to catch what gets through, mitigation controls to limit blast radius, and prevention measures to reduce attacker surface before code ships.

Each layer addresses a different phase of the attack, and all three are necessary.

Detection

Start here, because build-time controls alone won't catch what gets through. 

Instrument your runtime environment to monitor behavioral signals: unexpected process execution, unusual system calls, network connections to unknown endpoints, privilege escalation attempts, and file system access outside normal parameters.

These signals don't require a known signature. They require a baseline and the ability to identify deviation from it.

If you're running containers or Kubernetes, periodic scanning isn't enough. Since workloads are ephemeral, you need continuous runtime monitoring across every workload lifecycle. Not snapshots.

Pro tip: Start with your highest-risk workloads and establish their behavioral baselines first. Trying to baseline everything simultaneously creates noise that makes deviation harder to identify, not easier.

Mitigation

Assume something will get through and limit what it can do. 

Audit every application, service, and dependency for what it actually needs to function and remove everything else. Enforce network segmentation between your build and runtime environments so a compromised component can't move laterally. And use your software bill of materials (SBOM) against runtime data to prioritize remediation.

Focus on vulnerabilities in code that's actually executing, not everything that's installed.

Pro tip: When auditing dependencies for least privilege, don't just look at what permissions are configured. Look at what permissions are actually used at runtime. The gap between the two is where your real exposure lives.

Prevention

Reduce the attacker surface before code ships. Generate and maintain a software bill of materials for every application. Sign container images and enforce admission control so unverified images don't reach production. 

Harden your CI/CD pipeline: rotate secrets, apply least privilege to build agents, and separate build systems from deployment systems. Pin dependency versions and scan before every build. 

And assess vendor security posture before integrating any third-party tool or service.

Pro tip: Before onboarding any vendor, ask two questions: how do they secure their build pipeline, and can they produce an SBOM for what you're integrating? An inability to answer either is a meaningful risk indicator.

How are regulators responding to supply chain risk?

Governments and standards bodies are responding to increasing supply chain attacks  with frameworks, mandates, and legal obligations that affect how organizations build and distribute software.

Supply chain attacks are no longer just a security problem. They're a policy problem.

The regulatory response is still maturing. But the direction is clear: transparency, traceability, and accountability throughout the software supply chain are becoming requirements. Not recommendations.

Here's how the major frameworks and regulations compare:

These frameworks serve different functions and different audiences. Some are binding law. Others are voluntary guidance.

What they share is a common thread: the expectation that organizations understand what's in their software and can demonstrate how it was built. 

Across every framework in this list, one requirement keeps appearing: the software bill of materials. 

An SBOM is what makes supply chain transparency actionable. Without it, organizations can't assess exposure when a new vulnerability is disclosed. They can't respond effectively when a component is compromised. And they can't satisfy the transparency obligations that regulators are increasingly demanding.