What Is a Supply Chain Attack

Introduction

In December 2020, security researchers at FireEye discovered that their own security tools had been compromised — not by an attacker breaking in, but by a poisoned software update they had willingly installed. The culprit was SUNBURST, a supply chain attack that embedded a backdoor into a legitimate software update from SolarWinds Orion, signed with a valid code-signing certificate, and distributed to roughly 18,000 organizations including the US Treasury, the Department of Homeland Security, and Fortune 500 companies. Every victim had done everything right: they installed signed software from a trusted vendor. Yet they were all compromised. In March 2024, attackers with a remarkably similar playbook spent two years embedded in the XZ Utils open-source project, adding a backdoor to a compression library present in nearly every Linux system. The supply chain attack is now among the most dangerous attack vectors in existence precisely because it exploits the trust that makes software distribution work. Understanding how these attacks operate — and what defences actually limit them — is essential for any organization that consumes software or provides it.

What Is a Supply Chain Attack?

A supply chain attack compromises a target indirectly by corrupting a trusted component of its software development, build, or distribution pipeline. Rather than attacking the victim’s own systems directly, the attacker inserts malicious code into something the victim willingly downloads and trusts — an update from a software vendor, an open-source dependency, a build tool, or hardware from a manufacturer.

The attack’s power comes from trust propagation: one successfully compromised upstream component automatically distributes the attacker’s payload to every downstream consumer. A widely used open-source library with a hidden backdoor reaches millions of deployments. A compromised build server injects malicious code into every binary the organization ships. A poisoned hardware component reaches every customer of an equipment manufacturer.

The term “supply chain” is borrowed from physical logistics: just as contaminating a food ingredient at a supplier affects every product containing it, compromising a software component at any point in the development-to-deployment pipeline affects every system that ultimately runs it.

How Supply Chain Attacks Work

Supply chain attacks target different points in the software pipeline. The most common vectors are:

1. Build pipeline compromise (SolarWinds model): Attackers gain access to a vendor’s build infrastructure and inject malicious code during compilation, before signing. The resulting binary is cryptographically signed with the vendor’s legitimate key and distributed through official channels. Recipients have no way to detect the tampering through signature verification alone because the signature is valid.

2. Dependency confusion / package hijacking: Attackers exploit the gap between private package registries and public ones. If an organization uses a private package named acme-payments that is not registered on npm or PyPI, an attacker publishes a malicious acme-payments at a higher version number on the public registry. Misconfigured package managers that check public registries first automatically install the attacker’s version.

3. Open-source project compromise: Attackers gain maintainer access to widely used open-source projects through social engineering, burnout exploitation, or by becoming trusted contributors over months or years — then submit malicious changes. The XZ Utils attack involved nearly two years of trust-building before the backdoor was inserted. The event-stream npm package attack in 2018 used a similar long-game approach.

4. CI/CD pipeline injection: Attackers compromise a repository’s CI/CD configuration (GitHub Actions workflows, Jenkins pipelines) to execute malicious code during builds — exfiltrating secrets, backdooring binaries, or modifying deployment artifacts before they reach production.

5. Update mechanism abuse: Any software with an automatic update mechanism is a potential supply chain target. A compromised update server can push malicious code to millions of endpoints. The 3CX VoIP supply chain attack (2023) was itself the result of a prior supply chain attack — the threat actor had compromised a dependency that 3CX’s build system used.

VIDEO · READY 16:9

PLAY

SolarWinds Hack Explained

Supply Chain Attack Types vs Defences

Real-World Use Cases

Federal contractor security requirements: US Executive Order 14028 (2021) and subsequent guidance require federal software vendors to provide a Software Bill of Materials (SBOM) for all software delivered to government customers. The SBOM must list every component, library, and dependency with provenance data. CISA and NIST SP 800-161 Rev. 1 define the full C-SCRM (Cybersecurity Supply Chain Risk Management) framework. For organizations handling regulated data, supply chain controls now intersect with FISMA Compliance and procurement requirements.

