Artifact Attestations, SBOM Provenance, Verification, and SLSA-Oriented Builds: Configuration, Design Patterns, and Trade-Offs

1. Start with the question, not the feature

Supply-chain controls become confusing when teams add “signing,” “SBOM” and “SLSA” as checklist words. Begin with the decision that a consumer must make. If the question is “are these bytes unchanged?” use a digest. If it is “which approved workflow produced these bytes?” require provenance plus identity policy. If it is “what components does the producer claim are present?” require an SBOM predicate. If the question is “where can I download the binary?” choose an artifact/package/release store.

2. Mechanism decision table

3. Verification policy: owner-only is convenient; exact signer is stronger

The GitHub CLI requires at least an owner or repository boundary. Production policy should usually be narrower than “anything signed anywhere in this organization.” Add the expected repository, signer workflow and source ref where those values are stable and meaningful. For reusable-workflow builders, verify the reusable workflow identity as the signer using the CLI's signer controls.

Overly broad identity conditions increase the blast radius of a compromised workflow. Overly rigid conditions can make legitimate migrations painful. Treat policy changes as reviewed code and record why each accepted signer exists.

4. Reusable workflow as a trusted-builder boundary

A normal repository workflow can be modified by anyone allowed to change that workflow. For higher assurance, organizations can centralize build and attestation logic in a protected reusable workflow, pin callers to reviewed releases/commits and verify that reusable workflow as the signer. This reduces the number of locations that can alter the build/attestation implementation.

That pattern is stronger only if the reusable workflow itself is protected, its inputs cannot subvert the build boundary, its action dependencies are immutable, and caller-provided data cannot replace trusted builder code. Centralization without change control is not a trusted builder.

5. Provenance versus SBOM: complementary, not substitutes

Provenance carries build identity and source/build metadata. SBOM carries component inventory. A release pipeline often needs both, because a consumer may first verify “this came from our approved release workflow” and then ask “does this build contain component X?” Neither claim replaces vulnerability scanning or policy evaluation.

6. Public versus private attestation infrastructure

7. Artifact upload versus attestation versus registry flow

For a file release, you can attest local bytes and later upload those exact bytes to a release/package channel. For OCI images, the subject is normally an immutable image digest rather than a mutable tag. The action can also support registry-oriented attestation flows, but registry authentication and package permissions are additional side effects and are outside this chapter's mandatory lab.

Do not let a convenience tag such as latest become the trust anchor. Resolve and verify immutable digests.

8. Permissions belong to the attestation job, not the whole pipeline by habit

The build/attestation job needs OIDC and attestation write authority. That does not mean every lint/test job needs it. Scope id-token: write and attestation permissions to the job that performs signing. If source checkout is needed, add contents: read; do not grant repository write scopes merely because the action creates signed evidence.

9. High-assurance provenance still depends on the workflow supply chain

A perfectly signed provenance statement can faithfully say that a build ran a compromised mutable action. Chapter 21 therefore remains part of Chapter 23: pin external actions by full commit SHA, review release provenance and keep the runner/toolchain assumptions observable. Attestation raises confidence in which build happened; it does not make an unsafe build definition safe.

10. Online versus offline verification

Online gh attestation verify can fetch associated attestations from GitHub. For disconnected environments, GitHub documents downloading the attestation bundle and trusted roots ahead of time, then verifying offline. Offline verification is a distribution/operations design choice; the policy identity constraints should remain equivalent.

11. SLSA-oriented control map

12. Worked scenario: release CLI binary

A team publishes a cross-platform CLI. It chooses a central protected reusable workflow, pins all external actions by SHA, builds each platform artifact once, computes digests, creates provenance + SBOM attestations, and publishes the same bytes. Consumers verify repository + signer workflow + expected source ref before installation. A separate vulnerability process evaluates the SBOM. Deployment/release approval consumes these results but remains an independent governance state.

13. Lesson summary

Select provenance, SBOM, storage and verification controls by the questions they answer. Strong assurance comes from composing immutable inputs, protected builders, narrow signing permissions and explicit consumer identity policy—not from any one badge or signature.

Knowledge check

Official references and version notes

• Artifact attestations concept — GitHub model for Sigstore-backed attestations, public/private signing roots and verification policy.
• Use artifact attestations — Current generation, permissions, binary/container and verification guidance.
• actions/attest v4.2.2 — Current consolidated GitHub action for provenance, SBOM and custom attestations.
• GitHub CLI attestation verify — Current identity, predicate, source-ref and signer-workflow verification controls.
• Verify attestations offline — Bundle and trusted-root workflow for disconnected verification.
• SLSA-oriented GitHub guidance — GitHub guidance connecting attestations and reusable workflows to stronger SLSA-oriented build controls.
• Workflow permissions — Current id-token, attestations, artifact-metadata and contents permission syntax.