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?”
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 and lets teams start with what’s tangible without waiting for a complete framework that would never arrive.
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. This turns SLSA into something executable, not just documentary.
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 (Google Cloud Build in certain modes, or GitHub’s ephemeral runners with specific configurations) 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: it certifies how the image was assembled, not how the intermediate dependencies were built. A complete chain requires every link to sign, and that’s where the ecosystem’s uneven adoption shows.
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. Work is underway to allow aggregated provenance, but it isn’t standardized yet.
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. Extending to more artifacts becomes mechanical.
What I wouldn’t recommend is trying to reach L3 across the board, or building a SLSA compliance framework before having a single signed artifact. The usual experience is that the team gets stuck in planning and never gets to execute anything verifiable.
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. Current drafts point in the right direction, but their dependence on forge-internal details means rollout will inevitably be uneven.
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. It’s less ambitious than SLSA’s original vision, but it’s executable today, and that’s worth more than any level that only exists on slides.
