17.6 The SLSA Framework¶

Common Language for Supply Chain Security

SLSA ("salsa") provides a checklist of standards to prevent tampering and improve integrity. More than a technical specification, it's a communication tool—a way to set expectations between software producers and consumers about security properties.

After the SolarWinds attack demonstrated how vulnerable software supply chains could be, the industry needed a common language to discuss and measure supply chain security. Google open-sourced their internal build security framework, which became SLSA¹ (Supply-chain Levels for Software Artifacts, pronounced "salsa"). SLSA provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. More than a technical specification, SLSA serves as a communication tool—a way to set expectations between software producers and consumers about the security properties of artifacts.

This section provides a comprehensive guide to the SLSA framework, including its levels, requirements, implementation strategies, and practical adoption approaches.

Understanding SLSA¶

SLSA is a security framework that defines incrementally adoptable levels of supply chain security. Rather than requiring perfect security immediately, SLSA provides a maturity model where organizations can progressively improve.

Core SLSA Concepts:

Concept	Definition
Artifact	An immutable blob of data (binary, package, container)
Attestation	Authenticated statement about an artifact
Provenance	Metadata about how an artifact was produced
Build platform	System that produces artifacts from source
Level	Degree of supply chain integrity achieved

What SLSA Addresses:

┌─────────────────────────────────────────────────────────────────┐
│                 SUPPLY CHAIN THREATS AND SLSA                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Source Threats:                                                │
│  • Unauthorized source changes    → Source track (future)       │
│  • Compromised source repository  → Source track (future)       │
│                                                                 │
│  Build Threats:                                                 │
│  • Compromised build process      → Build track (L1-L3)         │
│  • Modified build outputs         → Build track (L1-L3)         │
│  • Compromised dependencies       → Dependencies track (future) │
│                                                                 │
│  Distribution Threats:                                          │
│  • Tampering after build          → Build track + signing       │
│  • Registry compromise            → Build track + verification  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

SLSA Version History:

SLSA v0.1 (2021): Initial release with levels 1-4
SLSA v1.0 (2023): Major revision, levels 0-3, track separation
Current: v1.0 specification with Build track as primary focus

The SLSA framework emphasizes incremental progress over perfection, providing organizations with a roadmap for continuous improvement in supply chain security rather than demanding immediate perfect compliance.

SLSA Tracks¶

SLSA v1.0 separates requirements into tracks, each addressing different aspects of supply chain security.

Current Tracks:

Track	Status	Focus
Build	Stable (v1.0)	How artifacts are built
Source	Future	Source code integrity
Dependencies	Planned	Dependency verification

Build Track (Primary Focus):

The Build track is the most mature and widely implemented. It addresses:

Build platform integrity
Provenance generation
Isolation between builds
Tamper resistance

Source Track (Future):

The Source track will address:

Source repository integrity
Code review requirements
Two-person review
Verified source history

Dependencies Track (Future):

The Dependencies track will address:

Dependency verification
Transitive dependency tracking
Dependency provenance

SLSA Levels and Requirements¶

SLSA defines four levels (L0-L3), each building on the previous.

SLSA Level Summary

L0: No guarantees. L1: Provenance exists (trust generator). L2: Hosted build with signed provenance (trust build service). L3: Hardened, isolated, tamper-resistant builds (trust hardened platform). Start at L1, progress incrementally.

Level Summary Table:

Level	Name	Key Requirement	Trust Model
L0	No guarantees	No SLSA	No provenance
L1	Provenance exists	Build provenance generated	Trust provenance generator
L2	Hosted build	Signed provenance, hosted platform	Trust build service
L3	Hardened builds	Isolated, tamper-resistant builds	Trust hardened platform

Detailed Requirements:

Level 0: No Guarantees

No SLSA requirements met. This is the baseline—most software today.

L0: "I built this on my laptop"

Characteristics:
• No provenance
• No verification possible
• Full trust in producer

