Artifact Attestations, SBOM Provenance, Verification, and SLSA-Oriented Builds: Diagnostics, Failure Modes, and Production Practices

1. Failure diagnosis starts with the original subject

When verification fails, do not rebuild first. Preserve the exact artifact that failed, its SHA-256, the attestation bundle/ID, verifier command/output, run ID/attempt, source SHA and workflow revision. A rebuild may create different bytes and turn one diagnosable incident into two unrelated subjects.

2. Evidence-first diagnostic sequence

Use the same causal sequence established across the course: preserve run/attempt and first-failure evidence → confirm event/ref/SHA and workflow revision → confirm permissions/inputs → inspect job/runner/toolchain → confirm the exact subject digest → inspect attestation ID/type/signer → verify expected identity → inspect artifact storage/distribution → apply the least destructive correction → rerun only the smallest equivalent scope.

3. Failure layers and signatures

4. Intentionally broken example: attest a rebuilt file

Suppose build job A produced digest D1 and uploaded the artifact. A later “sign” job checks out the same source but rebuilds independently and produces D2. It then attests D2 while the release channel still serves D1. Both jobs may be green, yet consumer verification of the released bytes fails.

# BROKEN ARCHITECTURE — teaching example only
jobs:
  build:
    steps:
      - run: ./build.sh          # produces D1 and publishes it
  sign-later:
    needs: build
    steps:
      - run: ./build.sh          # rebuilds; may produce D2
      - uses: actions/attest@FULL_SHA
        with:
          subject-path: dist/app

Repair: transfer the exact D1 bytes through a controlled artifact channel, verify D1 after download, and attest/publish the same object. Better still, when practical, build and attest in one trusted job before distribution.

5. Failure: verification checks only that “someone valid signed it”

A consumer runs a broad owner-level verification even though only one release workflow should be trusted. The command succeeds for an artifact produced by another allowed repository/workflow under the owner. This is not a cryptographic failure; it is an authorization-policy failure.

Repair by constraining the expected repository, signer workflow and/or source ref. Preserve the previously successful broad verification as evidence of why the old policy was insufficient.

6. Failure: SBOM is treated as a vulnerability verdict

A signed SPDX predicate verifies correctly, but operations assumes this means “no vulnerable packages.” That conclusion is unsupported. Verification only authenticates the SBOM claim and subject relationship. Run vulnerability analysis separately and record its database/version/time because vulnerability state changes after the build.

7. Failure: provenance is treated as proof that source is secure

An attestation can correctly identify a malicious source revision and malicious workflow. Provenance is valuable because it makes that origin visible; it does not judge whether the origin was acceptable. Repository review, branch protection, dependency governance, testing and security analysis remain necessary.

8. Failure: high-assurance build uses @main dependencies

The release workflow is protected, but it invokes external actions by mutable branches/tags. An upstream movement changes executable build code without changing your workflow file. The attestation remains authentic but now describes a different build implementation.

Repair by mapping reviewed releases to full commit SHAs, pinning them, recording the mapping in the dependency register, and reviewing upgrade diffs as Chapter 21 taught.

9. Failure: attestation action cannot mint/store evidence

If the action cannot request signing identity or persist its result, inspect the job's effective permissions before touching credentials. id-token: write is not a secret and should not be replaced with a PAT. attestations: write and current artifact-metadata: write requirements belong only where attestation is produced.

10. Do not debug by printing OIDC tokens or entire contexts

Raw OIDC tokens and broad contexts are unnecessary for routine attestation debugging and can disclose sensitive identity/session material. Prefer action error messages, run identity, declared permissions, attestation IDs and verifier diagnostics. Never weaken TLS or bypass identity validation to “see whether it works.”

11. Preserve first-failure evidence before rerun

12. Least-destructive recovery patterns

If the wrong file was attested, do not pretend the attestation applies to another digest; produce a new corrected build/evidence chain and mark the erroneous subject as rejected. If the verifier policy was too broad, tighten policy and re-evaluate the existing artifact rather than rebuilding it. If a dependency was mutable, pin and review it, then create a fresh build whose new digest/provenance is intentionally distinct.

13. Lesson summary

Attestation incidents are easiest to solve when bytes, signer identity, predicate type and storage/deployment state remain separate. Preserve the original subject and policy evidence, diagnose the causal layer, then make the narrowest correction without erasing the first failure.

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.