Artifact Attestations, SBOMs, Build Provenance, Verification, and SLSA-Oriented Workflows: Diagnostics, Failure Modes, Security, and Performance

1. Failure: signature valid, builder policy wrong

Imagine artifact.tar has a valid GitHub attestation from acme/scratch-builds, but production policy allows only acme/release-platform/.github/workflows/release.yml. A verifier that checks only --owner acme may accept an identity that is cryptographically genuine but operationally unauthorized.

# Too broad for production if many repositories may sign.
gh attestation verify artifact.tar --owner acme

# Stronger: require the expected repository and signer workflow.
gh attestation verify artifact.tar   --repo acme/widget   --signer-workflow acme/release-platform/.github/workflows/release.yml   --source-ref refs/heads/main

Preserve both outputs. The first demonstrates why cryptographic validity alone is not sufficient; the second demonstrates the intended authorization policy. If the stronger check fails, do not weaken it reflexively—determine whether the artifact is wrong or the documented policy is stale.

2. Intentionally broken example: artifact bytes changed after attestation

Start from a copy of the verified Lesson 2 artifact so the original evidence remains intact. Append one byte to the copy and rerun verification. This is non-destructive to the original but creates a real substitution failure.

cp atlas-lab.tar atlas-lab-tampered.tar
printf 'X' >> atlas-lab-tampered.tar

printf 'original: '
sha256sum atlas-lab.tar
printf 'tampered: '
sha256sum atlas-lab-tampered.tar

set +e
gh attestation verify atlas-lab-tampered.tar   -R "$REPO"   --signer-workflow "$REPO/.github/workflows/ch25-attest.yml"   2>tampered.verify.stderr
STATUS=$?
set -e

cat tampered.verify.stderr
printf 'verification_exit=%s
' "$STATUS"
test "$STATUS" -ne 0

Expected interpretation: the tampered file computes a different subject digest, so the verifier cannot validate it against the attestation issued for the original bytes. Repair means restore/re-download the known artifact and verify again—not create a new attestation for unexplained bytes.

3. Failure: SBOM was generated from source, not shipped reality

A common pipeline generates an SBOM immediately after dependency resolution, then a later packaging stage vendors a native library or downloads a runtime asset. The SBOM can be correctly attested yet incomplete because the claim itself does not describe final contents. Cryptography protects the claim’s provenance; it does not infer missing components.

4. Failure: attestations exist, nobody verifies them

A team celebrates that every release run produces attestations, but the deployment script continues to run curl ... && deploy without gh attestation verify or equivalent policy. This adds storage and dashboards, not a security boundary. GitHub’s own documentation explicitly states that generating attestations alone does not provide the security benefit; consumers must verify.

# Weak deployment outline: presence is assumed.
# download artifact
# deploy artifact

# Governed outline:
# download artifact
# compute/record digest
# verify attestation + expected signer/source policy
# verify required SBOM predicate if policy needs it
# deploy only on success

5. Failure: “we use GitHub attestations, therefore we are SLSA L3”

GitHub currently states that artifact attestations by themselves provide SLSA v1.0 Build Level 2 and that a vetted reusable-workflow design can help achieve v1 Build Level 3. The current SLSA specification is v1.2. A team that claims “SLSA L3” merely because it uses actions/attest has skipped the architectural requirements around build platform, isolation, producer process and verification.

6. Failure: policy overlooks runner trust

An attestation may identify a valid workflow that ran on self-hosted infrastructure. If your threat model requires GitHub-hosted isolation, that difference is causal. Current GitHub CLI exposes --deny-self-hosted-runners so a deployment policy can reject attestations generated on self-hosted runners.

gh attestation verify artifact.tar   --repo acme/widget   --signer-workflow acme/widget/.github/workflows/release.yml   --deny-self-hosted-runners

Do not interpret this as “self-hosted runners are always insecure.” Chapter 16 established that self-hosted runners are a separate trust zone whose patching, network reach, persistence and isolation are operator responsibilities. The verifier flag is appropriate only when the consumer policy intentionally excludes that trust zone.

7. Failure: REST bundle presence is treated as verification

# Discovery/inventory only:
gh api -H "X-GitHub-Api-Version: 2026-03-10"   "repos/acme/widget/attestations/sha256:EXAMPLE_DIGEST"

# Acceptance requires cryptographic + identity verification:
gh attestation verify artifact.tar --repo acme/widget   --signer-workflow acme/widget/.github/workflows/release.yml

The REST documentation itself warns that an attestation’s signature/timestamps and signer identity must be cryptographically verified for meaningful security. Use REST to find evidence and CLI/library verification to decide trust.

8. Reliability and performance where they are causal

Verification adds network/API/registry dependency and cryptographic work. For individual release artifacts this is usually small, but high-volume deployments should cache/download attestation bundles deliberately, handle API pagination/rate limits, and design offline verification for air-gapped environments. Do not skip verification merely because the network is unavailable; define a trusted offline-bundle/trusted-root procedure or fail closed according to deployment criticality.

For OCI images, fetching image and attestation bundles may involve registry authentication. Do not log registry credentials or attestations containing confidential predicate data. Public attestations and transparency-log data should be treated as intentionally public evidence.

9. Evidence-first diagnostic runbook

Knowledge check

Summary

Most attestation failures are policy/data-lifecycle failures, not broken cryptography. Preserve the exact subject and verifier output, distinguish authenticated certificate identity from workflow-controlled predicate content, fix wrong bytes/builders/SBOM stages rather than weakening checks, and state SLSA claims no stronger than the evaluated evidence. The checkpoint now turns those lessons into one end-to-end consumer gate.

Official references

• gh attestation verify
• Artifact attestations — concepts
• Repository attestation REST API
• Verifying attestations offline
• SLSA v1.2 Build requirements