What Is SLSA? Understanding Supply Chain Levels for Software Artifacts

In 2020, attackers compromised SolarWinds’ build system and injected malicious code into Orion software updates that were distributed to roughly 18,000 organizations, including multiple U.S. government agencies. The attack succeeded because there was no verifiable record of what the build system was supposed to produce — so no one noticed when it started producing something different.

SLSA (Supply chain Levels for Software Artifacts, pronounced “salsa”) is a framework designed to prevent exactly this kind of attack. It defines a set of progressively stronger requirements for how software is built, producing a signed, tamper-evident record — called provenance — that documents exactly how, where, and by whom an artifact was created. Maintained by the Open Source Security Foundation (OpenSSF), SLSA provides a common language for describing build security maturity, from basic documentation to hardened, tamper-resistant build platforms.

The SLSA Build Levels

SLSA v1.0 defines three build levels, each adding stronger guarantees against different classes of supply chain threats.

Build L1: Provenance Exists

At Level 1, the build process produces provenance — a document that records what was built, from what source, using which build system. The provenance format is an in-toto attestation with an SLSA Provenance predicate.

Requirements:

• Provenance is generated and available to consumers
• The provenance document follows the SLSA provenance format
• The build process is documented

What it prevents: Build L1 does not prevent attacks, but it creates a baseline of transparency. If a compromised artifact is later discovered, provenance helps trace where the failure occurred. It also enables consumers to make informed decisions about which artifacts to trust.

Build L2: Hosted Build Platform

At Level 2, provenance must be generated by a hosted build service — not the developer’s local machine. The build service signs the provenance, attesting that it accurately reflects the build it performed.

Requirements:

• All Build L1 requirements
• Builds run on a hosted build platform (e.g., GitHub Actions, Google Cloud Build, GitLab CI)
• The build platform generates and signs the provenance (the developer cannot forge it)
• Provenance includes the builder identity, source reference, and build configuration

What it prevents: Build L2 prevents developers from fabricating provenance. Because the build platform generates the provenance, a compromised developer account cannot create forged provenance claiming an artifact was built from clean source code when it was not.

Build L3: Hardened Builds

At Level 3, the build platform itself must be hardened against tampering. Builds run in isolated environments where even the build platform’s own administrators cannot manipulate individual builds.

Requirements:

• All Build L2 requirements
• Builds run in isolated, ephemeral environments
• The build platform prevents cross-build contamination (one build cannot influence another)
• Secrets and signing keys are isolated from build workloads
• The build platform has a verifiable record of its own integrity

What it prevents: Build L3 prevents insider threats at the build platform level. Even if an attacker compromises the CI/CD infrastructure, the isolation guarantees mean they cannot inject code into a specific build without detection. This is the level required to defend against SolarWinds-class attacks.

How SLSA Provenance Works

SLSA provenance is a machine-readable document that answers three questions about a software artifact:

1. What was built? — The artifact’s digest (cryptographic hash)
2. How was it built? — The source repository, commit, build configuration, and builder identity
3. Who built it? — The build platform and its identity credentials

Provenance is expressed as an in-toto attestation — a signed envelope containing a typed predicate. The SLSA Provenance predicate type includes fields for the builder, build configuration, source materials, and metadata. The attestation is signed using Sigstore (keyless signing) or traditional key-based signing, and the signature is recorded in a transparency log.

A simplified example of what provenance captures:

Subject:    my-app:v1.2.3 (sha256:abc123...)
Builder:    GitHub Actions (github.com/actions/runner)
Source:     github.com/my-org/my-app @ commit def456
Build:      .github/workflows/release.yml
Timestamp:  2026-02-20T14:30:00Z

Consumers verify provenance by checking the signature, confirming the builder identity, and validating that the source and build configuration match their expectations. Tools like cosign verify-attestation and slsa-verifier automate this process.

The Supply Chain Threats SLSA Addresses

SLSA’s levels map to specific threat categories in the software supply chain. The framework’s threat model identifies attacks at each stage of the development process.

Note that SLSA v1.0 focuses on the build track. Source integrity (protecting the source repository from unauthorized changes) is being developed as a separate track. Dependency management is out of scope for SLSA but is addressed by complementary tools like SBOMs and vulnerability scanning.

Real-World Adoption

GitHub Actions

GitHub’s artifact attestation feature generates SLSA Build L1 provenance for any artifact built with GitHub Actions. The provenance is an in-toto attestation signed via Sigstore and stored alongside the artifact. Verification is available via the GitHub CLI:

gh attestation verify my-artifact.tar.gz --owner my-org

For Build L2/L3, the slsa-github-generator uses GitHub’s reusable workflows to generate provenance in an isolated build context, preventing the calling workflow from tampering with the provenance.

