Software Supply Chain Security
What is Software Supply Chain Security?
Software Supply Chain SecurityThe discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss.
Software supply chain security treats code as something assembled from many sources rather than written from scratch. It covers source repository protection, identity for developers, secure CI/CD, dependency curation, SBOM and CBOM generation, signing and verification (Sigstore, Cosign, in-toto), provenance attestation per SLSA, vulnerability management, secrets handling, and policy enforcement at deployment. The discipline emerged in response to incidents like SolarWinds, Codecov, Log4Shell, XZ Utils, and dependency confusion campaigns. Frameworks and guidance include SLSA, NIST SSDF (SP 800-218), CISA Secure by Design, US EO 14028, and the EU Cyber Resilience Act, all converging on signed, verifiable, transparent pipelines.
● Examples
- 01
End-to-end signed pipeline with SLSA L3 provenance and Cosign-verified deployments.
- 02
Curated internal package proxy combined with SBOM-driven vulnerability response.
● Frequently asked questions
What is Software Supply Chain Security?
The discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss. It belongs to the Application Security category of cybersecurity.
What does Software Supply Chain Security mean?
The discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss.
How does Software Supply Chain Security work?
Software supply chain security treats code as something assembled from many sources rather than written from scratch. It covers source repository protection, identity for developers, secure CI/CD, dependency curation, SBOM and CBOM generation, signing and verification (Sigstore, Cosign, in-toto), provenance attestation per SLSA, vulnerability management, secrets handling, and policy enforcement at deployment. The discipline emerged in response to incidents like SolarWinds, Codecov, Log4Shell, XZ Utils, and dependency confusion campaigns. Frameworks and guidance include SLSA, NIST SSDF (SP 800-218), CISA Secure by Design, US EO 14028, and the EU Cyber Resilience Act, all converging on signed, verifiable, transparent pipelines.
How do you defend against Software Supply Chain Security?
Defences for Software Supply Chain Security typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Software Supply Chain Security?
Common alternative names include: Software supply chain, Build supply chain security.
● Related terms
- attacks№ 1116
Supply Chain Attack
An attack that compromises a trusted third-party software, hardware, or service provider in order to reach its downstream customers.
- appsec№ 1053
SLSA Framework
Supply-chain Levels for Software Artifacts: a tiered set of requirements published by OpenSSF that progressively hardens how software is built, signed, and verified against supply-chain tampering.
- appsec№ 1068
Software Bill of Materials (SBOM)
A formal, machine-readable inventory of the components, libraries, and dependencies that make up a piece of software, along with their versions and relationships.
- appsec№ 1044
Sigstore
An open-source Linux Foundation project that makes signing, verifying, and protecting software artifacts easy by combining short-lived keys, OIDC identities, and a transparency log.
- appsec№ 166
CI/CD Security
The set of controls protecting continuous integration and continuous delivery pipelines from compromise, code injection, secret leakage, and unauthorized deployments.
- appsec№ 870
Provenance Attestation
A signed, machine-verifiable statement that describes how a software artifact was produced - including source, build system, parameters, and dependencies - so consumers can trust its origin.
● See also
- № 245Cryptographic Bill of Materials (CBOM)
- № 226Cosign
- № 522in-toto
- № 304Dependency Confusion Attack
- № 305Dependency Pinning
- № 784Package Signing
- № 921Reproducible Builds
- № 444GitOps Security