The SLSA GitHub Generator is retired in favour of artifact attestations

The README now opens with a retirement notice

The most important thing in this repository is a note at the top of the README, and it changes how everything else should be read. The project is no longer actively maintained, the team is working on guidance and simpler tooling to replace it, and in the meantime they suggest GitHub artifact attestations, described as a built-in solution for generating SLSA provenance on GitHub. The notice then addresses existing users directly. Provenance that has already been generated remains valid, and the reusable workflows continue to work, but they should not be assumed to receive updates, including for GitHub Actions runtime deprecations. The most recent release is v2.1.0 from February 2025, and the last push to the repository was on 2026-08-07. So this is not an archived project that has been forgotten, it is a maintained-in-the-past component of a framework that is being folded into a first-party GitHub feature, and the honest engineering question is whether your next integration should start here at all.

What SLSA and provenance are meant to give you

The overview section explains the framework in two steps, and the definitions are worth having precisely. SLSA, Supply-chain Levels for Software Artifacts, is a security framework, a checklist of standards and controls to prevent tampering, improve integrity and secure packages and infrastructure. It defines an incrementally adoptable set of levels expressed in terms of increasing compliance and assurance, and the README makes the point that the levels are a common language for talking about how secure software, supply chains and their component parts actually are. Provenance is the metadata layer: information about how a software artifact was created, which could include what source code, build system and build steps were used, as well as who and why the build was initiated, and it is used to determine the authenticity and trustworthiness of the artifacts you use. SLSA defines a provenance format that can hold that metadata, and the entire repository exists to produce it accurately for GitHub-hosted builds.

Two tools, generation and builder creation

The repository contains two things, and they are separable. The first is tooling for generating non-forgeable SLSA provenance on GitHub for your projects, meeting the provenance generation and isolation requirements for SLSA Build Level 3 and above. The second is tooling for building a SLSA builder on GitHub using the Build-Your-Own-Builder framework, with which you can wrap an existing GitHub Action into a SLSA builder that generates non-forgeable provenance meeting the same requirements. The top level of the tree shows how that is laid out in code, with actions/ for the workflow definitions, internal/ for the Go implementation, slsa/ for the SLSA specific pieces, signing/ for the signing side, third_party/ for vendored dependencies, plus a go.mod, a Makefile, e2e/ and github/ directories, and top level documents such as PROVENANCE_FORMAT.md, SPECIFICATIONS.md, BYOB.md and RELEASE.md. The go.mod pins Go 1.23.1 and pulls in the Sigstore stack, cosign v2, rekor and sigstore itself, plus in-toto-golang, so the signing and transparency log side is Sigstore's rather than something bespoke.

The reusable workflows are not the whole of level 3

There is a warning in the documentation that matters more than the feature list, because it is where projects get this wrong. While slsa-github-generator can help you achieve SLSA Build level 3, use of the provided GitHub Actions reusable workflows alone is not sufficient to meet all of the requirements at that level. Specifically, those workflows do not address provenance distribution or provenance verification, both of which are separate requirements in the specification. So the reusable workflows are a starting point rather than the destination, and the missing pieces are the ones that determine whether a consumer outside your build system can check what you produced. The repository ships the slsa-verifier to close the verification side, and the README notes that the same reusable workflows are used by projects in its Hall of Fame, with Flask, flatbuffers and grpc-gateway named in the list of projects generating provenance with the builders here.

The verifier is the part that changes when you migrate

This is the practical trap for anyone following the retirement notice. GitHub artifact attestations are verified with gh attestation verify rather than with slsa-verifier, and the README says so directly, noting that migrating changes how your consumers verify. That is a consumer-facing break, not an internal detail. A downstream system that runs slsa-verifier against an attestation payload will need to change, and a documented verification step in a downstream build or release policy has to be rewritten, not just re-pointed. The repository is organised so that a consumer can see the whole path, with a verification section covering installation, inputs and command line examples, and the Makefile shows how the project itself is built and tested, with go-test vendoring the modules and running the Go test suite and ts-test running the TypeScript tests for the actions where tests are found, plus a unit-test target that runs both.

The two ways to get provenance, and the choice between them

Two paths exist, and the difference is who hosts the signing infrastructure and who verifies the result. With the generator, the project provides the builders, the reusable workflows and the verifier, and the provenance is produced as part of your GitHub Actions build with the isolation properties SLSA requires. With GitHub artifact attestations, the functionality is built into GitHub itself, so there is no separate project to vendor, no builder framework to learn and no third-party verifier to keep in step with. The trade-off is control. The generator route lets you shape the builder and the format, and the BYOB framework exists precisely so you can wrap an existing action rather than accept the supplied one. The attestation route removes that freedom and replaces it with a smaller surface. For a team starting today, the README's own recommendation settles the question in favour of attestations. For a team with a large existing deployment, the migration is mostly a verification change, and the presence of the verifier in this repository is what makes that change possible rather than a rewrite.

Editorial conclusion

Adopt GitHub artifact attestations for any new work, because the SLSA GitHub Generator's own README says the project is no longer actively maintained and names attestations as the built-in replacement. Keep the generator only if you already depend on the provenance it produced, since the documentation states that provenance already generated remains valid and the reusable workflows continue to work, but they should not be assumed to receive updates, including for GitHub Actions runtime deprecations. Before you migrate, plan the verification change, because attestations are checked with gh attestation verify rather than slsa-verifier, and that changes how your consumers verify.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. slsa-framework/slsa-github-generator on GitHub