SLSA v1.0: Supply-chain Levels for Software Artifacts Reaches Maturity

In April 2023, the SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") framework reached version 1.0. This was a significant milestone — SLSA went from a draft proposal by Google to a mature, industry-backed framework with a clear specification, practical tooling, and growing adoption.

SLSA v1.0 also brought substantial changes from the earlier v0.1 draft, simplifying the level definitions and making the framework significantly more practical to adopt incrementally.

What SLSA Is

SLSA is a security framework that addresses the integrity of software artifacts throughout the supply chain. It answers the question: "Can I trust that this artifact is what it claims to be and hasn't been tampered with?"

SLSA focuses specifically on build integrity — ensuring that the software artifact you're deploying was actually built from the source code you think, using the build process you expect, without unauthorized modifications.

What Changed in v1.0

Simplified Levels

SLSA v0.1 had four levels. V1.0 simplifies to three:

SLSA Build Level 1 (Provenance)

• The build process produces provenance — a record of how the artifact was built
• Provenance includes: what was built, from what source, using what build process
• The provenance is available to consumers
• This is the entry point — it requires generating provenance, but doesn't require specific build system properties

SLSA Build Level 2 (Hosted Build)

• Everything in Level 1, plus:
• The build runs on a hosted build platform (not a developer's laptop)
• The provenance is signed by the build platform
• The provenance is generated by the build platform, not by a user-controlled process

SLSA Build Level 3 (Hardened Build)

• Everything in Level 2, plus:
• The build platform provides strong isolation between builds
• The provenance cannot be falsified by build platform users
• The build platform is audited and hardened

Separate Tracks

V1.0 introduces the concept of separate tracks. Build integrity (the current focus) is one track. Future tracks may cover source code integrity, dependency integrity, and other aspects of the supply chain. This allows the framework to grow without overloading a single set of levels.

Clearer Threat Model

V1.0 explicitly defines the threats each level protects against:

• Level 1: Mistakes and documentation gaps (provenance exists but isn't verified)
• Level 2: Tampering after build (provenance is signed, so modifications to the artifact are detectable)
• Level 3: Tampering during build (the build environment itself is hardened against manipulation)

Practical Implementation

Achieving Level 1

Level 1 is achievable immediately:

1. Choose a provenance format: SLSA recommends in-toto attestations
2. Generate provenance during your build: Record the source repository, commit, build configuration, and output artifacts
3. Make provenance available: Publish provenance alongside your artifacts

For GitHub Actions, the slsa-framework/slsa-github-generator provides automated provenance generation:

# In your GitHub Actions workflow
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.5.0
  with:
    base64-subjects: "${{ needs.build.outputs.digests }}"

Achieving Level 2

Level 2 requires a hosted build platform:

• GitHub Actions: Provides Level 2 (and Level 3 for GitHub-hosted runners) provenance through the SLSA GitHub generator
• Google Cloud Build: Natively supports SLSA Level 2+ provenance
• Other platforms: Can achieve Level 2 by implementing the SLSA provenance specification and signing provenance with the platform's identity

Achieving Level 3

Level 3 requires hardened build isolation:

• GitHub Actions with GitHub-hosted runners: Meets Level 3 requirements because GitHub-hosted runners provide ephemeral, isolated build environments
• Self-hosted runners: Generally do not meet Level 3 because they may not provide sufficient isolation between builds
• Google Cloud Build: Meets Level 3 through containerized, isolated build environments

Verification

Generating provenance is half the story. Verification is the other half.

SLSA Verifier

The slsa-framework/slsa-verifier tool verifies SLSA provenance:

slsa-verifier verify-artifact myapp-v1.0.0.tar.gz \
  --provenance-path myapp-v1.0.0.intoto.jsonl \
  --source-uri github.com/myorg/myapp \
  --source-tag v1.0.0

Policy Enforcement

In Kubernetes environments, admission controllers can verify SLSA provenance before allowing deployments:

• Kyverno: Supports SLSA provenance verification policies
• Sigstore Policy Controller: Verifies signatures and attestations on container images
• OPA/Gatekeeper: Can be extended with custom policies for provenance verification

Adoption Status in 2023

By mid-2023, SLSA adoption was growing:

• npm: Began supporting provenance attestations for packages published from GitHub Actions
• Go: The Go ecosystem was exploring SLSA provenance for modules
• Python: PyPI's Trusted Publishers feature aligned with SLSA principles
• Container registries: Major registries supported storing attestations alongside images

Common Questions

Does SLSA prevent supply chain attacks?

SLSA doesn't prevent all supply chain attacks. It prevents and detects specific categories:

• Prevents: Unauthorized modifications to build artifacts, impersonation of build systems
• Detects: Discrepancies between claimed source and actual build inputs
• Doesn't address: Source code compromise, dependency compromise (future tracks), social engineering

Is SLSA compatible with Sigstore?

Yes. Sigstore and SLSA are complementary:

• SLSA defines what provenance should contain and what security properties the build system should have
• Sigstore provides the tooling (Cosign, Fulcio, Rekor) for signing and verifying provenance
• In practice, most SLSA implementations use Sigstore for signing

How does SLSA relate to SBOMs?

SBOMs and SLSA are complementary:

• SBOM answers: "What components are in this software?"
• SLSA answers: "Was this software built correctly from its intended source?"
• Together, they provide comprehensive supply chain transparency

How Safeguard.sh Helps

Safeguard.sh integrates SLSA into your supply chain security practice:

• Provenance Generation: Safeguard.sh generates SLSA-compliant provenance attestations as part of your build process.
• Provenance Verification: Safeguard.sh verifies SLSA provenance for artifacts before they're deployed, ensuring only properly built software reaches production.
• Level Assessment: Safeguard.sh evaluates your build processes against SLSA requirements and identifies gaps, providing a roadmap for increasing your SLSA level.
• Integration with SBOMs: Safeguard.sh combines SLSA provenance with SBOM data, providing comprehensive supply chain transparency from source to deployment.

SLSA v1.0 takes supply chain security from aspiration to practice. The framework is clear, the tooling is available, and the industry is moving toward making provenance a standard expectation. Starting with Level 1 is straightforward, and the incremental path to higher levels is well-defined.