In a GitHub Actions workflow, build and push the container image to a registry; record the image digest (sha256:...) from the push step output.
Add a step using the actions/attest-build-provenance action, passing subject-name (the full image reference) and subject-digest (the digest without the sha256: prefix) to generate a signed SLSA provenance attestation.
The attestation is automatically stored in the GitHub attestation store and signed using the workflow's OIDC identity via Sigstore's keyless signing—no secrets required.
To verify, run gh attestation verify oci://<image-reference>@<digest> --owner <github-org> on a machine with the GitHub CLI installed; the command fetches the attestation from GitHub and validates the Sigstore signature.
To verify an SBOM or other non-provenance predicate type, pass --predicate-type <predicate-uri> to gh attestation verify explicitly, as the default predicate is SLSA provenance.
In private or internal repositories, artifact attestations require a GitHub Enterprise Cloud plan; for public repositories, attestations are available on all plan tiers.
Known gotchas
Attestation verification is monotonic: once an artifact passes verification with a valid provenance attestation, adding additional attestations (even revoked ones) cannot change the passing status.
The subject-digest passed to attest-build-provenance must be the digest of the content (image manifest) not a tag; tags are mutable and would make the attestation unverifiable after a tag move.
gh attestation verify fetches attestations from GitHub's API; the workflow must have id-token: write permission and the repository must have attestation publication enabled, otherwise the attestation is silently not stored.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp