SLSA framework for supply chain integrity levels guide

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework that provides a graduated set of requirements for securing the software build and release process. It solves the problem of software supply chain attacks — where attackers compromise build systems, CI/CD pipelines, or dependencies to insert malicious code into software without compromising the source code repository. SLSA defines four levels of increasingly rigorous requirements, from basic provenance documentation (L1) to fully hermetic, reproducible builds with two-party review (L4), giving organisations a concrete roadmap for hardening their software supply chains.

Build provenance is a cryptographically signed document that records how a software artifact was produced: which source code commit was used, which build system ran the build, which dependencies were included, and the timestamp of the build. It creates an auditable, tamper-evident chain of custody from source code to deployable artifact. Provenance is important because it allows you to verify that a binary was produced from the specific source code you expect, by the build system you trust, without any undocumented modifications — making supply chain attacks detectable. SLSA uses the in-toto Attestation Framework for provenance documents, which are signed using Sigstore's ephemeral signing infrastructure.

SLSA L2 is the practical minimum for organisations that supply software to enterprise or government customers, as it is now referenced in US federal procurement guidance (CISA) and several enterprise vendor security assessments. SLSA L2 requires that all production builds run on a hosted CI/CD service (not developer laptops) and that signed provenance is generated and available for consumers to verify. SLSA L3 is appropriate for high-value software (security tools, infrastructure software, anything handling sensitive data) and is increasingly required by major cloud providers and regulated industries. SLSA L4 (reproducible builds) is appropriate for the most critical infrastructure software and is currently achieved by only a small number of projects.

Sigstore is the cryptographic signing infrastructure that SLSA uses to sign provenance documents and software artifacts. Sigstore provides: Cosign for signing and verifying container images and other artifacts; Fulcio, a certificate authority that issues short-lived signing certificates tied to OIDC identities (GitHub Actions identities, Google service accounts); and Rekor, a transparency log that records all signatures for public audit. SLSA defines what should be signed (provenance documents with specific required fields) and the trust model; Sigstore provides the signing infrastructure that makes it possible to sign artifacts with verified CI/CD system identities without managing long-lived signing keys — a significant operational simplification.

SLSA provenance answers the question "how was this artifact built?" — documenting the build process, build system, and chain of custody. An SBOM (Software Bill of Materials) answers "what is in this artifact?" — providing a complete inventory of all software components, dependencies, and their versions. They are complementary: SLSA provenance proves the artifact was built without tampering from known sources; an SBOM documents what those sources contain so consumers can scan for known vulnerabilities. US Executive Order 14028 and CISA guidance require both from software vendors supplying to the federal government. The combination provides both process integrity (SLSA) and component visibility (SBOM).

SLSA provenance verification at deployment is typically implemented at the container registry or Kubernetes admission controller layer. For container images, Sigstore's policy-controller (a Kubernetes admission controller) can be configured to verify that all images have valid SLSA provenance attestations meeting a specified level before admission. The slsa-verifier CLI tool can verify provenance documents for binaries and other artifacts. For registry-level enforcement, AWS ECR supports Sigstore signatures through AWS Signer, and GitHub's container registry (GHCR) supports provenance attestations natively. The verification checks that the provenance signature is valid, that the signing identity matches the expected build system, and that the provenance fields meet SLSA level requirements.

A hermetic build is a build that is fully isolated from the external environment — all dependencies are pre-declared and resolved before the build starts, no network access is permitted during the build, and the same inputs always produce bit-for-bit identical outputs (reproducibility). Hermetic builds make supply chain attacks extremely difficult because there is no opportunity to inject malicious dependencies or modify the build environment during execution. SLSA L4 is difficult because achieving true reproducibility requires eliminating all sources of non-determinism in the build: timestamps embedded in binaries, random ordering in archives, compiler version variation, and operating system state. Most build systems have non-deterministic elements that must be explicitly addressed, and the toolchain ecosystem (compiler, linker, archive tools) must all support reproducible output modes.

No — SLSA is equally relevant and increasingly required for commercial software. The framework originated in the open-source ecosystem (driven by Google and the OpenSSF) but has been adopted as a supply chain security standard for all software. US government procurement guidance now references SLSA levels for commercial software vendors. Enterprise customers in financial services, healthcare, and critical infrastructure are including SLSA level requirements in vendor security questionnaires and contracts. For SaaS and internal enterprise software, SLSA provides the same value: protecting against CI/CD compromise, insider threats in the build process, and build environment tampering that can introduce vulnerabilities or backdoors into production deployments.