What Is a Software Supply Chain Attack: Cases and SLSA Defence 2026

A software supply chain attack is an attack that compromises legitimate software at some point of its build or distribution chain in order to infect downstream users. The attacker doesn't break the door of the final target: they break the door of someone the target trusts (a vendor, a library, a package registry, a build tool) and let the official update deliver the signed implant. That property (one breach multiplied across thousands of victims, distributed through trusted channels) makes the software supply chain the most explosive attack category of the 2020 to 2026 period.

This guide explains what a software supply chain attack is, the five categories of attack by point in the chain, publicly documented cases without glamorising them (SolarWinds Sunburst, NotPetya, Codecov, Kaseya, Log4Shell, 3CX, XZ Utils, npm and PyPI poisoning), why it is a strategic target, modern defence frameworks (SLSA, sigstore, in-toto, NIST SSDF, OpenSSF), the role of SBOM under CRA and Executive Order 14028, and a practical enterprise defence programme.

The essentials

• A supply chain attack compromises legitimate software during its construction or distribution; the malicious code arrives signed through the official channel.
• The five categories by point of the chain are developer environment, source code, build pipeline, package registry and distribution.
• Cases like SolarWinds, NotPetya, Codecov, Kaseya, Log4Shell, 3CX, XZ Utils and the recurring incidents on npm and PyPI are publicly documented.
• Defence frameworks are SLSA (levels L1 to L4), sigstore (cosign, fulcio, rekor), in-toto, NIST SSDF and OpenSSF Best Practices.
• SBOM (SPDX or CycloneDX) is required under the European Cyber Resilience Act and the United States Executive Order 14028.
• Practical defence combines continuous inventory, artefact signing, version pinning, vulnerability scanning, internal registry, CI/CD hardening and vendor risk management.

What a software supply chain attack is

A software supply chain attack is any attack that introduces malicious code, hostile configuration or compromised cryptographic material into a legitimate component of the software lifecycle, in such a way that the altered component is distributed through the normal trusted channels and reaches end users as if it were the official version. The difference compared with a direct attack is structural: the attacker doesn't compromise the victim, they compromise the vendor or a link in the chain, and the victim infects itself when applying the update or resolving the dependency.

The appeal for the attacker is amplification. Compromising a library used by ten thousand applications is equivalent to gaining ten thousand potential bridgeheads. Compromising a security scanner integrated into CI/CD pipelines multiplies the reach inside every victim. Compromising a vendor's signing key allows the attacker to sign implants that any reputation-based defence will consider legitimate.

The 2020 to 2026 period has consolidated this category as the most profitable and the hardest to detect in time. SolarWinds, NotPetya, Log4Shell, 3CX and XZ Utils are examples of incidents where detection took months or years and the impact was measured in thousands of organisations affected simultaneously.

Attack categories by point in the chain

Attacks are not uniform: every point in the lifecycle has its own surface. The classification that best fits practical defence work distinguishes five categories.

Maintainer development environment. The attacker compromises the developer's workstation (phishing, credential theft, malware) or their GitHub, GitLab or package registry credentials. Also in this category are malicious IDE plugins (Visual Studio Code, JetBrains) that execute code every time the project is opened.

Source code. Malicious pull request accepted under lax review, commit hijack via stolen credentials, alteration of the mirror repository, dependency confusion where the attacker publishes a public package with the same name as an internal one and the resolver prefers it. The XZ Utils case is the most sophisticated example: a patient attacker built trust over years until becoming co-maintainer and then introduced the implant.

Build pipeline (CI/CD). Compromise of GitHub Actions, GitLab CI or Jenkins runners, theft of secrets stored in the pipeline, alteration of the artefact between compilation and signing, execution of malicious scripts in build hooks. SolarWinds Sunburst is the paradigmatic case: the attacker injected Sunburst during the official Orion build process, not into the source code.

Package registry. Typo squatting (packages with names similar to the original, requets instead of requests), maintainer account takeover (event-stream and ua-parser-js are public examples), publication of malicious versions after acquiring the package by purchase or transfer, tampering with the registry itself.

Distribution and signing. Compromised CDN serving altered binaries, theft of the private signing key (the attacker signs their implant as if it were the vendor), automatic updates pointing to compromised update infrastructure. The 3CX case in 2023 illustrates a nested chain: 3CX was a victim of an earlier supply chain attack against X_Trader, whose compromised installer infected the workstation of a 3CX developer, who ended up propagating the implant to 3CX customers.

Publicly documented cases

