# actions/attest-build-provenance: signed SLSA provenance for workflow artifacts > This GitHub Action turns a workflow artifact into a signed SLSA build provenance attestation uploaded to GitHub. Since version 4 it is only a wrapper around actions/attest, and plan limits decide where the signatures can live. **actions/attest-build-provenance** — Action for generating build provenance attestations for workflow artifacts - Repository: https://github.com/actions/attest-build-provenance - Stars: 1,073 · Forks: 870 - Language: Unknown - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/actions-attest-build-provenance ## Binding a workflow artifact to a signed provenance record The problem this project addresses is narrow and concrete. A team that publishes a build output from GitHub Actions hands downstream users a file. Downstream users have no built-in way to tell whether that file really came from the pipeline they think produced it. This Action answers that by generating a build provenance attestation: a record that binds some subject, meaning a named artifact together with its digest, to a SLSA build provenance predicate, using the in-toto format. The subject side of that binding is what makes the record useful. A digest is a fixed fingerprint of the bytes, so the attestation talks about one exact artifact rather than about a name that could be reused or replaced. The predicate side carries the build metadata. Together they form a statement that a reviewer can check instead of a promise. A verifiable signature is then generated for the attestation using a short-lived Sigstore-issued signing certificate. Once the attestation has been created and signed, it is uploaded to the GitHub attestations API and associated with the repository from which the workflow was initiated. That last detail matters for anyone auditing a release: the record is tied to a specific repository, not to a free floating file on a web page. ## The in-toto envelope wrapped around a SLSA predicate The format choice is deliberate and worth understanding before you rely on the output. The attestation follows the in-toto attestation format, and the predicate it carries is a SLSA build provenance predicate. In other words, the signature does not cover an ad hoc JSON blob invented by this Action. It covers a statement written in a specification that other tooling can parse, which is the difference between an artifact you can check and a blob you can only trust. The two halves of the statement carry different jobs. The subject identifies what is being talked about, a named artifact plus its digest. The predicate carries the build provenance, the part that describes how and where the thing was built. The in-toto structure keeps them in one signed unit, so a verifier cannot swap the subject while keeping a valid signature over the old predicate. The project's repository layout stays small. Top level entries include a README, a LICENSE, a RELEASE.md, an action.yml, and a .github directory. There is no separate service, no agent, and no database in this repository. The heavy lifting is done by the @actions/attest package, and the trust infrastructure is Sigstore. That is a small enough surface that you can read the whole project and understand what it depends on, but it also means the interesting behaviour lives in dependencies and in GitHub's hosted APIs rather than in this codebase. ## Public-good Sigstore for public repositories, private instances for private ones Signature keys are the part of any supply chain setup that tends to be hand waved, so it is worth being explicit about what this Action does. It does not use a long lived key that lives in your repository secrets forever. It uses a short-lived Sigstore-issued signing certificate, and the signature produced with that certificate is verifiable. Which Sigstore instance issues the certificate depends on repository visibility. If the repository initiating the GitHub Actions workflow is public, the public-good instance of Sigstore is used to generate the attestation signature. If the repository is private or internal, the GitHub private Sigstore instance is used instead. The same Action therefore produces the same kind of artifact in both cases, but the trust infrastructure behind the certificate differs, and that is a distinction you should confirm against your own policy before telling a customer to verify a signature. Verification is not performed by this repository. Attestations can be verified using the attestation command in the GitHub CLI, and GitHub also publishes a guide on using artifact attestations to establish provenance for builds. The practical consequence is that consuming teams need the GitHub CLI in their verification path, and if your organisation standardises on a different verifier, you should check the compatibility before adopting the action. ## Version 4 reduced the action to a wrapper on actions/attest The most important practical fact about this repository is that it has stopped being the place to look for the real implementation. As of version 4, actions/attest-build-provenance is simply a wrapper on top of actions/attest. The underlying work is done by the @actions/attest package, and the project points new implementations at the actions/attest repository for usage information. Existing applications may continue to use the attest-build-provenance action. That sentence is the project's own compatibility statement, and it defines the audience for this wrapper. Teams with a working pipeline and a signed-attestation requirement can leave the existing step in place, while new work should be built on actions/attest. The alternative is therefore not a competitor product but a sibling action, and the difference in approach is one of scope: actions/attest is the general attestation action, while this repository narrows the output to build provenance. For anyone still on an older line, the project keeps documentation for previous versions in the README of the v3.2.0 tag. Release history shows the v4 line moving from v4.1.0 on 2026-02-26 through v4.1.1 on 2026-06-26 to v4.2.2 on 2026-08-06, and the last push to the repository was on 2026-08-21. Version 4 is not an experiment that was abandoned after a release. ## Wiring the step in and checking the result from the command line This repository publishes no installation instructions of its own, because it is a GitHub Action consumed inside a workflow rather than a package you install locally, and because version 4 defers usage documentation to the actions/attest repository. There is consequently no install command to copy. Take the usage details from the actions/attest repository, keep the action step in the workflow that produces the artifacts, and make sure the artifacts you want attested are the ones the step receives. Verification happens on the consumer side, through the GitHub CLI. The project points at the attestation command in the GitHub CLI for this, and the manual page for it is the reference for the exact arguments: A real check also needs the subject digest and the repository. The GitHub CLI manual page linked from the project is the authoritative list of arguments and flags. What you should see when verification succeeds is the GitHub attestations API returning the stored attestation for the digest you passed, with a signature that chains back to the Sigstore instance that issued the certificate for your repository type. If a verification fails, the usual suspects are a digest that does not match the bytes you hold, or a repository and plan combination where the attestation was never stored in the first place. Checking the digest first is faster than re-running the workflow. ## Plan and repository visibility decide whether attestations land at all The clearest limitation is commercial and is stated in the project documentation rather than discovered in production. Artifact attestations are available in public repositories for all current GitHub plans. They are not available on legacy plans, such as Bronze, Silver, or Gold. If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, artifact attestations are available only for public repositories. To use artifact attestations in private or internal repositories, you must be on a GitHub Enterprise Cloud plan. That is a hard boundary, not a soft recommendation. Check the GitHub plan and repository visibility before enabling the workflow. Test attestation creation and verification in your own environment, and treat a missing or failed attestation as a failure of the provenance check rather than assuming that a successful build proves one exists. A second limitation is what the documentation leaves out. The repository does not document custom predicate contents, per-attestation retention, key management options, a rollback path, or a policy engine for enforcing verification on the consumer side. The action.yml file is present at the top level, but the usage details are delegated elsewhere. If your requirement needs any of those, the gap is in what is written down, so raise it with the project or plan around it. ## What a team gets and what it still has to build It helps to be blunt about the value proposition. You get a signed statement, in a standard format, attached to a digest, stored by GitHub and tied to your repository, without running a key management service or an agent. For teams whose buyers are asking where a release binary came from, that removes a large amount of custom infrastructure work. What you do not get is a complete provenance system. Verification policy remains a consumer decision, so the receiving side still has to decide when to fail a download. Retention is a property of the GitHub attestations API rather than of this Action. Anything beyond the standard SLSA build provenance predicate has to come from the general attestation action, and documentation for that lives in a different repository. The repository itself is modest. There is a LICENSE carrying the MIT identifier, a RELEASE.md for release notes, a CODEOWNERS file, and a .github directory for workflow and configuration files. With the last push on 2026-08-21 and a v4.2.2 release on 2026-08-06, this is a repository that has been touched recently, though the v4 line makes clear that most of the design decisions now sit with actions/attest and Sigstore rather than with this wrapper. ## Conclusion Adopt this action if you publish artifacts from GitHub Actions to consumers who need to prove where a binary came from, and if your repository type and GitHub plan allow attestations at all. Do not adopt it to gain control over signing keys, custom predicate contents, retention windows, or rollback, because none of that is described in the project documentation. If you are starting fresh, follow the pointer to actions/attest, since version 4 of this repository is a wrapper around it. Before wiring anything in, confirm that your repository visibility and plan are covered, then check that the attestation command in the GitHub CLI can reach the uploaded attestation for your artifact digest. ## FAQ ### How do I verify an attestation created by actions/attest-build-provenance? Attestations can be verified using the attestation command in the GitHub CLI. The action uploads the signed attestation to the GitHub attestations API and associates it with the repository from which the workflow was initiated, so the repository and the artifact digest are what the check keys on. ### Can I use actions/attest-build-provenance in a private repository? Only on a GitHub Enterprise Cloud plan. Artifact attestations for private or internal repositories require GitHub Enterprise Cloud, while GitHub Free, Pro and Team plans cover public repositories only. Private and internal repositories also use the GitHub private Sigstore instance rather than the public-good one. ### Should a new workflow use actions/attest-build-provenance or actions/attest? As of version 4, actions/attest-build-provenance is simply a wrapper on top of actions/attest, and the project directs new implementations to actions/attest. Existing applications may continue to use the attest-build-provenance action. ### What licence is actions/attest-build-provenance released under? The repository carries a LICENSE file and the project is identified as MIT licensed. The code is therefore available under the MIT terms, and the Sigstore certificates and the GitHub attestations API remain outside this repository. ### When was actions/attest-build-provenance last updated? The last push to the repository was on 2026-08-21, and the most recent release listed is v4.2.2 from 2026-08-06, preceded by v4.1.1 from 2026-06-26 and v4.1.0 from 2026-02-26. ## Sources - [actions/attest-build-provenance on GitHub](https://github.com/actions/attest-build-provenance) - [Issues](https://github.com/actions/attest-build-provenance/issues) - [License: MIT](https://github.com/actions/attest-build-provenance/blob/main/LICENSE) - [README](https://github.com/actions/attest-build-provenance/blob/main/README.md) - [Releases](https://github.com/actions/attest-build-provenance/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/actions-attest-build-provenance