Vérifier la nomenclature logicielle (SBOM) et les preuves de somme de contrôle

Introduction

Les preuves relatives à la chaîne d'approvisionnement ne sont utiles que si vous les vérifiez avant le déploiement. Un bundle de version peut contenir un manifeste Kubernetes, une nomenclature logicielle (SBOM), des métadonnées d'image et un fichier de somme de contrôle. La somme de contrôle prouve que les fichiers listés n'ont pas été modifiés. Le SBOM et les métadonnées de l'image vous aident à confirmer l'image et les preuves de paquets que la version prétend contenir.

Dans ce laboratoire, vous validerez un bundle de version local à l'aide de sha256sum et jq, confirmerez que le SBOM et les métadonnées de l'image décrivent la charge de travail approuvée, enregistrerez un résultat de validation JSON compact et ne déploierez que le manifeste approuvé. Ce laboratoire ne nécessite aucun téléchargement externe ni outil de signature. Il se concentre sur l'habitude fondamentale du CKS : vérifier les preuves locales avant de faire confiance à l'artefact de version.

Inspecter le bundle de version

Dans cette étape, vous inspecterez le bundle de version avant d'exécuter toute commande de validation. Cela est crucial car les fichiers de somme de contrôle ne couvrent que les chemins qui y sont listés. Un fichier peut exister dans le bundle tout en étant en dehors de l'ensemble de version approuvé.

Commencez dans le répertoire du projet et lisez les notes :

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

Listez les fichiers du bundle :

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

Entrez dans le bundle et inspectez le fichier de somme de contrôle :

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

Vous devriez voir les sommes de contrôle pour manifests/receipt-ledger-approved.yaml, sbom.json et image-metadata.json. Le manifeste non listé devrait exister dans le bundle, mais il ne devrait pas apparaître dans checksums.sha256.

Vérifier les sommes de contrôle et rejeter le candidat non listé

Dans cette étape, vous vérifierez les artefacts listés avec sha256sum -c. L'option -c lit les hashs attendus à partir d'un fichier de somme de contrôle et les compare aux fichiers actuels. Un résultat positif signifie que les fichiers listés correspondent toujours aux sommes de contrôle approuvées.

Exécutez la vérification de la somme de contrôle :

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

Confirmez que le manifeste non listé ne fait pas partie des preuves de somme de contrôle approuvées :

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

La première commande devrait afficher OK pour les trois fichiers listés. La seconde commande devrait indiquer que le manifeste non listé ne figure pas dans la liste des sommes de contrôle approuvées.

Faire correspondre les métadonnées SBOM aux métadonnées de l'image

Dans cette étape, vous inspecterez le SBOM et les métadonnées de l'image. La somme de contrôle vous indique que les fichiers n'ont pas été modifiés, mais elle n'explique pas si le SBOM décrit l'image que vous prévoyez de déployer. Pour cela, comparez le nom de l'image et le digest dans les deux fichiers.

Extrayez les métadonnées du composant SBOM :

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

Confirmez que le SBOM contient l'entrée de paquet attendue :

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

Inspectez les métadonnées de l'image :

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

Créez maintenant un JSON de validation compact à partir des preuves que vous venez d'inspecter. Les variables shell lisent la somme de contrôle du manifeste approuvé et le digest de l'image à partir du bundle au lieu de les coder en dur.

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

Ce JSON n'est pas un rapport textuel. Il s'agit d'un petit enregistrement lisible par machine des faits de vérification que vous souhaiteriez obtenir avant le déploiement.

Déployer uniquement le manifeste approuvé

Dans cette étape, vous déploierez uniquement le manifeste qui a réussi la validation de la somme de contrôle. Le candidat non listé est présent dans le bundle, mais comme il n'était pas listé dans le fichier de somme de contrôle approuvé, il doit rester en dehors du cluster.

Appliquez le manifeste approuvé :

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

Attendez le déploiement :

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

Confirmez que le déploiement non listé n'a pas été créé :

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

Lisez le statut d'exécution du Pod approuvé :

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

Le statut d'exécution devrait être :

release-status=approved

Résumé

Vous avez inspecté un bundle de version local, vérifié les sommes de contrôle approuvées, confirmé qu'un candidat non listé était en dehors de l'ensemble de version approuvé, fait correspondre les métadonnées SBOM aux métadonnées de l'image, enregistré des preuves de validation JSON compactes et déployé uniquement le manifeste Kubernetes approuvé. C'est le flux de travail essentiel des preuves de la chaîne d'approvisionnement : vérifier l'intégrité et l'identité avant le déploiement.