SolarWinds Sunburst (2020). The group identified by Mandiant as UNC2452 (subsequently attributed to APT29 / SVR) compromised the SolarWinds Orion build pipeline between March and June 2020. The signed official update distributed the Sunburst implant to approximately eighteen thousand customers, with selective exploitation against a few dozen (US federal agencies, Microsoft, FireEye). Detection came in December 2020 from FireEye after an intrusion into their own environment.

NotPetya (2017). The initial vector was the update of the Ukrainian accounting software MEDoc, widely used in Ukraine to meet local tax obligations. The implant propagated NotPetya, destructive ransomware without a real decryption key, with multi-billion global impact on Maersk, Merck, FedEx, Mondelez and other organisations with Ukrainian subsidiaries or partners.

Codecov (2021). Attackers altered the installation script of the official Codecov Docker image, a code coverage tool integrated into CI pipelines. The altered script exfiltrated environment variables (credentials, tokens, secrets) from every pipeline that executed it. The company estimated two months of exposure prior to detection.

Kaseya VSA (July 2021). The REvil group exploited vulnerabilities in the Kaseya VSA agent, remote management software used by MSPs (managed service providers), to deploy ransomware not only to Kaseya direct customers but to the end customers of those MSPs. The estimated reach was between one thousand and fifteen hundred victim organisations through around sixty MSPs.

Log4Shell (CVE-2021-44228). It wasn't a deliberate attack against the chain, but it illustrated the scale of the transitive dependency risk. Log4j 2 is a logging library used directly or indirectly by a huge fraction of the enterprise Java ecosystem. The vulnerability allowed remote RCE without authentication. Cataloguing real exposure was a massive exercise in every organisation because of the absence of prior SBOMs.

3CX (March 2023). Compromise of the 3CX desktop client, corporate VoIP communications software. Subsequent investigation established that the origin was a prior infection against X_Trader, a tool from the financial sector, whose trojanised installer infected the workstation of a 3CX employee. Mandiant and CrowdStrike attributed the campaign to North Korean actors.

XZ Utils (CVE-2024-3094, March 2024). A person operating under the alias Jia Tan contributed for more than two years to the XZ Utils project (compression library included in practically every Linux distribution), gained co-maintainer status and then introduced an extremely sophisticated backdoor in versions 5.6.0 and 5.6.1 that compromised sshd when loaded via systemd. The detection was made by Andres Freund (Microsoft engineer) due to a 500 millisecond performance anomaly on SSH connections in his testing environment. The backdoor did not reach stable versions of most distributions thanks to early detection, but it is considered the most sophisticated supply chain attack documented to date.

Recurring npm and PyPI poisoning. The package ecosystem experiences regular incidents: event-stream (2018, account takeover and injection targeting Copay), ua-parser-js (2021, maintainer compromised via reused credentials), ruby-saml (2024, vulnerability in SAML parser with multi-implementation impact), multiple typo squatting campaigns against popular packages. These are not isolated incidents: they are permanent background noise in the modern open source ecosystem.

Why the supply chain is a strategic target

Three properties make the chain a priority target and it is no coincidence that state-level APTs have invested in this avenue.

Amplification. One breach equals thousands or tens of thousands of potential victims. The cost per victim falls at the rate of the fanout of the compromised component.

Trust vector. Perimeter defences, reputation-based EDRs and update firewalls are designed to trust the official channel. A vendor-signed binary passes every control by design. The attacker doesn't need to bypass the defence: the defence cooperates.

Detection difficulty. The implant can stay dormant for months (Sunburst waited twelve to fourteen days before activating its C2), distributed across thousands of legitimate installs, with no recognisable static signature (because every victim receives the same binary signed by the vendor as officially released). Detection requires behavioural visibility (anomalous network traffic, beaconing, unexpected execution) and specific threat hunting queries, not signature antivirus.

Modern defence frameworks

SLSA (Supply chain Levels for Software Artifacts). Open specification maintained by OpenSSF that defines four progressive levels of guarantees over the integrity of software construction. L1 requires an automated build process and documented provenance. L2 adds hosted build and signed provenance. L3 requires isolated, non-forgeable and tamper-resistant builds. L4 is the strictest level, with reproducible builds and human review over the code entering the build. Few organisations operate at L4 outside specific critical projects.

sigstore. Set of OpenSSF projects that makes it easier to sign artefacts cryptographically without requiring long-term manual key management. Cosign signs and verifies container images and binaries. Fulcio is the CA that issues ephemeral certificates bound to OIDC identities (Google, GitHub, GitLab). Rekor is the transparency log that records all signatures for subsequent audit. Real adoption in 2026 has grown significantly: Kubernetes, Distroless, npm with provenance, GitHub Actions with OIDC.

