Use gh attestation verify with the artifact path and the source repository for a binary, add an oci:// prefix for a container image, and add --predicate-type to check an SBOM attestation. A pass means the attestation matches that artifact and repository. It does not mean the software is safe.
GitHub's documentation shows all three forms. This post lays them out and adds a short routine for using them in a release check.
The three forms
A binary. Pass the file and the organization and repository you expect:
gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME
A container image. Log in to the registry first, then prefix the reference with oci://:
gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test
The documentation example for images does not show a repository flag. Check the current command reference for flags that state the expected repository before you script it.
An SBOM attestation. Add --predicate-type, such as https://spdx.dev/Document/v2.3 for SPDX. You can add --format json with --jq to inspect the predicate content.
What each check is saying
| Command form | You are confirming |
|---|---|
| Binary with repository | This file has an attestation tied to that repository |
| Image with oci prefix | This image reference has an attestation |
| Predicate type given | An attestation of that specific kind exists, such as SBOM |
The repository flag is the expectation. If you leave it out, you are checking less, because you are not stating where the artifact should have come from. That echoes the SLSA advice that verification needs expectations, not just a valid signature.
What a pass does not cover
GitHub's page says attestations establish where and how software was built. It does not state any claim about vulnerabilities or code safety, and neither should you.
A pass also does not say the build used reviewed code, only that it happened in the place named. Pair verification with branch protection and review rules in the source repository.
A release check routine
- Download the artifact from the place customers get it.
- Run the verify command with the repository you expect.
- For images, verify by the digest you plan to deploy, not a moving tag. Tags can be repointed.
- Run the SBOM form if you ship SBOM attestations, and read the content.
- Save the output with the release record.
- Make a deploy job fail when verification fails.
Step three is a general good habit rather than something the page requires, since digests name exact content and tags can move.
Handling failures
When verification fails, resist the urge to rerun until it passes. Read the message, confirm the repository name, and check whether you are verifying the artifact that was actually attested. A rebuilt or re-tagged artifact has a different digest and will not match an older attestation.
Where scanning fits
Verification tells you about origin. Scanning tells you about contents. Safeguard's dependency scanning and SBOM tools cover the second part, and you can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Do I need the repository flag?
The documentation examples include it. Without it you are not stating where the artifact should have been built.
Does verification confirm the image has no vulnerabilities?
No. It confirms origin information. Scan separately.
Sources
Last reviewed: 19 October 2026.
