SLSA v1.0: a mature framework for the software supply chain

Actualizado: 2026-05-03

When Google published the first version of SLSA in 2021, software supply-chain security was still a relatively marginal topic. SolarWinds had just turned concern into urgency, but tooling was scarce and standards were in draft form. Four years later, the landscape is very different: SLSA v1.0 has been out for a year and a half, the Sigstore ecosystem has matured, major forges ship attestation generation with a couple of lines of config, and European regulation is starting to cite all of this by name in drafts like the Cyber Resilience Act.

It’s a good moment to take stock. This review isn’t meant to be exhaustive; it’s meant to answer the question I keep getting these months: “We want to start with SLSA — where?”

Key takeaways

• SLSA v1.0 separated the original ladder into tracks: Build, Source, Dependencies. Only Build is stabilised.
• The Build track has three levels: L1 (basic provenance), L2 (signed by hosted build service), L3 (strong isolation between builds).
• If your build lives in GitHub Actions, the path to L2 is a few hours of work.
• The Sigstore ecosystem has been the great unlock: ephemeral OIDC-based signatures, no long-lived key management.
• My recommendation: pick a single important artifact, get it to L2, and learn the vocabulary before scaling.

What changed in v1.0

The initial version of SLSA mixed source, build and dependency requirements into a single four-level ladder. It was conceptually elegant but hard to apply: a team could have an impeccable build and mediocre dependency hygiene, and the framework didn’t know what to do with them.

v1.0 separated concerns into tracks. Today the Build track is the only stabilized one, with three levels:

• L1 requires the build to be automated and a basic provenance statement to exist.
• L2 adds that the provenance be signed and published by a hosted build service.
• L3 demands strong isolation between builds and that signing keys not be accessible from the code being built.

The source and dependency tracks are still being drafted. This is healthy: it admits that the problem is too big for a single model.

What works well

If your build lives in GitHub Actions, the path to L2 is surprisingly short. The official provenance-generating action produces a Sigstore-signed attestation, and the runner provider signs as a verifiable identity. In projects using GoReleaser, the integration with cosign and attestation upload to the registry have been in the default config for several versions.

The Sigstore ecosystem in general has been the great unlock. Three years ago, signing binaries meant managing keys, HSMs and procedures few teams could afford. Today an OIDC identity is enough to emit a short-lived signature and register it in a public transparency log. The mental-model shift — ephemeral signatures instead of long-lived keys — has let the practice spread without friction.

Verification has also improved. Both cosign verify-attestation and admission policies in Kubernetes with Kyverno or Gatekeeper let you require that an image has provenance signed by a specific workflow before admitting it to the cluster.

What still hurts

The L3 level is another story. It demands effective isolation between builds, which means either using a provider that already guarantees it or building your own non-trivial infrastructure. For most small teams, going from L2 to L3 isn’t worth it compared to other security priorities.

Multi-stage builds with intermediate containers are another headache. If your Docker build uses layers built outside the SLSA-tracked flow, your final provenance is technically correct but incomplete.

Another delicate point is large monorepos with multiple artifacts. Provenance is emitted per artifact, but if 30 services share the same pipeline, the cost of generating and signing 30 attestations per push isn’t negligible.

Where to start without frustration

If you haven’t touched SLSA yet, my recommendation is concrete. Pick a single important artifact — the one whose compromise would worry you most:

• The product binary.
• The base image everyone inherits from.
• The internal library used across services.

Reaching L1 for that single artifact is a two-hour job if you already build in CI. Reaching L2 adds maybe another hour to enable signing and configure the attestation registry.

With that single case done, you’ll have learned the vocabulary — provenance, attestation, transparency log, admission verification — and have an internal example to copy.

Looking ahead

The next frontier, the source track, is the one that would have the most real impact. Guaranteeing that the code entering the build actually comes from the repository it claims to, and that it went through the declared reviews, would cover the attack vector SolarWinds opened.

Meanwhile, L2 build provenance generalized already changes the game. It turns the question “can I trust this binary?” into “does its provenance match what I expected?”, and that’s something an automated policy can actually answer.

Conclusion

SLSA v1.0 is the right starting point for teams wanting to demonstrate integrity in their software supply chain. Incremental adoption — one artifact, L2, learn the vocabulary, scale — is the path that works. The Sigstore ecosystem has removed the key management barrier that made binary signing inaccessible to most teams. The question is no longer “should we do this?” but “which artifact do we start with?”.