Verify SBOM and Checksum Evidence

Introduction

Supply-chain evidence is useful only when you verify it before deployment. A release bundle may contain a Kubernetes manifest, an SBOM, image metadata, and a checksum file. The checksum proves that listed files have not changed. The SBOM and image metadata help you confirm what image and package evidence the release claims to contain.

In this lab, you will validate a local release bundle with sha256sum and jq, confirm that the SBOM and image metadata describe the approved workload, record a compact JSON validation result, and deploy only the approved manifest. This lab does not require external downloads or signing tools. It focuses on the core CKS habit: verify the local evidence before trusting the release artifact.

Inspect the Release Bundle

In this step, you will inspect the release bundle before running any validation command. This matters because checksum files only cover the paths listed inside them. A file can exist in the bundle and still be outside the approved release set.

Start in the project directory and read the notes:

cd /home/labex/project
sed -n '1,180p' RELEASE_VALIDATION_NOTES.md

List the bundle files:

find release-bundle -path release-bundle/evidence -prune -o -type f -print | sort | tee release-bundle/evidence/bundle-files.txt

Move into the bundle and inspect the checksum file:

cd /home/labex/project/release-bundle
cat checksums.sha256 | tee evidence/checksum-file-review.txt

You should see checksums for manifests/receipt-ledger-approved.yaml, sbom.json, and image-metadata.json. The unlisted manifest should exist in the bundle, but it should not appear in checksums.sha256.

Verify Checksums and Reject the Unlisted Candidate

In this step, you will verify the listed artifacts with sha256sum -c. The -c option reads expected hashes from a checksum file and compares them with the current files. A successful result means the listed files still match the approved checksums.

Run the checksum verification:

sha256sum -c checksums.sha256 | tee evidence/checksum-verification.txt

Confirm that the unlisted manifest is not part of the approved checksum evidence:

if grep -q 'receipt-ledger-unlisted.yaml' checksums.sha256; then
  echo "unlisted manifest is unexpectedly approved" | tee evidence/unlisted-check.txt
else
  echo "unlisted manifest is not in the approved checksum list" | tee evidence/unlisted-check.txt
fi

The first command should print OK for the three listed files. The second command should say that the unlisted manifest is not in the approved checksum list.

Match SBOM Metadata to Image Metadata

In this step, you will inspect the SBOM and image metadata. The checksum tells you the files have not changed, but it does not explain whether the SBOM describes the image you plan to deploy. For that, compare the image name and digest in both files.

Extract the SBOM component metadata:

jq '.metadata.component' sbom.json | tee evidence/sbom-component.json

Confirm the SBOM contains the expected package entry:

jq '.components[] | select(.name == "busybox")' sbom.json | tee evidence/sbom-required-package.json

Inspect the image metadata:

jq . image-metadata.json | tee evidence/image-metadata-review.json

Now create a compact validation JSON from the evidence you just inspected. The shell variables read the approved manifest checksum and image digest from the bundle instead of hard-coding them.

approved_sha="$(awk '$2=="manifests/receipt-ledger-approved.yaml" {print $1}' checksums.sha256)"
image_digest="$(jq -r '.digest' image-metadata.json)"

cat > evidence/validation.json <<EOF
{
  "checksum_status": "verified",
  "approved_manifest": "manifests/receipt-ledger-approved.yaml",
  "approved_manifest_sha256": "${approved_sha}",
  "sbom_name": "receipt-ledger",
  "sbom_version": "1.8.4",
  "sbom_image": "busybox:1.36",
  "sbom_package": "busybox",
  "image_digest": "${image_digest}",
  "rejected_manifest": "manifests/receipt-ledger-unlisted.yaml",
  "rejection_reason": "not-listed-in-checksums"
}
EOF
jq -M . evidence/validation.json

This JSON is not a prose report. It is a small machine-readable record of the verification facts you would want before deployment.

Deploy Only the Approved Manifest

In this step, you will deploy only the manifest that passed checksum validation. The unlisted candidate is present in the bundle, but it was not listed in the approved checksum file, so it should stay out of the cluster.

Apply the approved manifest:

kubectl apply -f manifests/receipt-ledger-approved.yaml

Wait for the Deployment:

kubectl -n cks-prep-sbom rollout status deployment/receipt-ledger --timeout=120s

Confirm that the unlisted Deployment was not created:

if kubectl -n cks-prep-sbom get deployment receipt-ledger-unlisted >/dev/null 2>&1; then
  echo "unlisted deployment exists" | tee evidence/unlisted-deployment-check.txt
else
  echo "unlisted deployment is absent" | tee evidence/unlisted-deployment-check.txt
fi

Read the runtime status from the approved Pod:

pod="$(kubectl -n cks-prep-sbom get pod -l app=receipt-ledger --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')"
kubectl -n cks-prep-sbom exec "$pod" -- cat /release/status.txt | tee evidence/runtime-status.txt

The runtime status should be:

release-status=approved

Summary

You inspected a local release bundle, verified the approved checksums, confirmed that an unlisted candidate was outside the approved release set, matched SBOM metadata to image metadata, recorded compact JSON validation evidence, and deployed only the approved Kubernetes manifest. This is the core supply-chain evidence workflow: verify integrity and identity before deployment.