Open-source package ecosystems: The npm, PyPI, and RubyGems registries collectively host millions of packages and serve billions of downloads per day. Major incidents — event-stream (2018), ua-parser-js (2021), colors.js (2022) — demonstrated that even popular packages with millions of weekly downloads can be weaponized. GitHub’s dependency review feature and Dependabot now alert on known-vulnerable dependencies automatically, but they cannot detect novel malicious code.

Container image supply chains: A containerized application may layer a base OS image, a language runtime image, several library layers, and application code — any of which can be compromised. Sigstore and cosign provide transparent, verifiable image signing tied to CI/CD workflow identities. SLSA (Supply-chain Levels for Software Artifacts) is a graduated framework for build provenance — requiring at minimum that builds are hermetic, reproducible, and generate verifiable attestations. The signing infrastructure for containers uses the same public-key cryptography and digital signatures covered elsewhere in this series.

Common Mistakes to Avoid

Pinning only to package names, not exact content hashes: Specifying requests==2.28.1 in a Python requirements file pins the version, but the package at that version on PyPI can be overwritten by a malicious publisher (typosquatting). Pin to the content hash — use pip’s --require-hashes flag or npm’s package-lock.json with integrity hashes. This ensures you install exactly the bytes you previously verified, regardless of what the registry serves today.

Granting CI/CD pipelines excessive secrets access: Build systems frequently have access to cloud provider credentials, code-signing keys, and deployment permissions. A compromised CI/CD workflow can exfiltrate these secrets and use them to sign malicious binaries or deploy to production. Use short-lived, OIDC-issued credentials (GitHub Actions OIDC provider with AWS IAM role assumption) instead of long-lived static secrets. Grant the minimum permissions needed per workflow step.

Not monitoring your dependency tree for newly malicious packages: A package can be benign when you first adopt it and become malicious after a maintainer account takeover. Tools like Socket.dev, Snyk, and GitHub’s dependency review detect newly added network calls, eval usage, or install scripts in package updates. Subscribe to your package ecosystem’s security advisories and treat dependency updates as code changes that require review.

Treating signed software as automatically trustworthy: SolarWinds was the definitive proof that a valid code-signing certificate does not mean the code is trustworthy — only that it was signed by whoever holds the certificate. Binary transparency (publishing signed hashes of every released artifact to an append-only log, as Sigstore’s Rekor does) makes tampering detectable. Reproducible builds allow independent parties to verify that a given binary was built from the declared source code. Neither has a valid code-signing certificate as a substitute.

Getting Started

To reduce your supply chain attack exposure:

First, generate an SBOM for every application and keep it current. Use tools like syft (Anchore), cdxgen (CycloneDX), or trivy to generate SBOMs in SPDX or CycloneDX format. Integrate SBOM generation into your CI/CD pipeline so every build produces an updated SBOM. When a new vulnerability like Log4Shell is disclosed, query your SBOM inventory to identify affected systems in minutes instead of days.

Second, lock dependencies to content hashes in every project. For npm, commit package-lock.json and use npm ci in CI pipelines. For Python, use pip-compile with --generate-hashes. For Go, the module system provides cryptographic checksums via go.sum. Treat any dependency with a changed hash as a potential compromise until reviewed.

Third, adopt SLSA for your own build pipeline. SLSA (pronounced “salsa”) Level 1 requires a machine-generated provenance attestation for every build. Level 2 adds that the build runs on a hosted, authenticated build platform. Start with Level 1 using GitHub Actions’ attestation support or Google Cloud Build’s SLSA provenance feature — it requires minimal pipeline changes and produces verifiable build records.

Fourth, implement code-signing and signature verification end to end. Sign every artifact your pipeline produces using Sigstore’s cosign tool with a keyless OIDC-based identity. Configure your deployment infrastructure to reject any artifact without a valid, verified signature from your CI/CD identity. For the cryptographic foundations of the signing and verification process, see What Is a Digital Signature? How It Proves Authenticity and Certificate Transparency: How CT Logs Stop Bad TLS Certs, which describes the append-only transparency log model that Sigstore’s Rekor is based on.