SLSA v1.0: Software Provenance Attestation Goes Mainstream

In April 2023, the Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") framework reached version 1.0—a milestone that transformed it from an aspirational specification into a practical, adoptable standard. Originally developed by Google and now maintained under the Open Source Security Foundation, SLSA provides a framework for ensuring the integrity of software artifacts from source to deployment.

What SLSA Solves

SLSA addresses a specific class of supply chain attacks: those that tamper with software between the time a developer writes code and the time a user runs it. This includes:

Source tampering: An attacker modifies source code without the developer's knowledge (compromised version control, unauthorized commits).

Build tampering: An attacker compromises the build system to inject malicious code during compilation or packaging (the SolarWinds attack model).

Artifact tampering: An attacker modifies the built artifact after it's produced but before it reaches the user (compromised distribution channel, registry manipulation).

Dependency tampering: An attacker introduces malicious dependencies that are pulled in during the build process (dependency confusion, typosquatting).

SLSA provides provenance attestations—cryptographically signed metadata about how an artifact was built—that allow consumers to verify the integrity of the software they're using.

The SLSA v1.0 Levels

SLSA v1.0 simplified the framework from the previous four-level model to three build levels, plus a set of source requirements:

Build Level 1: Provenance Exists

The build process produces provenance metadata describing what was built, how, and where. The provenance is available but not necessarily signed or verified.

This is the entry point. It's easy to achieve—most CI/CD systems can generate build metadata—and provides basic traceability.

Build Level 2: Hosted Build Platform

The build runs on a hosted platform that generates and signs provenance. The provenance is authenticated (you can verify it came from the claimed build platform) but the build platform's security isn't fully verified.

This level requires using a CI/CD service that supports SLSA provenance generation. GitHub Actions has native SLSA support through the slsa-github-generator project.

Build Level 3: Hardened Builds

The build platform provides strong guarantees about build isolation, provenance integrity, and resistance to compromise. The build runs in an ephemeral, isolated environment, and the provenance cannot be falsified by the build service's users.

This is the highest current level and requires build infrastructure specifically designed for SLSA compliance.

Real-World Adoption in 2023

SLSA v1.0's release catalyzed adoption across the ecosystem:

npm provenance. In April 2023, npm launched provenance support, allowing packages published from GitHub Actions to include SLSA provenance attestations. The provenance links a package to its source repository and build workflow, letting users verify that a package was built from the code it claims.

By October, over 5,000 npm packages had published with provenance, including popular packages like express, lodash, and webpack.

PyPI attestations. PyPI began work on provenance support, building on the Trusted Publishers feature to provide verifiable links between packages and their source repositories.

Sigstore integration. SLSA leverages Sigstore for signing provenance attestations. Sigstore's keyless signing model eliminates the key management burden that previously made artifact signing impractical for most projects. With Sigstore, developers can sign artifacts using their OIDC identity (e.g., their GitHub account) without managing long-lived signing keys.

GitHub Actions native support. GitHub deepened its SLSA integration, making it straightforward to generate SLSA Build Level 3 provenance for artifacts built in GitHub Actions. The slsa-github-generator project provides reusable workflows for common build scenarios.

Understanding Provenance

A SLSA provenance attestation is a JSON document (in the in-toto attestation format) that contains:

{
  "buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
  "builder": {
    "id": "https://github.com/slsa-framework/slsa-github-generator/..."
  },
  "invocation": {
    "configSource": {
      "uri": "git+https://github.com/example/repo@refs/tags/v1.0.0",
      "digest": {"sha1": "abc123..."},
      "entryPoint": ".github/workflows/release.yml"
    }
  },
  "materials": [
    {"uri": "git+https://github.com/example/repo", "digest": {"sha1": "abc123..."}}
  ]
}

This tells you:

• Which source repository the artifact came from
• Which commit was built
• Which build workflow was used
• Which build service performed the build

Armed with this information, a consumer can verify that a package was built from the expected source, by the expected process, and hasn't been tampered with.

Practical Adoption Guide

For package publishers:

1. Publish from CI/CD, not developer machines. This is prerequisite for build provenance.
2. Use GitHub Actions with the SLSA generator for Build Level 3.
3. Enable npm provenance or equivalent for your package registry.
4. Document your build process so consumers can verify provenance meaningfully.

For package consumers:

1. Verify provenance when available. npm audit signatures checks provenance for installed packages.
2. Prefer packages with provenance. When choosing between equivalent packages, favor those with verified provenance.
3. Include provenance status in your dependency evaluation criteria.
4. Build tooling to check provenance at scale across your dependency graph.

Limitations

SLSA provenance is powerful but not a complete solution:

It doesn't prevent malicious maintainers. If a legitimate maintainer publishes malicious code through the proper build process, provenance will verify that it came from the right source—because it did.

Source integrity is separate. SLSA's build levels focus on build integrity. Source integrity (ensuring the code hasn't been tampered with in version control) is addressed separately and less maturely.

Adoption is uneven. Not all registries, build systems, or projects support SLSA yet. The ecosystem is growing but far from universal.

How Safeguard.sh Helps

Safeguard.sh integrates SLSA provenance verification into its supply chain analysis, automatically checking provenance attestations for dependencies that support them and flagging components without provenance. Our platform tracks provenance coverage across your dependency graph, helps you prioritize adoption for your own packages, and provides a clear view of which parts of your supply chain have verified integrity and which don't. As SLSA adoption grows, Safeguard.sh ensures you're taking full advantage of the integrity guarantees it provides.