Why teams keep postponing attestations
Most engineering leads agree software supply-chain integrity matters. Then the sprint starts, release pressure wins, and attestations get pushed “after the next milestone.” The blocker usually is not disagreement. It is fear of friction: longer pipelines, broken deploys, and one more security gate developers will bypass.
The good news is you can roll out artifact attestations incrementally without stalling delivery. Treat it like any production change: pilot, measure, enforce in phases.
What artifact attestations actually buy you
An attestation is signed metadata about how an artifact was built: source, workflow identity, builder, timestamps, and often dependency context. Combined with policy checks, it helps answer a hard operational question during incidents: “Can we trust this artifact, and should we deploy or roll back it right now?”
Attestations are not magic provenance truth. If your CI identity or signing keys are compromised, attackers can produce “valid-looking” attestations. You still need strong identity boundaries, short-lived credentials, and runner hardening.
Phase 1: Visibility mode (no deployment blocking)
Start by generating attestations for one service and storing them in your registry or transparency log. Do not enforce yet. First, validate pipeline behavior and developer ergonomics.
For GitHub Actions style workflows, the pattern is:
permissions:
id-token: write
contents: read
attestations: write
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t ghcr.io/org/app:${GITHUB_SHA} .
- name: Push image
run: docker push ghcr.io/org/app:${GITHUB_SHA}
- name: Generate attestation
uses: actions/attest-build-provenance@v1
with:
subject-name: ghcr.io/org/app
subject-digest: ${{ steps.digest.outputs.value }}
push-to-registry: trueKeep this pilot narrow: one language, one build path, one deploy environment.
Phase 2: Verify in pre-prod, warn only
Add a verification step in staging deployment that checks:
- Attestation exists for artifact digest
- Builder identity matches approved workflow/ref
- Build occurred within expected freshness window
In this phase, failed verification should warn, not block. You want to discover edge cases first: rebuilt hotfix tags, legacy pipelines, or third-party vendor images with incomplete metadata.
Phase 3: Enforce for production with explicit exceptions
Once warning noise drops, enforce in production deploy policy. Keep exceptions explicit, time-bound, and audited. If exceptions are invisible, enforcement slowly becomes theater.
A practical policy model:
- First-party services: valid provenance required
- Third-party base images: allowlist publisher digest + scheduled review
- Emergency break-glass: one-time bypass with incident ticket reference
Where teams usually get burned
Identity sprawl: Multiple CI identities with broad registry rights make provenance less meaningful. Restrict push rights to controlled workflows.
Long-lived secrets: If your build still depends on static credentials, attestations help less than you think. Move to OIDC-based short-lived auth first.
Digest drift confusion: People verify tags, not digests. Policy should always evaluate immutable digests.
SBOM and attestations: related, not interchangeable
SBOM answers “what is inside this artifact.” Attestation answers “how this artifact was produced.” Use both. During CVE response, SBOM helps scope affected services; attestation helps determine whether the deployed image truly came from your approved pipeline.
Minimal operating checklist for platform teams
- Define approved builders and workflow refs
- Require immutable artifact digests in deploy manifests
- Log verification outcomes for every production deploy
- Track bypass frequency as a reliability/security KPI
If bypasses trend upward, the process is either too brittle or under-supported. Fix that before tightening policy further.
Bottom line
Attestations work when they are treated as deployment reliability controls, not just compliance artifacts. Roll out gradually, keep policy understandable, and anchor enforcement to real operational risk. Teams that do this well gain faster incident triage and much higher confidence in what actually reaches production.