A GitHub artifact attestation is a cryptographically signed claim about how and where a piece of software was built. It lets a consumer verify provenance and integrity. It does not prove the artifact is secure, and GitHub says so plainly.
What an attestation contains
Each attestation can include a link to the workflow, the repository, organization, environment, commit SHA and triggering event, plus other data from the OIDC token. You can also attach a software bill of materials listing the open source dependencies used in the build. GitHub uses Sigstore to sign attestations.
Public and private repositories
| Repository type | Signing setup |
|---|---|
| Public | Sigstore Public Good Instance, bundle stored with GitHub and written to a public, immutable transparency log |
| Private | GitHub's own Sigstore instance, with no transparency log, federating only with GitHub Actions |
On plan availability, the features page says artifact attestations on Free, Pro and Team plans are for public repositories, with private or internal repositories requiring GitHub Enterprise Cloud.
SLSA level
The documentation says attestations alone provide SLSA v1.0 Build Level 2. To reach Build Level 3, run builds in a reusable workflow shared across your organization, which isolates the build from the calling workflow. Treat the level as a description of build integrity, not a rating of your whole product.
How to verify
Consumers can check an artifact with the GitHub CLI command gh attestation verify. The verified details let you write and enforce your own policies, for example "only deploy images built by this workflow from the main branch."
What attestations prove
They link an artifact to its source code and the build instructions that produced it. If someone swaps a binary after the build, verification fails. That is real value against tampering between build and deploy.
What they do not prove
- That the code is free of vulnerabilities.
- That the dependencies are safe.
- That the build workflow itself was not written maliciously.
GitHub states that attestations are not a guarantee that an artifact is secure, and that you must define criteria and make your own risk decisions.
What to sign
The documentation advises signing release software that people will run or download, such as binaries, packages and manifests with content hashes. It advises against signing frequent test builds or individual files such as source code or documentation.
A starter policy
- Generate attestations for release builds only.
- Verify at deploy time, not just at download.
- Pair provenance with vulnerability scanning of the same artifact.
- Record verification results as evidence.
Where a dedicated scanner fits
Provenance says where software came from. Scanning says what is in it. Safeguard offers SBOM and dependency scanning and compliance and evidence automation, plus a free scan at gold.safeguard.sh/scan.
Quick check
Does an attestation mean the software is safe to run?
No. It shows where and how it was built. Safety needs separate scanning and review.
What command verifies an attestation?
The GitHub CLI command gh attestation verify.
Sources
Last reviewed: 19 October 2026.