Level 1: Build Provenance Exists

Provenance automatically generated by the build process.

Requirement	Description
Provenance exists	Artifact has provenance attestation
Provenance format	Follows SLSA provenance schema
Provenance content	Includes builder, source, timestamp

// L1 Provenance example
{
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "...",
      "externalParameters": {
        "source": {"uri": "git+https://github.com/org/repo", "digest": {"sha1": "..."}}
      }
    },
    "runDetails": {
      "builder": {"id": "https://example.com/builder"},
      "metadata": {"startedOn": "2024-01-15T10:00:00Z"}
    }
  }
}

Level 2: Hosted Build Platform

Provenance is signed and generated by a hosted build service.

Requirement	Description
Hosted platform	Build runs on dedicated infrastructure
Signed provenance	Provenance cryptographically signed
Authenticated builder	Builder identity verifiable

L2 Properties:
┌────────────────────────────────────────────────────────────────┐
│                                                                │
│  ┌─────────────────┐        ┌─────────────────┐                │
│  │  Source Repo    │───────►│  Hosted Build   │                │
│  └─────────────────┘        │  Service        │                │
│                             │  (GitHub Actions,│               │
│                             │   Cloud Build)   │               │
│                             └────────┬────────┘                │
│                                      │                         │
│                                      ▼                         │
│                             ┌─────────────────┐                │
│                             │ Signed          │                │
│                             │ Provenance      │                │
│                             │ (verifiable)    │                │
│                             └─────────────────┘                │
│                                                                │
└────────────────────────────────────────────────────────────────┘

Level 3: Hardened Builds

Build platform provides strong isolation and tamper resistance.

Requirement	Description
Isolated builds	Builds cannot influence each other
Ephemeral environment	Build environment created fresh each time
Enumerated external parameters	Inputs controlled by users are captured in provenance
Unforgeable provenance	Provenance cannot be forged by build steps

L3 Properties:
• Isolated builds (no cross-build influence)
• Ephemeral runners (clean environment each build)
• Unforgeable provenance (generated by platform, not build)
• External parameters fully enumerated in provenance

Requirements Matrix:

Requirement	L1	L2	L3
Provenance exists	✓	✓	✓
Follows SLSA format	✓	✓	✓
Signed provenance		✓	✓
Hosted build platform		✓	✓
Authenticated builder		✓	✓
Isolated builds			✓
Ephemeral environment			✓
External parameters enumerated			✓
Unforgeable provenance			✓

Practical Steps to Achieve Each Level¶

Achieving SLSA Level 1¶

Level 1 requires that provenance exists. This is achievable with minimal changes, and includes the following steps:

Step 1: Generate provenance during build

# GitHub Actions: Basic provenance generation
name: Build with Provenance

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v4

      - name: Build

        run: |
          make build
          # Generate basic provenance
          cat > provenance.json << EOF
          {
            "_type": "https://in-toto.io/Statement/v1",
            "subject": [{"name": "artifact.tar.gz", "digest": {"sha256": "$(sha256sum artifact.tar.gz | cut -d' ' -f1)"}}],
            "predicateType": "https://slsa.dev/provenance/v1",
            "predicate": {
              "buildDefinition": {
                "buildType": "https://example.com/basic-build",
                "externalParameters": {"source": "${{ github.repository }}@${{ github.sha }}"}
              },
              "runDetails": {
                "builder": {"id": "https://github.com/actions/runner"}
              }
            }
          }
          EOF

      - uses: actions/upload-artifact@v4

        with:
          name: release
          path: |
            artifact.tar.gz
            provenance.json

Step 2: Document provenance location

Step 3: Make provenance discoverable

Achieving SLSA Level 2¶

Level 2 requires hosted builds with signed provenance. Use established tools.

Step 1: Use SLSA GitHub generators

# GitHub Actions: L2 with slsa-github-generator
name: Release with SLSA L2

