Project challenges / verified progress
Beacon: package it so anyone can run it

The engineering notebook

Prove who built it

How can someone verify the image came from your workflow?

Loading statusStage 8 of 9

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Phase 3 — Publish, inspect, prove

Step 01 of 06

Learn the concept

A digest proves bytes did not change after you named them. It does not prove who produced those bytes. SolarWinds and the xz-utils backdoor were not reminders to hash harder; they were reminders that provenance is a separate question.

DIGEST TO TRUSTED CLAIM01Image digestcontent identitysha25602OIDC identityGitHub or usershort lived03Cosign signsignature objectattached04Rekor logpublic recordauditable05Verifyidentity plus bytespolicy
Signing does not replace the digest. It signs the digest and binds it to an identity. Verification asks whether this exact image was signed by the identity your policy accepts.
Step 01

The ideas this is made of

Hashes answer what, not who

If two people build two images, each image has a digest. Pulling by digest protects you from tag movement, but it does not say whether the digest was produced by your release workflow, a laptop, or an attacker with push access. Signatures add an identity claim over that digest.

Keyless signing avoids secret key babysitting

Traditional signing requires storing and rotating a private key. Cosign keyless signing asks an OIDC provider, such as GitHub, to issue a short-lived identity certificate. The signature can then be verified against the certificate subject and issuer. There is still trust, but not a long-lived key sitting in CI like a loaded mousetrap.

Transparency logs make quiet rewrites harder

Rekor records signing events in an append-only log. That means signatures can be audited after the fact, and suspicious duplicate or unexpected signatures are visible. A transparency log does not prevent every attack. It changes the attack from silent to observable, which is often the difference between incident and mystery.

Attestations are signed statements about the artifact

A signature says an identity signed a digest. An attestation says something more: this build used this workflow, this SBOM belongs to the image, these materials were inputs. Tools can verify attestations separately from signatures. That is how supply-chain policy grows beyond "was it signed?" into "was it built the way we require?"

Keyless sign and verify
cosign sign ghcr.io/YOUR_GITHUB_USERNAME/beacon@sha256:YOUR_DIGEST

cosign verify   --certificate-identity-regexp 'https://github.com/YOUR_GITHUB_USERNAME/.*'   --certificate-oidc-issuer https://token.actions.githubusercontent.com   ghcr.io/YOUR_GITHUB_USERNAME/beacon@sha256:YOUR_DIGEST

For a local interactive sign-in, the issuer may be Sigstore's OIDC flow rather than GitHub Actions. Verification policy must match the identity that actually signed.

Integrity, identity, provenance

QuestionMechanismExample

What bytes?

Digest

sha256:abc...

Signed by whom?

Cosign signature

GitHub OIDC identity

Logged where?

Rekor

Transparency entry

Built how?

Attestation

SLSA provenance

What these are called on the job

  • Cosign — Sigstore's tool for signing and verifying container images and related artifacts.

  • OIDC — OpenID Connect, used here to obtain a short-lived signing identity.

  • Rekor — Sigstore's transparency log for signatures and attestations.

  • Attestation — A signed statement about an artifact, such as provenance or SBOM linkage.