SBOMs, signatures, and provenance

Follow one artifact without changing the question

A digest is a content-derived identifier. A tag is a name that a registry can move. An SBOM is a software bill of materials: an inventory of components found or declared for a particular artifact. A signature lets a verifier check that an allowed key or signing identity signed the intended object. Provenance describes build inputs and process. Together they answer inventory, authenticity, and build-history questions; they do not replace functional tests.

Work through an invented release: image digest A has an SBOM and a passing transaction test. Someone moves its tag to digest B. Verifying evidence for A while deploying the tag's new B checks the wrong object. Bind the deployment and evidence to the intended digest. Now suppose A is correctly signed but has a broken balance calculation: identity verification can still pass because it was not a balance test.

Small practice: create three columns labelled “which bytes?”, “who built/signed them?”, and “what behavior passed?”. Put the image digest in the first, restricted signing identity and verified provenance in the second, and the transaction result in the third. An SBOM helps inventory the first column's components, but cannot fill the third. Mark a missing piece as missing; do not infer it from another column.

Ask three separate questions

An SBOM inventories components. A signature associates a verified signing identity or key with an artifact. Provenance describes how an artifact was built. None alone establishes that the application behaves correctly or contains no vulnerabilities.

Generate an SBOM for the already-built Accounts image:

Run this from the MicroBank checkout after the scanning bite has created evidence/security/; use the same reviewed Trivy installation.

: "${STUDY_TAG:?Select the built Accounts image tag}"
trivy image --image-src docker --format cyclonedx \
  --output evidence/security/accounts.cdx.json "microbank-study/accounts:$STUDY_TAG"

Keep the image ID alongside the SBOM. A local Docker image ID is not always interchangeable with a registry manifest digest; multi-platform indexes introduce another identity layer. When publishing becomes part of your own workflow, record the registry digest of the actual image selected for deployment.

Understand verification before adding signing

Cosign can sign and verify container images. With keyless signing, verification must restrict the expected certificate identity and OIDC issuer, as well as reference the intended digest. Merely checking that some signature exists is too weak.

Do the first identity review as a design exercise: identify the repository, workflow, allowed trigger/ref, expected issuer, and where verification would block deployment. Check the build-system and evidence requirements for a SLSA level before claiming it; a provenance JSON file alone is insufficient.

MicroBank release record

Create a table linking source commit → build invocation → image ID/digest → SBOM → test result → deployed Pod image ID. Mark any missing signature/provenance step as missing. With images loaded locally into kind, you can practise checking artifact consistency. An authenticated registry and admission enforcement require separate setup and verification.

Checkpoint: explain which evidence would detect an unexpected image and which evidence would detect a business-logic regression. Those are different checks.

Test a verification failure deliberately

Once your own signing/publishing workflow exists, verify a known artifact with the expected identity, then test a deliberately wrong allowed identity or issuer. The negative verification should fail for that reason. Do not weaken identity restrictions to make the exercise pass.

Keep this distinct from a vulnerability finding and a business-logic test. A signed artifact can contain a bug, an SBOM can be incomplete, and valid provenance can describe a build whose inputs were unsuitable. Later policy enforcement should name the evidence it requires and how missing evidence is handled.

Checkpoint answer: a digest mismatch detects different content; a failed allowed-identity check detects the wrong signer under that policy; a transaction assertion detects a tested behavior mismatch. A signed, inventoried artifact can still fail that assertion. Continue to workload hardening to limit what the correctly identified process may do after it starts.

Sources

Trivy SBOM generation↗, Cosign signing↗, Cosign verification↗, and SLSA specification↗.