Free tools Windows power users keep installed
One-click scans. No signup required.
GitHub artifact attestations provide signed provenance linking a software artifact to details about how it was built. To use them effectively, producers must attest the release files they distribute, and consumers must verify the attestation and decide whether its source, workflow, commit, and build environment meet their trust requirements. A successful verification is evidence of provenance—not proof that the artifact is safe.
What a GitHub artifact attestation tells you
An artifact attestation is a cryptographically signed statement that connects an artifact to build provenance. GitHub says provenance claims can identify the associated workflow, repository, organization, environment, commit SHA, triggering event, and information from the OIDC token. See GitHub’s artifact attestations documentation.
That information helps a consumer ask whether a release came from the expected source and build process. It does not establish that the source code, dependencies, build scripts, or workflow are benign. GitHub cautions that attestations are not a guarantee that an artifact is secure; meaningful security depends on verifying the signature and signer identity, then assessing the provenance against your own policy.
How GitHub signs attestations
GitHub’s implementation uses Sigstore, but the transparency-log behavior depends on repository visibility:
| Repository | Signing and transparency behavior |
|---|---|
| Public | Uses the Sigstore Public Good Instance. GitHub stores a copy of the generated bundle, and the attestation is written to a publicly readable, immutable transparency log. |
| Private | Uses GitHub’s Sigstore instance, which has no transparency log and federates only with GitHub Actions. |
These differences affect where verification evidence comes from; they do not replace checking the identity and workflow represented in the provenance.
Create attestations for release artifacts
Generate attestations for the software you expect other people to verify, such as release binaries, packages, or manifests containing their hashes. GitHub advises against attesting frequent automated test builds or individual source, documentation, and embedded image files. Its documentation explains the supported workflow.
A producer’s job is to build the release and publish provenance for the distributed artifact. Attestation creation alone does not deliver the intended security benefit: consumers still need to verify and assess it.
Verify an attestation and assess its provenance
Consumers can use GitHub CLI to verify an artifact’s attestation and inspect its provenance. Verification checks cryptographic evidence and signer identity; the next step is to determine whether that identity and build process are acceptable for your use case.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Confirm the source repository and commit are expected.
- Check that the signer workflow is the intended workflow, including its repository when a reusable workflow is involved.
- Assess whether the build environment and triggering event match your release policy.
- Review the provenance as evidence, not as an automatic safety rating.
For stronger constraints, GitHub’s reusable-workflow guidance describes using --owner or --repo with gh attestation verify. These options identify where to fetch the attestation and identify the caller workflow. If the signing workflow is reusable and hosted in another repository, --signer-repo can constrain that repository, while --signer-workflow can require a particular workflow file. Consult GitHub’s reusable-workflow guide for the current command details.
Retrieve attestations through the REST API
The GitHub REST API can retrieve attestations associated with subject digests. Results are permission-filtered, and a fine-grained token may need the attestations:read permission, depending on the endpoint. Retrieval is not verification: the REST API documentation says signature and timestamp verification and signer-identity validation are required for meaningful security. Treat an API response as material to verify, not as proof by itself.
Rank #4
Choose online or offline verification
Online verification with GitHub CLI can retrieve attestations. Offline verification is possible when you transfer the necessary evidence into the isolated environment, but it adds a trusted-root freshness responsibility.
| Approach | What you need | Trade-off |
|---|---|---|
| Online | GitHub CLI and access to retrieve the attestation. | The verifier can retrieve evidence as part of the process. |
| Offline | The artifact, downloaded attestation bundle, trusted-root file, and GitHub CLI in the offline environment. | Trusted roots must be refreshed as new signed material is imported. A verifier using an older root file may not know that key material was revoked later. |
GitHub’s documented offline sequence is to download a bundle with gh attestation download, obtain trusted roots with gh attestation trusted-root, and run gh attestation verify against the local artifact with --bundle and --custom-trusted-root. Follow the current GitHub offline verification instructions, including its guidance on keeping trusted roots current.
Best Value
What assurance level do attestations provide?
GitHub characterizes artifact attestations by themselves as SLSA v1.0 Build Level 2. Its documentation presents reusable workflows with vetted build instructions and workflow isolation as a route to Build Level 3. This describes GitHub’s documented implementation, not a guarantee that every project using attestations achieves a particular security outcome. See GitHub’s explanation of attestation security and its reusable-workflow guidance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
