SLSA Framework
What is SLSA Framework?
SLSA FrameworkSupply-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.
SLSA (pronounced "salsa") is a community framework hosted by OpenSSF that helps producers and consumers reason about the integrity of build pipelines. It defines build levels (L1-L3+ in current versions), source and dependency requirements, and signed provenance describing what was built, how, and from which inputs. Higher levels demand reproducible builds, hermetic build environments, isolated, ephemeral build platforms, and verifiable provenance. SLSA complements SBOM (which lists components) and frameworks like NIST SSDF and CISA Secure by Design. Adoption typically combines tools such as GitHub Actions reusable workflows, Tekton Chains, Sigstore Cosign, and in-toto attestations. SLSA is becoming a baseline expectation in regulated and federal procurement.
● Examples
- 01
Reaching SLSA build level 3 by using GitHub's reusable workflows and signed provenance.
- 02
Verifying SLSA provenance at deploy time as part of admission controls in Kubernetes.
● Frequently asked questions
What is 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. It belongs to the Application Security category of cybersecurity.
What does SLSA Framework mean?
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.
How does SLSA Framework work?
SLSA (pronounced "salsa") is a community framework hosted by OpenSSF that helps producers and consumers reason about the integrity of build pipelines. It defines build levels (L1-L3+ in current versions), source and dependency requirements, and signed provenance describing what was built, how, and from which inputs. Higher levels demand reproducible builds, hermetic build environments, isolated, ephemeral build platforms, and verifiable provenance. SLSA complements SBOM (which lists components) and frameworks like NIST SSDF and CISA Secure by Design. Adoption typically combines tools such as GitHub Actions reusable workflows, Tekton Chains, Sigstore Cosign, and in-toto attestations. SLSA is becoming a baseline expectation in regulated and federal procurement.
How do you defend against SLSA Framework?
Defences for SLSA Framework typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for SLSA Framework?
Common alternative names include: SLSA, Supply-chain Levels for Software Artifacts.
● Related terms
- appsec№ 1069
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.
- 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.
- appsec№ 522
in-toto
An open framework that cryptographically attests to every step of a software supply chain so that consumers can verify the artifact was built and handled exactly as the project owner intended.
- 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№ 226
Cosign
An open-source CLI from the Sigstore project for signing, verifying, and attesting to OCI artifacts and other software using either keyed or keyless workflows.
- appsec№ 921
Reproducible Builds
Build practices that ensure compiling the same source code with the same instructions produces a bit-for-bit identical artifact, regardless of when or where it is built.
● See also
- № 1068Software Bill of Materials (SBOM)
- № 784Package Signing
- № 166CI/CD Security