on:
  push:
    tags:

      - 'v*'

permissions:
  contents: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:

      - uses: actions/checkout@v4
      - id: build

        run: |
          make release
          echo "digest=$(sha256sum dist/release.tar.gz | base64 -w0)" >> $GITHUB_OUTPUT

      - uses: actions/upload-artifact@v4

        with:
          name: release
          path: dist/release.tar.gz

  provenance:
    needs: build
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
    with:
      base64-subjects: ${{ needs.build.outputs.digest }}
      upload-assets: true

Step 2: Verify provenance is generated and signed

# Verify the provenance
slsa-verifier verify-artifact release.tar.gz \
    --provenance-path release.tar.gz.intoto.jsonl \
    --source-uri github.com/myorg/myrepo

Step 3: Document builder identity in security documentation

Achieving SLSA Level 3¶

Level 3 requires hardened build platforms. Some hosted platforms and ecosystem-specific generators offer L3-capable configurations when used with their documented constraints.

Step 1: Use L3-capable generators

# The slsa-github-generator can help meet L3 requirements
# when used correctly and paired with distribution and verification
name: Release with SLSA L3

on:
  release:
    types: [created]

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

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      artifacts: ${{ steps.build.outputs.artifacts }}
      digests: ${{ steps.hash.outputs.digests }}
    steps:

      - uses: actions/checkout@v4

      # Build in isolated, ephemeral environment

      - name: Build

        id: build
        run: |
          # Build commands - no network access to external resources
          make release
          echo "artifacts=dist/release.tar.gz" >> $GITHUB_OUTPUT

      - name: Generate hash

        id: hash
        run: |
          DIGEST=$(sha256sum dist/release.tar.gz | base64 -w0)
          echo "digests=$DIGEST" >> $GITHUB_OUTPUT

      - uses: actions/upload-artifact@v4

        with:
          name: release-artifacts
          path: dist/

  # Use L3 generator (isolated provenance generation)
  provenance:
    needs: build
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
    with:
      base64-subjects: ${{ needs.build.outputs.digests }}
      upload-assets: true
      # Provenance generated in isolated environment
      # Cannot be influenced by build job

Step 2: Ensure build isolation

# Container build with provenance; L3 depends on the builder and policy
jobs:
  build-container:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
    steps:

      - uses: actions/checkout@v4

      - uses: docker/build-push-action@v5

        id: build
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.sha }}
          provenance: true  # BuildKit generates provenance
          sbom: true

Step 3: Verify L3 requirements met

# Verify L3 provenance
slsa-verifier verify-image ghcr.io/myorg/myapp@sha256:... \
    --source-uri github.com/myorg/myapp \
    --print-provenance | jq '.predicate.runDetails.builder.id'
# Should show L3-capable builder

Ecosystem Support¶

SLSA adoption varies across package ecosystems.

Ecosystem Support Matrix:

Ecosystem	Native Provenance	SLSA Level	Verification
npm	✅ Yes	Depends on trusted publishing/build flow	`npm audit signatures`
PyPI	✅ Yes (Attestations)	Depends on publishing workflow	slsa-verifier, sigstore-python
Go	⚠️ Via tools	Depends on builder	slsa-verifier
Containers	✅ Yes (BuildKit)	Depends on builder	cosign, slsa-verifier
Maven Central	⚠️ Limited	L1-L2	slsa-verifier
GitHub Releases	✅ Yes	Depends on generator/builder	slsa-verifier
crates.io	⚠️ Trusted Publishing	L1-L2 (via external tools)	slsa-verifier

npm SLSA Support:

# Publish with provenance
npm publish --provenance

# Verify package provenance
npm audit signatures

# Output:
# 247 packages have verified registry signatures
# 89 packages have verified attestations

Valid provenance is not proof of safe inputs

