Skip to content

CONCEPT Cited by 1 source

Release attestation

A release attestation is a signed cryptographic statement that a specific release — identified by tag, asset digests, and optionally build-pipeline metadata — was published by a specific identity, portable outside the platform that produced it. It is the receipt that lets downstream consumers verify a release is authentic and unmodified without having to re-contact the publishing platform.

Two architectural properties distinguish release attestations from adjacent primitives:

  1. Portable: verification works outside the issuing platform. A mirror, an air-gapped enterprise, or a CI system running on a different cloud can verify the attestation with no network call back to the issuer. This distinguishes attestations from API-based integrity checks ("ask GitHub's API whether this release still exists with these assets") which require live platform access.
  2. Whole-release scoped: the attestation binds to the release (tag + asset set + metadata) as an aggregate, not to individual blobs or commits. This differs from commit signing, which attests a single commit's authorship, and from object-level checksum signing, which attests a single blob.

Canonical instance: GitHub immutable-release attestations

When a release is published with immutability enabled (see concepts/publish-time-immutability), GitHub emits a signed attestation in Sigstore bundle format. The attestation is retrievable via the GitHub CLI (gh attestation verify) or any Sigstore-compatible verifier (cosign, language SDKs, policy engines like Kyverno / OPA with Sigstore plugins).

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

The post does not disclose the attestation's identity model — whether it binds to GitHub's own keyless OIDC identity (Fulcio- issued), a per-repo identity, or a workflow-identity encoding the publishing GitHub Actions run. The signer identity determines what downstream policy can actually conclude from a valid signature.

What the attestation binds

Minimally, a release attestation binds:

  • The release's identity (repo + tag + release metadata)
  • Asset digests (content-addressed hash per asset)
  • A signer identity (public key or OIDC claim-set)
  • A timestamp (at minimum, signature time; ideally transparency-log inclusion time)

Richer attestations (e.g. SLSA provenance) can additionally bind:

  • Build system identity (which CI, which runner)
  • Source commit (Git SHA the build was sourced from)
  • Build command / entrypoint (reproducibility inputs)
  • Materials (dependency hashes consumed)

The GitHub changelog does not specify which tier its attestations reach.

Enforcement vs attestation — the two-half model

Supply-chain controls come in two orthogonal halves:

  • Enforcement: the publishing platform refuses to allow modification. Examples: GitHub's server-side asset-lock and tag-protection on immutable releases; S3 Object Lock; a package registry's refusal to let a published version be re-published.
  • Attestation: the platform emits a signed statement that the consumer can verify independently. Examples: Sigstore bundles, SLSA provenance, Notary v2 signatures.

Enforcement is only valid inside the platform. Attestations travel. A complete supply-chain control needs both — which is why GitHub immutable releases ships enforcement (asset + tag lock) and attestation (Sigstore bundle) together. (Source: sources/2025-10-31-github-immutable-releases-ga)

Verification model

The attestation-side consumer flow:

  1. Consumer receives the release artifact (from GitHub, a mirror, an internal cache, etc.) along with its attestation bundle.
  2. Consumer invokes a Sigstore-compatible verifier, passing the artifact, the bundle, and a trust policy (which signer identities are acceptable).
  3. Verifier: (a) checks the signature against the certificate chain, (b) recomputes the artifact's digest and compares, (c) checks transparency-log inclusion, (d) evaluates the trust policy against the signer identity.
  4. On success: the artifact is authenticated + integrity-checked against a named identity, without GitHub being online.

This shape pushes verification policy into the consumer's environment — a control-plane decision the consumer makes, keyed off data-plane evidence.

Why Sigstore format specifically (GitHub's choice)

Sigstore is CNCF-graduated and has multi-language SDK support, cosign tooling, Fulcio (certificate authority), and Rekor (transparency log). By choosing Sigstore-bundle format GitHub elects:

  • Ecosystem compatibility — verification integrates with existing Kubernetes admission controllers, Docker image policies, etc.
  • No GitHub-specific verifier lock-in — consumers are not forced to run GitHub-proprietary tooling to verify.
  • Transparency-log backing — Rekor inclusion means attestations are publicly auditable, which closes a "silent re-sign" attack class.

Seen in

Last updated · 200 distilled / 1,178 read