Supply chain attack

A supply chain attack subverts the trust relationship between an organisation and something it consumes from a third party, so the victim installs or authorises the compromise itself. MITRE ATT&CK catalogues the technique as T1195 (Supply Chain Compromise), with sub-techniques covering the software development environment, the software update mechanism and hardware. Attacks are usually classified into software supply chain (build systems, dependencies, updates, code-signing infrastructure) and hardware or third-party service compromise (a managed service provider, an OAuth-connected SaaS app, an outsourced help desk). The strategic appeal is leverage: one compromise upstream propagates to many downstream victims through a channel they already trust and often through signed, seemingly legitimate artefacts.

Two landmark cases define the modern understanding. In the 2020 SolarWinds Orion incident, attackers compromised the vendor's build pipeline and inserted the SUNBURST backdoor into a signed update distributed to thousands of organisations, demonstrating that a valid code signature attests only to who built an artefact, not that the artefact is benign. In 2024 the xz-utils / liblzma backdoor (CVE-2024-3094) showed the open-source variant: a maintainer identity was cultivated over years to insert an obfuscated backdoor into a widely used compression library feeding OpenSSH on many Linux distributions, caught by chance before broad release. Together they illustrate the two dominant vectors - compromising a commercial build/distribution channel, and compromising the open-source dependency graph, where transitive dependencies mean an application trusts code it never directly chose.

Defences focus on provenance, integrity and verification across the software lifecycle. A Software Bill of Materials (SBOM), in formats such as SPDX or CycloneDX, inventories components so that a newly disclosed vulnerability can be located quickly. Build-integrity frameworks (SLSA) and reproducible builds raise assurance that a released artefact corresponds to reviewed source; signing and transparency systems (Sigstore, in-toto attestations) bind artefacts to their provenance; dependency pinning, lockfiles and vetting reduce exposure to malicious or typosquatted packages. NIST SP 800-161 provides cyber supply-chain risk-management guidance. Regulation now mandates much of this: NIS2 Article 21 explicitly requires supply-chain security among its risk-management measures, and the EU Cyber Resilience Act obliges product manufacturers to manage vulnerabilities across components, with reporting duties applying from 11 September 2026. In OWASP Top 10:2025 this area is elevated to A03 Software Supply Chain Failures.

A central misconception is that a valid digital signature or a reputable vendor guarantees safety; both SolarWinds and xz-utils delivered maliciously modified but properly signed or officially distributed code. Another is scoping supply chain to purchased software only, ignoring open-source dependencies, CI/CD tooling, container base images and connected SaaS, which are equally part of the attack surface. Supply chain attack is a delivery strategy rather than a payload, distinct from the malware or backdoor it plants and from a direct intrusion; its defining feature is that the trust an organisation places in its suppliers must itself be treated as an attack surface to be verified.