GitHub Actions

Artifact Attestations: Verify GitHub Actions Builds

By CI Tripwire Editorial · Published 2026-06-08 · 7 min read

Artifact attestations can make a release easier to verify, but only when the workflow signs the right output and consumers actually check the provenance before trusting it.

Key takeaways for artifact attestation security

  • GitHub says artifact attestations create signed claims that establish build provenance and include workflow, repository, commit SHA, environment, and triggering-event information. [1]
  • GitHub says generating attestations alone does not provide a security benefit unless the attestations are verified. [1]
  • GitHub's build-provenance guide requires id-token: write, contents: read, and attestations: write permissions for binary attestations. [2]
  • GitHub says artifact attestations by themselves provide SLSA v1.0 Build Level 2, while reusable workflows can help reach Build Level 3. [1] [3]
  • The GitHub CLI manual documents gh attestation verify for verifying a file path or OCI image with owner, repository, and signer constraints. [4]

Attestations are useful only when release verification exists

Bottom line: Add artifact attestations to release workflows after the build output is final, then publish a verification path that checks repository, signer, workflow, and digest before anyone treats the artifact as trusted.

GitHub describes artifact attestations as cryptographically signed claims that establish where and how software was built. [1] That makes them a release-control tool, not a general test badge.

The practical question is whether a human, script, deployment controller, or downstream package consumer verifies the attestation. GitHub's own concept page says generating an attestation alone has no security benefit unless the attestation is verified. [1]

An attestation links the artifact to workflow provenance

GitHub says an artifact attestation includes a link to the workflow, repository, organization, environment, commit SHA, triggering event, and other information from the OIDC token used for provenance. [1] That evidence helps answer whether a binary, image, or manifest came from the expected automation path.

The attestation does not mean the artifact is bug-free or malware-free. GitHub warns that artifact attestations are not a guarantee that an artifact is secure, and that consumers must define policy criteria and make a risk decision. [1]

Clean verdict: Sign released assets that consumers can verify, not every temporary file created during a CI run.

The attestation job needs narrow explicit permissions

For binary provenance, GitHub's guide lists three required workflow scopes before the actions/attest step runs: OIDC token access, repository content read access, and attestation write access. [2]

Container-image attestations add packages: write when the attestation is pushed with the image. [2] Keep that permission on the release job that truly needs registry write access, not on broad test jobs or pull-request checks.

The attestation step should run after the artifact is final. GitHub's guide says the subject-path parameter should point to the binary being attested, and container attestations use a fully qualified image name plus a SHA-256 subject digest. [2]

Verification should enforce the expected source and signer

GitHub's documentation says consumers can use the GitHub CLI to verify artifact attestations and use the information to create and enforce supply-chain policies. [1] The CLI manual documents gh attestation verify for file paths and OCI images, with required owner or repository scope. [4]

Verification should be specific. The CLI manual includes flags for repository, owner, signer repository, signer workflow, source repository, source ref, and subject digest. [4] Those checks are where a loose provenance signal becomes an enforceable release rule.

Avoid this posture: A release workflow signs an asset, but the README, install script, deployment job, and downstream consumers never run a verification command.

Reusable workflows can make signing policy more consistent

GitHub maps standalone artifact attestations to SLSA v1.0 Build Level 2 because they connect the artifact with its build instructions. [1] GitHub's reusable-workflow guide says combining reusable workflows with attestations can help a build reach SLSA v1.0 Build Level 3. [3]

The reusable-workflow guide says both the calling workflow and the reusable workflow need attestations: write, contents: read, and id-token: write, and that container-image builds also need packages: write. [3] That means central signing workflows still need permission review at both edges.

Use reusable workflows when many repositories should build and sign through the same vetted process. Then verify the signer workflow in the consumer path so a lookalike workflow cannot satisfy the same release policy. [4]

Offline verification needs a maintained trusted root

GitHub documents an offline verification path that downloads an attestation bundle, fetches trusted root material, and then verifies with --bundle and --custom-trusted-root. [5]

GitHub's offline guide says it is best practice to generate a new trusted_root.jsonl whenever new signed material is imported into an offline environment. [5] Offline provenance is still an operational process, not a file you can set once and forget.

A fast audit starts with release workflows and install docs

Search release workflows for actions/attest, attestations: write, id-token: write, container-image digests, and release upload steps. GitHub's build-provenance guide ties those permissions and subject fields directly to attestation generation. [2]

Then inspect the consumer path: release notes, install docs, deploy scripts, admission controllers, and package verification steps. Run gha-guard locally so attestation findings sit beside pinned-action, token-permission, timeout, reusable-workflow, OIDC, runner, and shell-context checks.

This article is informational and is not a substitute for a security review of your own workflows, repositories, or cloud accounts.

CI Tripwire has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 5 entries, primary platform documentation, last reviewed 2026-06-08.

Sources

  1. GitHub Docs, Artifact attestations.
  2. GitHub Docs, Using artifact attestations to establish provenance for builds.
  3. GitHub Docs, Using artifact attestations and reusable workflows to achieve SLSA v1 Build Level 3.
  4. GitHub CLI Manual, gh attestation verify.
  5. GitHub Docs, Verifying attestations offline.