We released a collection of improvements to Artifact Attestations to make the verification of attestations easier and more consistent.
Artifact Attestations let you create provenance signatures, which provide an unforgeable paper trail that links your artifact back to its originating workflow run. By verifying the signature, you can gate deployments to ensure that what you deploy is exactly what you built, guaranteeing that the artifact has not been tampered with.
Today we are announcing multiple improvements based on the user feedback we have received:
- Attestation verification defaults to build provenance: Build provenance is just one type of information that can be attested to an artifact. It provides a verifiable trail that links the artifact back to its originating workflow run, ensuring its authenticity and integrity. However, other types of information can also be attested to an artifact, for example a Software Bill of Materials (SBOM). Attestations can be verified by running
gh attestation verify
using the GitHub CLI. Previously, verification succeeded as soon as there was any attestation associated with the artifact. However, we observed that provenance is verified in the vast majority of cases. Therefore, we altered the CLI to default to provenance when no predicate type is specified. This change ensures that verification does not pass merely because, for example, an SBOM was attested to the artifact. To verify an SBOM, the predicate type must be explicitly supplied as a parameter usinggh attestation verify
with the--predicate-type
parameter. - CLI outputs evaluated policies during verification: When verifying an attestation, the CLI now outputs all the policies it evaluated to determine whether the verification succeeds or fails. This increases transparency, making it easier to understand the reasons behind the verification outcome.
- Attest actions support multiple subjects: Following the release to support attesting multiple subjects, we have enhanced our
attest
,attest-build-provenance
andattest-sbom
actions to also accept a checksum file that contains a list of artifacts and their corresponding digests as input. - Attestation verification is now monotonic: This means that once verification passes for an artifact, the addition of another attestation cannot change that status. Verification now succeeds if at least one attestation passes verification. This ensures that downstream processes, such as gated deployments, are not affected for any legitimate build that has a valid provenance attestation, even if someone adds another attestation that is bad or malformed.
For more information about Artifact Attestations, see Using artifact attestations to establish provenance for builds in the GitHub documentation. If you have any feedback on Artifact Attestations, join the discussion in the GitHub Community.