Lab: Container SBOM, Signing, and Attestation

Build a keyless container supply-chain pipeline with vulnerability scanning, SBOM generation, signing, provenance, and deployment verification.

Overview

This repository-first lab builds a container supply-chain workflow that scans an image, generates an SBOM, signs the image without a long-lived signing key, publishes provenance, and verifies those artifacts before deployment. Pull requests use a separate validation path with contents: read only that builds and scans locally; only trusted main/v* releases receive package-write, attestation, security-event, and GitHub OIDC permissions.

Review Status

Source and live publication reviewed July 26, 2026. The merged main workflow built and scanned the application, published sha256:d6439134951f052e54465a9bd5f54496481b460d162b252936959d64aad65d86, generated consumer SBOMs, signed the image with GitHub OIDC, attached SPDX and SLSA provenance attestations, and passed the separate evidence-verification job. See the successful workflow run.

Safety and Limits

  • Verify immutable image digests, not mutable tags.
  • The verification script binds the signer to this repository’s supply-chain.yml workflow on main or a v* tag; do not widen that identity expression to every GitHub repository or workflow.
  • Signature, SPDX SBOM attestation, and GitHub SLSA provenance verification are all mandatory and fail closed. verify-image.sh uses Cosign for all three checks and binds them to this repository’s exact authorized workflow identity.
  • Registry evidence may become visible shortly after the image manifest. The verifier retries each read-only check at most five times with bounded exponential backoff, then still fails closed if evidence remains missing or invalid.
  • Manual release dispatches reject every ref except main and v* tags. Protect both the branch and release-tag namespace with repository rulesets.
  • Actions and base images are pinned, with Dependabot configured to surface updates. Review dependency PRs before merging rather than replacing pins with mutable branches.
  • Go 1.26.5 is the reviewed minimum for both the module and builder. A digest-pinned builder may move to a newer patch without forcing the module’s minimum version to match it exactly.
  • GitHub runner minutes, retained artifacts, GHCR storage, and egress can be billable. This lab does not create Azure, AWS, or GCP resources.

Start Here

  1. Read the companion article for the security model and workflow explanation.
  2. Open the canonical GitHub repository for the current prerequisites and files.
  3. Follow the repository README through build, vulnerability review, digest-based verification, and cleanup.

The GitHub README is the source of truth for commands because action versions, registry behavior, and attestation tooling can change independently of the article.