An artifact attestation is a cryptographically signed statement about how a build was produced: which workflow, repository, commit and trigger created it. It helps small teams that ship software others consume, but only if someone actually verifies the attestation. Generating it without verifying it adds little.
What GitHub says it contains
GitHub's documentation describes attestations as signed claims that establish build provenance. They include a link to the workflow associated with the artifact, the repository, organization, environment, commit SHA and triggering event, and other information from the OIDC token used to establish provenance. You can also create attestations that include an associated software bill of materials.
GitHub generates them using Sigstore, an open source project for signing and verifying software artifacts. Public repositories use the Sigstore Public Good Instance, with the bundle also written to a public transparency log. Private repositories use GitHub's own Sigstore instance, which the docs say has no transparency log and federates only with GitHub Actions.
What problem it solves
Without provenance, a consumer sees a binary or image and has to trust the publisher's word. With a verified attestation, they can check that it came from a specific workflow in a specific repository at a specific commit. That makes a swapped artifact, built from somewhere else, easier to catch.
The docs state a limit clearly: generating attestations alone does not provide a security benefit; they must be verified for the benefit to be realized.
Who needs it
| Your situation | Worth doing now? |
|---|---|
| You publish a library, CLI or container image others install | Yes, it gives consumers something to verify |
| You ship an internal service deployed only by you | Maybe later, once your deploy step can verify it |
| You are still pinning actions and scoping tokens | Do those first |
How a small team can start
- Fix the basics first: restricted token permissions, pinned actions, protected branches. Provenance from a loose pipeline proves little.
- Add the attestation step to the release workflow only, using the platform's documented action and the permissions it asks for.
- Add a verification step where you deploy or consume the artifact. Follow the platform's current documentation for the verification command.
- Write down what a failed verification means and who decides. A check nobody acts on is theatre.
- Optionally attach an SBOM to the attestation so consumers can see the dependencies.
What attestations do not tell you
A valid attestation says where the artifact was built. It does not say the code is free of vulnerabilities, or that the dependencies were safe. A malicious dependency built in a perfectly attested pipeline still produces a perfectly attested malicious artifact.
GitHub's docs say attestations alone provide SLSA v1.0 Build Level 2, and that using a reusable workflow for the build can help reach Build Level 3. Treat those labels as descriptions of the guarantee, not certification of your company.
Pair it with dependency visibility
Provenance covers how it was built. You still need to know what went in.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and scans dependencies, which complements build provenance. The free scan at gold.safeguard.sh/scan shows what a repository pulls in.
Quick check
Do attestations replace an SBOM?
No. One records how the artifact was built, the other lists what is inside. GitHub lets you attach an SBOM to an attestation to carry both.
Are attestations a compliance certification?
No. They are signed build metadata. They can support evidence for a control, but they are not an audit result.
Sources
Last reviewed: 19 October 2026.
