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 reviewed July 10, 2026. The Go application, health probe, shell scripts, workflow YAML, action pins, Dockerfile, and verification commands passed local or static checks. The review did not run Docker, publish a new GHCR image, or perform a fresh GitHub OIDC signing ceremony, so the registry signature and attestations must still be confirmed from a 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. The provenance check uses GitHub CLI; authenticate gh and the GHCR registry before verifying a private package.
  • 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.
  • 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.