The software supply chain is everything that goes into producing a piece of software before it reaches a user: the source code, the open-source libraries it depends on, the dependencies of those dependencies, the compilers and build tools, the package registries that deliver them, and the people and accounts authorized to publish along the way. Modern applications pull from hundreds of these links automatically, so the chain is far longer than most teams realize.
The SLSA framework, an industry effort to secure this chain, describes the problem as “the complex process of getting that code into software systems” and aims to provide “guidelines and tamper-resistant evidence for securing each step of the software production process” (https://slsa.dev/spec/v1.0/about). The goal it states is the heart of supply-chain security: ensuring “the code that you run is actually the code that you scanned,” by attaching proof of which build platform produced an artifact and guarding against unauthorized modification.
Governments treat this as a first-order risk. The NIST Secure Software Development Framework (SP 800-218) lists “cybersecurity supply chain risk management” among its core topics and is written so that “software purchasers and consumers” can “foster communications with suppliers in acquisition processes” (https://csrc.nist.gov/pubs/sp/800/218/final). In other words, securing software now means securing the chain that delivers it, not just the final product.
Real incidents show why every link matters. The left-pad episode showed how removing one tiny package could break builds across the ecosystem; the xz backdoor showed how a trusted maintainer could plant hidden malicious code in a foundational library; and the SolarWinds compromise showed how attackers could subvert a build system to ship a backdoor to thousands of customers at once. Supply-chain security is the discipline of defending all of these links, registries, build systems, dependencies, and maintainers, against tampering.