in-toto attestations. Framework for cryptographically verifiable attestations over every pipeline step (who compiled, with which tools, on which source, with which inputs). Combined with SLSA and sigstore, it enables end-to-end provenance verification of an artefact.

NIST SSDF (Secure Software Development Framework, SP 800-218). US guidance on practices to integrate into the software lifecycle to reduce risk. It covers environment preparation, software protection, production of well-secured software and vulnerability response. Explicitly referenced by Executive Order 14028.

OpenSSF Best Practices Badge (formerly CII Best Practices). Programme where open source projects can self-certify at passing, silver and gold levels on basic, intermediate and advanced practices. Useful as a maturity signal when evaluating critical dependencies.

SBOM and regulatory obligations

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of the components that make up a piece of software, with their versions, licences, dependency relationships and provenance. Without an SBOM there is no realistic way to answer a question as simple as "are we affected by the vulnerability published today?" for a transitive dependency buried four levels under the application.

The two dominant formats are SPDX (ISO/IEC 5962:2021 standard, maintained by Linux Foundation) and CycloneDX (maintained by OWASP). Both cover the basic cases. SPDX has consolidated in environments with legal or licensing requirements; CycloneDX has consolidated in security due to integration with vulnerability management tooling.

Executive Order 14028 (May 2021, United States). Requires software suppliers to the US federal government to deliver SBOMs as a contract condition. It has pushed adoption upstream throughout the ecosystem.

EU Cyber Resilience Act (CRA). European regulation approved in 2024 with staggered entry into force. It requires manufacturers and distributors of products with digital elements (including software) to maintain SBOMs, manage vulnerabilities throughout the entire supported lifecycle, notify exploited vulnerabilities and deliver security updates. For a complete view of obligations, see the detail in Cyber Resilience Act.

Practical enterprise defence

A reasonable supply chain defence programme for a medium or large organisation combines the following controls, none of which is sufficient on its own.

Software asset inventory with continuous SBOM. Automatic SBOM generation for every deployed artefact, centralised storage, linkage with vulnerability feeds (NVD, OSV.dev). Without this step, every other control operates blind.

Code signing of all internal artefacts. Cosign integrated into pipelines, mandatory verification at deploy time, transparency log accessible for audit. Breaking the signature chain must block deployment.

Version pinning and lockfiles. package-lock.json, poetry.lock, Gemfile.lock, go.sum. Without pinning, every build resolves different dependencies and behaviour is non-reproducible. With pinning, upgrades are explicit and auditable.

Vulnerability scanning. Snyk, Trivy, Grype, Dependabot, Renovate. Pipeline integration with configurable blocking by severity. Important: build-time scanning does not replace runtime scanning over deployed images, because new vulnerabilities appear after deployment.

Internal package registry. Artifactory, Nexus, GitHub Packages, AWS CodeArtifact. All external packages go through the internal registry with pre-approval scanning. It mitigates dependency confusion (the resolver always queries the internal registry first) and allows control over which versions enter.

CI/CD hardening. Ephemeral runners (new runner per build, destroyed at the end), OIDC instead of long-lived credentials in the pipeline, least privilege on tokens, secrets in a dedicated manager, branch protection on branches that trigger deploys, mandatory review on pipeline changes.

SCA tools and licence compliance. Software Composition Analysis specific to detect dependencies with incompatible licences (GPL in a closed commercial product), abandoned libraries (no commits in years, single maintainer), EOL versions.

Vendor risk management. Security questionnaires for critical vendors, requirement of SBOM and certifications, contractual clauses on incident notification, response plan for vendor compromise (what we do in the first 48 hours if vendor X announces a breach). An external supply chain auditor is useful to validate this programme.

Open source consumption maturity

Organisations fall into four maturity levels regarding the open source they consume.

Passive. Whatever is available gets consumed, with no audit and no inventory. Any vulnerability or compromise is news the day it shows up in the media. This is the starting point for most non-tech companies.

Defensive. Inventory is maintained (SBOM), critical dependencies are audited (those on the hot path of the application, those touching sensitive data, those running with privileges), vulnerability feeds are monitored. This is the minimum reasonable level in 2026 for organisations with their own software product.

Active. On top of defensive, the organisation contributes upstream patches to critical dependencies, maintains internal forks when upstream doesn't respond on time, participates in programmes like OpenSSF Alpha-Omega to sustain critical projects.

