Software supply chain

The underlying problem was stated by Ken Thompson in his 1984 Turing Award lecture "Reflections on Trusting Trust": a compromised compiler can insert a backdoor into every program it builds, including new copies of itself, so inspecting source code alone cannot establish trust. Modern frameworks decompose the chain into source, build, dependency and distribution stages and ask, for each artefact, who produced it, from what inputs, on which platform, and whether anything changed in transit. SLSA models threats at each stage and defines a Build track (L1 provenance exists; L2 signed provenance from a hosted build platform; L3 hardened, isolated builds) and, from v1.2, a Source track. in-toto supplies the attestation format - signed statements binding an artefact digest to a predicate such as SLSA provenance, an SBOM or test results - and Sigstore provides keyless signing and a transparency log for those statements. The Update Framework (TUF) addresses the distribution link with role separation, threshold signatures and expiring metadata that resist key compromise, rollback and freeze attacks.

Attack mechanisms map onto those links. Source: stolen maintainer credentials or malicious commits (ua-parser-js, 2021). Maintainer social engineering: the event-stream npm package (2018) was handed to a new maintainer who added a dependency targeting a cryptocurrency wallet; the xz Utils backdoor (CVE-2024-3094) was hidden in binary test files in the repository and activated by a build script that existed only in the release tarballs, so the malicious code was injected at build time into liblzma and reached sshd on distributions that linked it via libsystemd. Build: SolarWinds' SUNBURST (2020) was inserted by malware on the build server during compilation while the source repository stayed clean. Dependencies: typosquatting and dependency confusion abuse package-manager resolution rules. Distribution: compromised update servers or signing keys, as with the 2017 NotPetya spread through M.E.Doc updates.

Defences are cumulative rather than alternative. Reproducible builds let independent parties rebuild and compare digests, detecting build-time tampering; hermetic, ephemeral build environments and short-lived credentials limit what a compromised job can do; two-person review and protected branches address source threats; pinned, hash-verified dependencies with SCA and SBOMs address the dependency layer; signing and provenance verification at deployment close distribution. OpenSSF Scorecard gives heuristic risk signals for open-source projects, although none of these signals would reliably have caught the xz attack.

For governance, NIST SP 800-161r1 (2022) covers cyber supply chain risk management for acquirers, and NIST SP 800-218 (SSDF) and SP 800-204D cover producers. In the EU, NIS2 Article 21(2)(d) requires in-scope entities to address supply-chain security, including the security practices of their direct suppliers, and the Cyber Resilience Act requires manufacturers of products with digital elements to exercise due diligence on third-party components, with reporting obligations applicable since 11 September 2026 and full application from 11 December 2027.