# What Is SLSA? Understanding Supply Chain Levels for Software Artifacts

> What is SLSA? The OpenSSF framework for software supply chain security defines three build levels for provenance and integrity. Learn how SLSA works, how it builds on in-toto, and how to adopt it with GitHub Actions.

- **Author:** Cowboy Neil
- **Published:** 2024-08-17
- **Categories:** Education
- **Tags:** Slsa, Security, Supply-Chain, Provenance
- **Updated:** 2026-03-20

**TL;DR:** SLSA (pronounced 'salsa') is a framework of three progressively stronger build levels that ensure software artifacts have verifiable provenance – a signed, tamper-evident record of how, where, and by whom they were built. Maintained by the OpenSSF, SLSA builds on the in-toto attestation format and is natively supported by GitHub Actions, Google Cloud Build, and other CI/CD platforms.

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](https://slsa.dev/)** (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)](https://openssf.org/), 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](https://sbomify.com/2024/08/14/what-is-in-toto/) 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](https://sbomify.com/2024/08/14/what-is-in-toto/) – 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](https://sbomify.com/2024/08/12/what-is-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](https://slsa.dev/spec/v1.0/threats-overview) identifies attacks at each stage of the development process.

| Threat                     | Example                                              | SLSA Level              |
| -------------------------- | ---------------------------------------------------- | ----------------------- |
| No provenance              | Consumers cannot verify how an artifact was built    | Build L1                |
| Forged provenance          | Developer fabricates provenance for a modified build | Build L2                |
| Compromised build platform | Attacker injects code via CI/CD infrastructure       | Build L3                |
| Compromised source         | Unauthorized commit pushed to repo                   | Source track (separate) |
| Compromised dependencies   | Malicious transitive dependency                      | Not yet covered by SLSA |

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](https://sbomify.com/what-is-sbom/) and [vulnerability scanning](https://sbomify.com/2026/02/01/sbom-scanning-vulnerability-detection/).

## Real-World Adoption

### GitHub Actions

GitHub's [artifact attestation](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds) feature generates SLSA Build L1 provenance for any artifact built with GitHub Actions. The provenance is an [in-toto attestation](https://sbomify.com/2024/08/14/what-is-in-toto/) signed via [Sigstore](https://sbomify.com/2024/08/12/what-is-sigstore/) and stored alongside the artifact. Verification is available via the GitHub CLI:

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

For Build L2/L3, the [slsa-github-generator](https://github.com/slsa-framework/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](https://sbomify.com/2024/08/12/what-is-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](https://sbomify.com/what-is-sbom/) 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](https://sbomify.com/2024/08/14/what-is-in-toto/), signed with [Sigstore](https://sbomify.com/2024/08/12/what-is-sigstore/), and managed alongside artifacts. For organizations using [sbomify](https://sbomify.com) 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:

```yaml
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](https://github.com/slsa-framework/slsa-github-generator) for isolated provenance generation that the calling workflow cannot tamper with:

```yaml
jobs:
  build:
    # ... your build steps ...
  provenance:
    needs: build
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: ${{ needs.build.outputs.digest }}
```

### Step 3: Verify Provenance

Consumers can verify provenance using the SLSA verifier:

```bash
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](https://sbomify.com/compliance/eo-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)](https://csrc.nist.gov/publications/detail/sp/800-218/final)** 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](https://sbomify.com/compliance/eu-cra/)** requires demonstrating supply chain security processes. SLSA provenance provides auditable evidence of build integrity.
- **[CISA minimum elements](https://sbomify.com/compliance/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)](https://openssf.org/).

### 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](https://sbomify.com/2024/08/14/what-is-in-toto/) 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](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds). The [slsa-github-generator](https://github.com/slsa-framework/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](https://sbomify.com/compliance/eo-14028/) (which requires attestation of secure development practices), the [NIST SSDF](https://csrc.nist.gov/publications/detail/sp/800-218/final) (which requires protecting build integrity), and the [EU Cyber Resilience Act](https://sbomify.com/compliance/eu-cra/) (which requires supply chain security processes). Adopting SLSA helps demonstrate compliance with these frameworks.

---

From sbomify: https://sbomify.com/2024/08/17/what-is-slsa/