Skip to content

PATTERN Cited by 1 source

Sigstore bundle attestation

Sigstore bundle attestation is the pattern of shipping a signed artifact's integrity receipt as a Sigstore-format bundle rather than in a platform-proprietary signature envelope, so verification is possible with any Sigstore-compatible tooling without a callback to the issuing platform.

The pattern is the standard shape for release attestations in 2025+ and is the canonical portable-half of a supply-chain control that pairs server-side enforcement with consumer-side verification.

Shape

publisher                       consumer
=========                       ========
build artifact                  receive artifact + bundle
  │                               │
  ▼                               ▼
sign with Sigstore keyless ───► verify bundle signature
OIDC identity (Fulcio cert)   (cert chain, trust policy, Rekor)
  │                               │
  ▼                               ▼
record to transparency        recompute artifact digest
log (Rekor)                   compare to bundle's claim
  │                               │
  ▼                               ▼
emit Sigstore bundle          pass/fail — no call to publisher
(cert + signature + digest
 + log inclusion proof)

The publisher produces a bundle. The consumer verifies it. The issuing platform is not in the verification path.

Why this shape

  • Off-platform verification. A mirror, an air-gapped enterprise, a different cloud's CI system can all verify without contacting the publisher. Essential for any supply-chain control that has to work when the publisher is offline, compromised, or unreachable.
  • Policy is consumer-owned. The consumer decides which signer identities to trust — by OIDC issuer, by subject claims, by workflow path. A platform-proprietary signature forces the consumer to accept the platform's trust decisions wholesale.
  • Transparency-log backing. Rekor inclusion is publicly auditable; a "silent re-sign" attack on a single consumer is detectable by cross-referencing the log. Platform-proprietary signatures typically don't ship with a public log.
  • Ecosystem composability. Kubernetes admission controllers (Kyverno, OPA Gatekeeper, Sigstore policy-controller), container registries, language package managers — all have Sigstore-aware paths. A bundle drops into any of them.

Canonical instance: GitHub immutable-release attestations (2025-10-28)

GitHub's GA immutable-releases feature emits release attestations in Sigstore bundle format. Verification is via the GitHub CLI (gh attestation verify) or any Sigstore-compatible tooling — the post explicitly names the interop case ("integrate with any Sigstore- compatible tooling to automate policy enforcement in your CI/CD pipelines"). GitHub's choice here — emit in ecosystem-standard format rather than invent a proprietary envelope — is what makes this pattern load-bearing in practice.

(Source: sources/2025-10-31-github-immutable-releases-ga)

Non-instances (for contrast)

  • npm's original signed-tarball scheme (pre-Sigstore): integrity shasum in the package metadata, published over HTTPS. No portable signature — if you don't trust the registry, you have no way to verify. npm has since adopted Sigstore for provenance attestations.
  • Docker Content Trust (Notary v1): pre-Sigstore signing for container images. Proprietary trust model, limited ecosystem support; largely supplanted by cosign + Sigstore for new deployments.
  • Ad-hoc release-signature .asc files (PGP-detached signatures): portable but without transparency-log backing and with no built-in identity-to-OIDC binding; still widely used for upstream Linux tarball releases.

The pattern name Sigstore bundle attestation specifically privileges the bundle format + Rekor-backed verification + keyless OIDC identity as the 2025+ convergent design, not any signed-artifact scheme.

When to use this pattern

  • Publishing a software release that will be consumed by any party outside your direct platform control (external CI, air-gapped enterprise, end-user distribution).
  • Pairing server-side enforcement (asset locks, tag protection) with a portable integrity receipt — server-side enforcement only works inside your platform, so some bytes need to travel with the release for off-platform verification.
  • Any case where downstream policy engines (admission controllers, CI gates, binary-authorization) need to enforce provenance.

When not to use

  • Closed-platform-only artifacts where consumers always re-contact the publisher to read metadata — a live-API integrity check suffices and the extra bundle overhead is pointless.
  • Artifacts that are themselves short-lived and replaced frequently (e.g. session tokens) — the verification-latency cost and Rekor traffic don't amortise.

Seen in

Last updated · 200 distilled / 1,178 read