Provenance attests how and where an artifact was built; it does not prove that the build inputs, cache state, workflow trigger, or pipeline identity were uncompromised. In the 2026 "Mini Shai-Hulud" TanStack compromise (CVE-2026-45321, CVSS 9.6), reporting tied 42 packages and 84 versions to a chained GitHub Actions path involving pull_request_target, cache poisoning, and runtime extraction of an OIDC token from the Actions runner. The attacker did not need to steal npm tokens: trusted publishing let attacker-controlled code inside the workflow mint a short-lived publish token through the project's own release pipeline, and the malicious versions reportedly carried valid SLSA Build Level 3 provenance attestations—the first documented npm worm reported to do so.³ For the worm narrative, see Book 1, Section 10.11; the CI/CD lesson here is narrower: valid provenance can describe a compromised pipeline faithfully.

We recommend verifying provenance and hardening the release pipeline that produces it. Use trusted runners for releases, scope trusted-publishing/OIDC trust to protected branches, workflow files, tags, and environments, treat caches as untrusted unless their keys and contents are integrity-protected, keep OIDC token scope and lifetime minimal, and prevent PR-triggered jobs from reaching publish authority.

PyPI SLSA Support:

# Using Trusted Publishers for PyPI
name: Publish to PyPI

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      id-token: write  # Required for Trusted Publishing
    steps:

      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: pip install build
      - run: python -m build
      - uses: pypa/gh-action-pypi-publish@release/v1

        # No password needed - uses OIDC

Container SLSA Support:

# Build with provenance using Docker BuildKit
docker buildx build \
    --provenance=true \
    --sbom=true \
    --push \
    -t ghcr.io/myorg/myapp:v1.0.0 .

# Verify
cosign verify-attestation \
    --type slsaprovenance \
    --certificate-identity-regexp 'https://github.com/myorg/*' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    ghcr.io/myorg/myapp:v1.0.0

SLSA as a Communication Tool¶

SLSA provides shared vocabulary for procurement and vendor requirements.

Using SLSA in Procurement:

# Vendor Security Requirements

### Software Supply Chain

All software provided to [Organization] must meet the following SLSA requirements:

**Minimum Requirements (All Software):**

- SLSA Build Level 2 or higher
- Signed provenance available for verification
- Source repository disclosed

**Critical Software Requirements:**

- SLSA Build Level 3
- Reproducible builds preferred
- Independent verification capability

**Verification:**

- Vendor must provide provenance attestations
- Attestations must be verifiable using slsa-verifier or equivalent
- Verification results must be documented before deployment

Vendor Questionnaire:

Question	Expected Response
What SLSA level do your artifacts achieve?	L2 or L3
Where is provenance stored?	Registry, Rekor, or provided
What builder generates your provenance?	Named builder (e.g., GitHub Actions)
Can we verify provenance independently?	Yes, using [tool/method]
Do you publish build reproducibility info?	Yes/No, location

Contract Language:

Vendor shall provide software artifacts that meet SLSA Build 
Level 2 requirements as defined by slsa.dev/spec/v1.0. 
Specifically:

(a) All artifacts shall include signed provenance attestations
    in SLSA provenance v1.0 format.

(b) Provenance shall be generated by an authenticated build 
    platform and signed using Sigstore or equivalent PKI.

(c) Buyer shall be able to verify provenance using publicly 
    available tools (slsa-verifier or equivalent).

(d) Vendor shall notify Buyer within 24 hours if provenance 
    generation is compromised or unavailable.

Limitations and Criticisms¶

SLSA addresses specific threats but has known limitations.

What SLSA Doesn't Cover:

Gap	Explanation
Source code quality	SLSA doesn't assess code security
Vulnerability presence	Artifact can be L3 and still have CVEs
Malicious maintainer	L3 doesn't prevent intentional backdoors
Dependency security	Current spec doesn't verify dependencies
Runtime security	Only addresses build-time properties