Maintainer. The organisation officially maintains one or several open source projects that it consumes and that other organisations also consume. It implies a security commitment: vulnerability response SLA, security advisory programme, SLSA attestation, sigstore on releases.

The jump from passive to defensive is the most urgent and the most profitable per euro invested.

EU Cyber Resilience Act specifics

The CRA introduces a qualitative shift: for the first time in the EU, manufacturers are jointly responsible for the security of software throughout its entire supported lifecycle, not only at the point of sale. The four most relevant operational obligations are as follows.

SBOM per product. Must be available and kept up to date in a machine-readable format.

Vulnerability handling process. Report intake channel (security.txt, coordinated disclosure programme), assessment, mitigation and communication. Without a formal programme there is no compliance.

Notification of exploited vulnerabilities. ENISA and the national CSIRT must be notified within short deadlines once active exploitation is confirmed.

Security updates during supported lifecycle. The manufacturer defines the cycle (for example, five years from release), but during that cycle they are required to publish free security patches for known vulnerabilities.

Maximum fines reach fifteen million euros or 2.5 percent of global annual turnover. For additional compliance detail, see Cyber Resilience Act and manufacturer obligations.

Frequently asked questions

When is SBOM mandatory

Under Executive Order 14028, for every software supplier to the US federal government. Under the EU Cyber Resilience Act, for every manufacturer or distributor of products with digital elements placed on the European market, during the staggered application period that ends in 2027. In practice, any organisation with a serious security programme maintains an SBOM even when not formally required, because without an SBOM you cannot respond to the day's vulnerabilities.

Is real sigstore adoption in 2026 significant

Yes. Kubernetes signs releases with cosign, npm has supported provenance with sigstore since 2023, GitHub Actions emits OIDC for fulcio with no additional configuration, Distroless and Chainguard images are signed by default. Adoption is not universal but has moved from pilot project to assumed technology in critical open source projects.

Is SLSA L3 or L4 viable for a small or medium business

L3 is realistic for an SMB with well-configured CI/CD in GitHub Actions or GitLab, isolated runners and signing with cosign. L4 requires reproducible builds and documented human review over every change entering the build, which carries a high operational cost and is only justified on critical components. For most applications, L2 or L3 are reasonable targets.

Was the XZ Utils case avoidable

Not reliably with the usual controls. The attacker had legitimate access as co-maintainer, the commits were subtle, the implant only activated on builds with specific conditions (sshd loaded via systemd, not in testing). What does help: reproducible builds (any deviation between the official build and an independent rebuild should trigger an alert), cross review of build system changes, performance telemetry (Andres Freund detected it due to an anomalous 500ms latency), and reducing blind dependence on projects with a single maintainer.

What is dependency confusion

It is an attack where the attacker publishes a package on the public registry (npm, PyPI) with the same name as a private internal package of the victim. When the language resolver looks for dependencies, it prefers the highest available version. If the resolver queries the public registry first and finds version 99.99.99 of the package with the same name, it downloads the malicious version. Mitigation: internal registry with explicit priority, private scope or namespace, provenance validation.

Is Renovate sufficient as supply chain defence

Not on its own. Renovate (and Dependabot) automates pull requests to upgrade dependencies and keeps versions up to date, which reduces the exposure window to known vulnerabilities. It does not detect freshly published malicious packages (it isn't a scanner), it doesn't generate SBOMs, it doesn't sign artefacts. It is part of the programme, it doesn't replace it.

Related resources

• Software supply chain attacks and DevSecOps
• What is a CVE and how vulnerabilities are managed
• What is a backdoor: types and detection methods
• Kubernetes pentesting: cluster security
• Serverless pentesting on AWS Lambda
• Top 10 pentesting tools in 2026

Supply chain security with Secra

At Secra we help organisations build a software supply chain defence programme that is operable rather than paperwork. We audit CI/CD pipelines focusing on plausible compromises (runners, secrets, OIDC, artefact signing), we review SCA integration and vulnerability management, we validate SBOM generation and consumption, and we simulate compromises against internal dependencies to measure whether current detection responds on time.

We also work on hardening of internal registries (Artifactory, Nexus), adoption of sigstore and cosign in releases, alignment with SLSA levels 2 and 3, and preparation for Cyber Resilience Act obligations during the 2025 to 2027 application period.

If your organisation develops software, distributes it or critically depends on third-party components, contact us for a first assessment of supply chain risk.