Google Cloud Build

Google Cloud Build natively generates SLSA Build L3 provenance for container images. Provenance is automatically signed and can be verified using Binary Authorization for admission control in GKE clusters.

npm and PyPI

The npm registry includes SLSA provenance for packages built via GitHub Actions, and PyPI supports provenance through its Trusted Publishers feature. Both use Sigstore for signing, allowing consumers to verify that a package was built from the stated source.

Kubernetes

All Kubernetes release artifacts include SLSA Build L3 provenance, allowing cluster operators to verify that the binaries they deploy were produced by the Kubernetes project’s official build infrastructure.

SLSA and SBOMs

SLSA and SBOMs address different parts of the software supply chain security problem, and they are most effective when used together.

• SLSA provenance answers: How was this artifact built, and can I trust the build process?
• SBOMs answer: What components are inside this artifact, and do any have known vulnerabilities?

An organization that generates SLSA provenance for its builds and produces SBOMs for its artifacts covers both integrity (the build was not tampered with) and visibility (the contents are known and monitorable). Provenance without an SBOM means you trust the build but do not know what is inside. An SBOM without provenance means you know what is inside but cannot verify the build was legitimate.

Both SLSA provenance and SBOMs can be expressed as in-toto attestations, signed with Sigstore, and managed alongside artifacts. For organizations using sbomify for SBOM management, pairing SBOMs with SLSA provenance provides a comprehensive picture: verified build integrity and a complete component inventory.

Getting Started with SLSA

Step 1: Achieve Build L1

Generate provenance for your builds. If you use GitHub Actions, enable artifact attestations:

permissions:
  id-token: write
  contents: read
  attestations: write

steps:
  - uses: actions/checkout@v4
  - run: make build
  - uses: actions/attest-build-provenance@v2
    with:
      subject-path: dist/my-app

This produces an SLSA Build L1 provenance attestation signed via Sigstore.

Step 2: Move to Build L2/L3

Use the slsa-github-generator for isolated provenance generation that the calling workflow cannot tamper with:

jobs:
  build:
    # ... your build steps ...
  provenance:
    needs: build
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      base64-subjects: ${{ needs.build.outputs.digest }}

Step 3: Verify Provenance

Consumers can verify provenance using the SLSA verifier:

slsa-verifier verify-artifact my-app \
  --provenance-path my-app.intoto.jsonl \
  --source-uri github.com/my-org/my-app

SLSA in the Compliance Context

SLSA aligns with emerging supply chain security regulations:

• Executive Order 14028 requires software producers to attest to secure development practices, including build integrity. SLSA provenance provides the mechanism for this attestation.
• NIST SSDF (SP 800-218) recommends protecting all forms of code from unauthorized access and tampering. SLSA’s build levels directly address this by progressively hardening the build process.
• EU CRA requires demonstrating supply chain security processes. SLSA provenance provides auditable evidence of build integrity.
• CISA minimum elements recommend that SBOMs include build information. SLSA provenance complements SBOMs by providing detailed, verified build records.

Frequently Asked Questions

What is SLSA?

SLSA (Supply chain Levels for Software Artifacts, pronounced “salsa”) is a security framework that defines three build levels of increasing rigor for producing software artifacts with verifiable provenance. It provides a common language for describing build security maturity, from basic provenance documentation (Build L1) to hardened, tamper-resistant build platforms (Build L3). SLSA is maintained by the Open Source Security Foundation (OpenSSF).

What are the SLSA build levels?

SLSA v1.0 defines three build levels. Build L1 requires that provenance exists and documents the build process. Build L2 requires that provenance is generated by a hosted build platform (not the developer’s machine), making it harder to forge. Build L3 requires a hardened build platform with isolated, tamper-resistant build environments, preventing even the build platform’s own administrators from manipulating individual builds.

How is SLSA related to in-toto?

SLSA uses the in-toto attestation format for all its provenance documents. An SLSA provenance attestation is an in-toto attestation with a specific predicate type that records build parameters, source information, and builder identity. in-toto provides the format; SLSA provides the security requirements.

How do I get started with SLSA?

The fastest path is to use a CI/CD platform that already supports SLSA provenance generation. GitHub Actions provides SLSA Build L1 provenance through its artifact attestation feature. The slsa-github-generator can produce Build L2/L3 provenance. Google Cloud Build also supports SLSA provenance natively.

Is SLSA required by any regulations?

SLSA is not mandated by name in any regulation, but its requirements align with Executive Order 14028 (which requires attestation of secure development practices), the NIST SSDF (which requires protecting build integrity), and the EU Cyber Resilience Act (which requires supply chain security processes). Adopting SLSA helps demonstrate compliance with these frameworks.