SLSA Scope:
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  ✓ SLSA Addresses              ✗ SLSA Doesn't Address          │
│  ─────────────────             ───────────────────────          │
│  • Build integrity             • Code quality                   │
│  • Provenance generation       • Vulnerability presence         │
│  • Build platform security     • Malicious code in source       │
│  • Tamper detection            • Runtime security               │
│  • Artifact authenticity       • Operational security           │
│                                • Social engineering             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Common Criticisms:

1. "SLSA L3 doesn't prevent supply chain attacks"

Response: Correct. SLSA makes certain attacks harder and detectable, not impossible. A malicious maintainer can still insert backdoors at L3. SLSA's value is raising the bar and enabling verification—not perfect prevention.

2. "The levels are too complex"

Response: SLSA v1.0 simplified significantly from v0.1. Three meaningful levels (L1-L3) with clear requirements is more manageable than many compliance frameworks.

3. "No one verifies provenance"

Response: Adoption is growing. npm verification is built-in. Kubernetes admission controllers can enforce provenance. As tooling improves, verification becomes automatic.

4. "SLSA focuses too much on build"

Response: Valid criticism. The Source and Dependencies tracks are still developing. Build was prioritized because build compromise (SolarWinds) was the most impactful recent attack.

5. "Small projects can't achieve L3"

Response: Using GitHub Actions with SLSA generators, L3 is achievable for many GitHub-hosted projects. The tooling abstracts much of the complexity, but projects still need proper provenance distribution and verification.

SLSA represents progress toward better security rather than perfect security—an approach that favors incremental improvement over unattainable ideals.

SLSA Verification Tooling¶

Several tools verify SLSA provenance.

slsa-verifier²:

The official SLSA verification tool.

# Install
go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest

# Verify generic artifact
slsa-verifier verify-artifact artifact.tar.gz \
    --provenance-path artifact.tar.gz.intoto.jsonl \
    --source-uri github.com/myorg/myrepo \
    --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml

# Verify npm package
slsa-verifier verify-npm-package @myorg/package \
    --package-version 1.0.0 \
    --source-uri github.com/myorg/package

# Verify container image
slsa-verifier verify-image ghcr.io/myorg/image@sha256:abc... \
    --source-uri github.com/myorg/repo

# Print provenance details
slsa-verifier verify-artifact artifact.tar.gz \
    --provenance-path provenance.jsonl \
    --source-uri github.com/myorg/repo \
    --print-provenance

Sigstore cosign:

For container image verification with SLSA provenance.

# Verify SLSA provenance attestation
cosign verify-attestation \
    --type slsaprovenance \
    --certificate-identity-regexp 'https://github.com/slsa-framework/slsa-github-generator/' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    ghcr.io/myorg/myapp:v1.0.0

# Download and inspect provenance
cosign download attestation ghcr.io/myorg/myapp:v1.0.0 | jq '.payload' | base64 -d | jq '.'

Kubernetes Admission Control:

# Kyverno: Require SLSA L2+
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-slsa-provenance
spec:
  validationFailureAction: Enforce
  rules:

    - name: verify-slsa

      match:
        resources:
          kinds:

            - Pod

      verifyImages:

        - imageReferences:
            - "ghcr.io/myorg/*"

          attestations:

            - type: https://slsa.dev/provenance/v1

              conditions:

                - all:
                    - key: "{{ runDetails.builder.id }}"

                      operator: Equals
                      value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"

Adoption Roadmap¶

A practical path to SLSA adoption.

Phase 1: Assessment (Week 1-2)

## SLSA Readiness Assessment

### Current State

- [ ] Inventory build systems
- [ ] Identify artifact types (containers, packages, binaries)
- [ ] Document current provenance (if any)
- [ ] List target ecosystems (npm, PyPI, containers)

### Gap Analysis

- [ ] Which artifacts have no provenance? (Target L1)
- [ ] Which use hosted CI but no signing? (Target L2)
- [ ] Which are security-critical? (Target L3)

