Securing Releases

A signed commit proves who wrote the source. Release security proves something different and downstream: that the artifact you ship was actually built from that source, by your pipeline, and not swapped or tampered with somewhere between the green build and the published binary. Those are two separate guarantees, and signing commits alone gives you only the first.

Build provenance, the SLSA framework, and signed attestations close the second gap. Together they create a verifiable chain from a specific commit to the exact bytes a consumer downloads, so a tampered artifact can be detected rather than trusted on faith.

The Gap

A passing CI run and a binary in your releases page are not cryptographically linked. Nothing in the artifact, by default, says which commit produced it or which workflow built it — so a binary substituted after the build, or built from different source, is indistinguishable from the real one. Provenance is what turns an implicit assumption into a checkable claim.

Build Provenance Attestations

The actions/attest-build-provenance action produces a signed statement describing what was built, from which commit, by which workflow run, backed by Sigstore. That attestation is the link the bare artifact lacks: it ties the output bytes to their build inputs in a form a consumer can later verify against your repository and workflow.

SLSA Levels

SLSA is the supply-chain framework that grades how trustworthy that provenance is. The key property is non-falsifiability — provenance is only meaningful if the build environment could not have lied about it. Provenance generated by a hosted, isolated builder like GitHub Actions maps toward SLSA Build L2/L3, whereas a build on mutable, attacker-reachable infrastructure earns far less trust.

Signed Releases

Beyond provenance, sign the release artifacts themselves so consumers can verify origin independently: Sigstore/cosign for container images, GPG or cosign for files. The strongest form is keyless signing, where the signature is tied to the workflow's OIDC identity rather than a stored signing key — there is no long-lived private key to leak.

Verification

None of this matters unless the consuming side checks it. A consumer verifies the attestation or signature before trusting the artifact — gh attestation verify for build provenance, cosign verify for signed images. Provenance that nobody verifies on the way in is theater; the verification step is what makes the whole chain real.