What are examples of supply chain attacks?

Landmark examples include SolarWinds/SUNBURST (2020, compromised build pipeline), Log4Shell (2021, a critical dependency vulnerability), the xz-utils backdoor (2024, a compromised maintainer), event-stream (2018, a malicious npm dependency), the Codecov bash uploader (2021, a compromised CI tool), and ongoing PyPI/npm typosquatting and dependency-confusion campaigns.

How do you prevent software supply chain attacks?

Defense spans the whole path: maintain an SBOM so you know what you ship; use reachability analysis to prioritise the vulnerabilities that are actually exploitable; scan dependencies for malware before install; harden and monitor CI runners (egress + behaviour); and verify build provenance (SLSA). No single control is enough — the attack surface runs from code to build to runtime.

Why are supply chain attacks so hard to detect?

Because the malicious code arrives through a trusted, often digitally-signed channel — a dependency you already use, a CI tool you rely on, or an update you expect. Signature and perimeter defenses assume the source is trustworthy, so the compromise is invisible until the payload acts. Runtime behaviour monitoring is what catches it after the fact.

Software supply chain attack examples

A software supply chain attack compromises a trusted part of how software is built or delivered — a dependency, a build tool, an update channel, or a maintainer account — so that malicious code reaches downstream users through a legitimate, trusted path. Below are the landmark examples, what each one actually did, and the class of weakness it exploited.

SolarWinds (SUNBURST)

2020Compromised build pipeline

Attackers breached SolarWinds’ build system and inserted a backdoor (SUNBURST) into signed Orion updates. Roughly 18,000 organisations installed the trojanised update; a subset were then actively exploited. The malicious code shipped through the legitimate, digitally-signed update channel — which is exactly why it evaded detection.

Takeaway: Signing proves origin, not integrity of the source. Build-pipeline tampering needs build-time defenses and provenance (SLSA), not just a signature check.

Log4Shell (Log4j)

2021Critical dependency vulnerability

CVE-2021-44228 in Apache Log4j allowed remote code execution via a crafted log string that triggered a JNDI lookup. Because Log4j is a near-ubiquitous transitive dependency, a single flaw exposed a vast share of Java applications — most teams did not even know they shipped it.

Takeaway: You cannot patch what you cannot see. An SBOM plus reachability analysis tells you whether the vulnerable Log4j path is actually reachable in your app.

CVE-2021-44228 details

xz-utils backdoor

2024Compromised maintainer / social engineering

CVE-2024-3094: a long-game social-engineering campaign gave a malicious actor maintainer trust over the xz compression library, which they used to plant a backdoor targeting SSH. It was caught by chance before reaching wide stable-distro deployment — a near-miss that showed how patient supply-chain compromise can be.

Takeaway: Trust in a maintainer is part of your attack surface. Behaviour-based build and runtime monitoring catch what code review of a trusted contributor may miss.

CVE-2024-3094 details

event-stream (npm)

2018Malicious dependency via transferred ownership

A popular npm package’s maintainership was handed to a new contributor who added a malicious transitive dependency designed to steal cryptocurrency wallet credentials from a specific downstream app. Millions of weekly downloads carried the poisoned code.

Takeaway: A dependency you trust can change hands. Continuous monitoring of dependency behaviour — not a one-time audit — is what catches a package that turns malicious.

Malicious package advisories

Codecov bash uploader

2021Compromised CI tool

Attackers modified Codecov’s bash uploader script to exfiltrate environment variables — including CI secrets and tokens — from the build environments of thousands of customers. The tampered script ran inside trusted CI pipelines.

Takeaway: CI runners are a high-value target: they hold secrets and run untrusted third-party scripts. Egress monitoring on the runner catches the exfiltration channel.

Egress monitoring

PyPI / npm typosquatting campaigns

ongoingTyposquatting & dependency confusion

Continuous campaigns publish malicious packages under names that mimic popular libraries (typosquatting) or exploit internal-package name collisions (dependency confusion) to get auto-installed. Payloads range from credential stealers to install-time backdoors.

Takeaway: The registry is an open attack surface. Pre-install malware scanning and a curated malware database stop the install before the payload runs.

Malicious package database

Defending against the whole class

No single control stops supply chain attacks — the surface runs from code to build to runtime. The building blocks:

SBOM — know what you ship Reachability — what’s actually exploitable Malware database — block bad packages Runtime protection for CI + containers Vulnerability intelligence

Frequently asked questions

What is a software supply chain attack?: A software supply chain attack compromises a trusted part of how software is built or delivered — a dependency, build tool, update channel, or maintainer account — so that malicious code reaches downstream users through a legitimate path. Because the delivery mechanism is trusted, these attacks bypass defenses aimed at external threats.
What are examples of supply chain attacks?: Landmark examples include SolarWinds/SUNBURST (2020, compromised build pipeline), Log4Shell (2021, a critical dependency vulnerability), the xz-utils backdoor (2024, a compromised maintainer), event-stream (2018, a malicious npm dependency), the Codecov bash uploader (2021, a compromised CI tool), and ongoing PyPI/npm typosquatting and dependency-confusion campaigns.
How do you prevent software supply chain attacks?: Defense spans the whole path: maintain an SBOM so you know what you ship; use reachability analysis to prioritise the vulnerabilities that are actually exploitable; scan dependencies for malware before install; harden and monitor CI runners (egress + behaviour); and verify build provenance (SLSA). No single control is enough — the attack surface runs from code to build to runtime.
Why are supply chain attacks so hard to detect?: Because the malicious code arrives through a trusted, often digitally-signed channel — a dependency you already use, a CI tool you rely on, or an update you expect. Signature and perimeter defenses assume the source is trustworthy, so the compromise is invisible until the payload acts. Runtime behaviour monitoring is what catches it after the fact.