Phase 2: L1 Implementation (Week 3-4)

## L1 Implementation

### Actions

- [ ] Add provenance generation to all build pipelines
- [ ] Use SLSA provenance schema
- [ ] Store provenance alongside artifacts
- [ ] Document provenance location

### Validation

- [ ] Provenance exists for all artifacts
- [ ] Provenance follows SLSA format
- [ ] Provenance is discoverable

Phase 3: L2 Implementation (Week 5-8)

## L2 Implementation

### Actions

- [ ] Migrate to hosted CI (if not already)
- [ ] Implement SLSA generators or native provenance
- [ ] Enable provenance signing (Sigstore/OIDC)
- [ ] Publish provenance to transparency log

### Validation

- [ ] All provenance is signed
- [ ] Builder identity is verifiable
- [ ] slsa-verifier succeeds

Phase 4: L3 Implementation (Week 9-12)

## L3 Implementation

### Actions

- [ ] Use L3-capable generators/builders
- [ ] Ensure build isolation
- [ ] Verify ephemeral environments
- [ ] Confirm non-falsifiable provenance

### Validation

- [ ] Provenance generated by hardened platform
- [ ] Build isolation verified
- [ ] Independent verification succeeds

Phase 5: Operationalization (Ongoing)

## Operational Excellence

### Monitoring

- [ ] Alert on provenance generation failures
- [ ] Track SLSA level per artifact
- [ ] Monitor verification success rates

### Governance

- [ ] Define SLSA requirements per artifact type
- [ ] Include in vendor requirements
- [ ] Document exceptions and remediation plans

Recommendations¶

For Developers:

Start with L1 today. Generate provenance for every build. Even unsigned provenance is better than none. Use SLSA generators to automate.
Target L2 as baseline. With GitHub Actions or similar platforms, L2 is achievable with minimal configuration. Make it the default.
Verify your own artifacts. Run slsa-verifier on your releases. Catch provenance issues before users do.

For Security Practitioners:

Use SLSA in risk assessment. Classify software by SLSA level. Require higher levels for critical components.
Implement verification in deployment. Use admission controllers to require SLSA provenance. Make verification automatic.
Include SLSA in vendor requirements. Add SLSA level requirements to procurement. Use it as common language with suppliers.

For Organizations:

Set SLSA targets by artifact type. Internal tools might be L1. Production services should be L2+. Security-critical infrastructure should be L3.
Invest in tooling. Deploy verification tools. Train teams on provenance generation. Make SLSA part of the CI/CD platform.
Communicate SLSA levels. Publish your SLSA levels. Let consumers know what they can verify. Build trust through transparency.

SLSA transforms supply chain security from vague assurances to verifiable properties. It won't prevent all attacks, but it makes attacks harder, tampering detectable, and trust measurable. As adoption grows across ecosystems, SLSA provenance will become as fundamental as code signing—table stakes for professional software delivery.

SLSA and the OSPS Baseline:

The OpenSSF OSPS Baseline incorporates SLSA concepts within its Build and Release (BR) category. OSPS-BR-06 requires signed releases with cryptographic hashes—directly aligned with SLSA requirements. Organizations implementing SLSA are simultaneously addressing Baseline requirements, and the Baseline's framework mappings show how SLSA compliance contributes to broader regulatory requirements including the EU Cyber Resilience Act and NIST SSDF.

OpenSSF, "SLSA: Supply-chain Levels for Software Artifacts," https://slsa.dev/ ↩
SLSA Framework, "slsa-verifier," https://github.com/slsa-framework/slsa-verifier ↩
The Hacker News, "Mini Shai-Hulud Worm Compromises TanStack, UiPath, Mistral AI npm and PyPI Packages," May 2026, https://thehackernews.com/2026/05/mini-shai-hulud-worm-compromises.html ↩