Supply Chain Security Kubernetes - Sécuriser la chaîne d'approvisionnement

La supply chain security représente 20 % du CKS et couvre la réduction de l'empreinte des images, la compréhension de la chaîne d'approvisionnement, la sécurisation des artefacts et l'analyse statique des workloads et images. Ce guide se concentre sur cinq pratiques concrètes : images minimales, scan de vulnérabilités, SBOM, signature d'images et contrôle d'admission.

Ces cinq pratiques couvrent le socle, mais elles n'ont de valeur qu'insérées dans une chaîne plus large : l'intégration continue, le stockage d'artefacts et les contrôles d'admission.

La sécurité de la chaîne d'approvisionnement est le domaine le plus large de la CKS, avec 20 % de l'épreuve. Un point de méthode compte pour bien réviser : le programme officiel décrit des compétences, réduire l'empreinte des images, sécuriser les artefacts, analyser statiquement, contrôler l'admission, et n'impose aucun outil. Ce guide suit donc cette structure par objectif, et les outils qui y apparaissent sont des moyens interchangeables.

Prérequis

Cluster Kubernetes fonctionnel avec accès cluster-admin
Bases Docker/conteneurs (build d'images)
kubectl configuré
Notions de sécurité (CVE, vulnérabilités)

Qu'est-ce que la supply chain d'une image ?

La chaîne d'approvisionnement d'une image conteneur couvre tout le cycle de vie avant déploiement :

Chaîne d'approvisionnement d'une image conteneur, étapes et contrôles de sécurité

Une attaque sur la chaîne d'approvisionnement compromet n'importe quel maillon : une dépendance malveillante, une construction piratée, une image modifiée en transit, ou un registre non authentifié.

Règle d'or : ne jamais faire confiance à une image simplement parce qu'elle « fonctionne ». Une image qui fonctionne peut quand même contenir des CVE critiques ou avoir été altérée.

1. Minimiser l'empreinte des images de base

C'est la première étape parce que c'est la seule qui retire du risque au lieu d'en ajouter la détection. Toutes les mesures qui suivent, signature, analyse, SBOM, portent sur ce que contient l'image : réduire ce contenu réduit d'autant ce qu'elles ont à couvrir.

Le gain se mesure immédiatement : un paquet absent de l'image ne génère aucune alerte de vulnérabilité, ne demande aucune mise à jour, et ne sert d'aucun levier à qui parvient à exécuter du code dans le conteneur.

Pourquoi les images légères réduisent la surface d'attaque

Une image qui embarque apt, bash, curl et des outils système offre à un attaquant autant de leviers s'il parvient à s'exécuter dans le conteneur. Une image distroless ne contient que le runtime et votre binaire.

Type d'image	Taille	Surface d'attaque	Cas d'usage
`ubuntu:22.04`	~70 Mo	Élevée (shell, apt, utils)	Développement
`alpine:3.19`	~7 Mo	Modérée (shell BusyBox)	Usage général
`gcr.io/distroless/static`	~2 Mo	Minimale (pas de shell)	Go, binaires statiques
`gcr.io/distroless/base`	~20 Mo	Très faible (glibc seulement)	C, C++, Java
`scratch`	0 Mo	Minimale côté base image (la sécurité dépend toujours du binaire embarqué)	Binaires entièrement statiques

Build multi-stage : compiler sans embarquer les outils

Le build multi-stage permet de compiler dans une image "build" complète et de ne copier que le binaire final dans une image minimale :

# Étape 1 : compilation (image complète)
FROM golang:1.23@sha256:60deed95d3888cc5e4d9ff8a10c54e5edc008c6ae3fba6187be6fb592e19e8c0 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp .

# Étape 2 : image finale minimale (distroless)
FROM gcr.io/distroless/static-debian12:nonroot@sha256:afa5c872c891853ca7fcf1f12c3edb23f7eeef36189728842dd51042ff57f7ab
COPY --from=builder /app/myapp /myapp
USER nonroot:nonroot
ENTRYPOINT ["/myapp"]

Bonnes pratiques images

Ces quatre règles portent sur la même question : l'image que vous déployez aujourd'hui sera-t-elle identique à celle que vous avez testée hier ? Un tag est un pointeur mutable côté registre, réaffectable sans que rien ne change dans votre manifeste ; un digest est le condensat du contenu, et il ne peut pas mentir. D'où la hiérarchie : latest ne garantit rien, un tag de version garantit une intention, un digest garantit le contenu.

Figer la version : nginx:1.25.3 plutôt que nginx:latest, une mise à jour peut introduire des CVE
Ajouter le digest pour garantir l'immuabilité, sans retirer le tag : nginx:1.25.3@sha256:abc123.... Le tag reste lisible par l'humain, le digest engage le contenu
Ne pas installer de debuggers dans les images de production (gdb, strace, tcpdump)
Nettoyer le cache dans le même RUN : apt-get install -y curl && rm -rf /var/lib/apt/lists/*

# Recommandé : tag ET digest, lisible et immuable
FROM nginx:1.31.3@sha256:8541484afbc9c8a5a8a99b379568ebbc957f658583ec9448fc43104229c03cf8

# ❌ à proscrire : latest n'est pas reproductible
FROM nginx:latest

Le marqueur # ❌ n'est pas décoratif. L'outillage d'épinglage du site réécrit les références d'images, et il ne s'arrête que sur ce marqueur : sans lui, un contre-exemple latest se fait « corriger » en image épinglée, et la démonstration disparaît en silence.

2. Scanner les vulnérabilités

Avant toute chose : scanner vos images pour détecter les CVE (Common Vulnerabilities and Exposures) connues.

L'incident Trivy de mars 2026, et ce qu'il change ici

En mars 2026, l'écosystème Trivy a subi une compromission en plusieurs vagues : publication d'un trivy v0.69.4 malveillant, compromission des tags de trivy-action, exposition de setup-trivy, puis images Docker Hub malveillantes v0.69.5 et v0.69.6. Aqua a recommandé de considérer comme compromis tous les secrets accessibles aux pipelines touchés.

L'épisode illustre exactement ce que ce chapitre enseigne : un outil de sécurité de la chaîne d'approvisionnement fait partie de cette chaîne, et se compromet comme n'importe quel autre maillon. Il justifie aussi la position retenue ici. Les commandes Trivy restent dans ce guide, parce qu'elles servent à lire les pipelines existants et qu'elles sont omniprésentes dans les supports de préparation ; mais le chemin recommandé pour un nouveau déploiement passe par un autre scanner.

Scanner avec Grype, mon choix principal

Je le privilégie pour son intégration avec Syft, pour sa priorisation du risque réel, appuyée sur EPSS, KEV et OpenVEX, et pour sa capacité à scanner images, systèmes de fichiers et SBOM indifféremment.

# Installation par binaire officiel vérifié (empreinte SHA256)
GRYPE_VERSION=0.111.0
base="https://github.com/anchore/grype/releases/download/v${GRYPE_VERSION}"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_linux_amd64.tar.gz"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_checksums.txt"
grep "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" "grype_${GRYPE_VERSION}_checksums.txt" | sha256sum -c -
sudo tar -C /usr/local/bin -xzf "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" grype

# Scanner une image
grype nginx:1.25.3

# Scanner avec seuil de sévérité (fail si CRITICAL détecté)
grype nginx:1.25.3 --fail-on critical

# Format JSON pour CI/CD
grype nginx:1.25.3 -o json > results.json

Scanner avec Trivy, culture écosystème

Vous croiserez ces commandes dans la quasi-totalité des pipelines existants et des supports de préparation au CKS, ce qui suffit à justifier de les connaître. Deux options méritent une explication. --ignore-unfixed masque les CVE sans correctif publié : utile pour ne pas bloquer un build sur un problème que personne ne peut résoudre, dangereux si vous l'activez sans suivre ces vulnérabilités par ailleurs. --exit-code 1, lui, transforme le scan en garde-fou : sans cette option, Trivy affiche les CVE et le job reste vert.

# Scanner une image
trivy image nginx:1.25.3

# Ignorer les CVE non fixées
trivy image --ignore-unfixed nginx:1.25.3

# Format pour CI/CD
trivy image --exit-code 1 --severity CRITICAL nginx:1.25.3

Une précision utile si vous révisez sur plusieurs supports : vous y verrez Trivy presque partout, et pourriez en conclure qu'il est au programme. Il ne l'est pas. Le curriculum officiel décrit la compétence, analyser une image et statuer sur le résultat, sans jamais désigner d'outil. Savoir lire une sortie Trivy reste utile ; en faire le seul scanner que vous connaissez serait une erreur de révision.

La limite à retenir avant de passer à la suite : une image sans CVE connue n'est pas une image fiable. Elle peut avoir été altérée, venir d'une source compromise, ou transporter du code malveillant qu'aucune base ne référence, l'incident Trivy en étant la démonstration directe. Le scan répond à une question précise, « quelles failles connues contient cette image », et il ne remplace ni la signature, qui établit l'intégrité, ni la provenance, qui établit l'origine, ni la politique d'admission, qui décide de ce qui entre dans le cluster.

Pour approfondir le scanning et comprendre les scores CVE : Comprendre les CVE, CVSS et EPSS.

3. Générer et exploiter un SBOM

Un SBOM (Software Bill of Materials) est l'inventaire exhaustif des composants d'une image : paquets système, bibliothèques, versions et licences. C'est la liste d'ingrédients de votre logiciel.

# Générer un SBOM avec Syft
syft nginx:1.25.3 -o cyclonedx-json > nginx-sbom.json

# Utiliser le SBOM pour scanner avec Grype
grype sbom:nginx-sbom.json

# Générer et scanner en une commande
syft nginx:1.25.3 | grype

Voir le guide SBOM complet pour les formats SPDX/CycloneDX et l'intégration CI/CD.

4. Signer et vérifier les images avec Cosign

La signature d'images garantit l'authenticité (l'image provient bien du build attendu) et l'intégrité (elle n'a pas été modifiée). Cosign de Sigstore est l'outil standard.

Signer une image

Un guide de supply chain qui installerait son propre outil sans vérification serait contradictoire : le bloc ci-dessous épingle une version précise et contrôle l'empreinte SHA256 publiée par le projet avant de rendre le binaire exécutable. Sigstore publie ce fichier sous le nom cosign_checksums.txt dans chaque release. La commande cosign generate-key-pair réclame ensuite une passphrase : elle protège cosign.key, la seule chose à ne jamais laisser sortir de votre coffre.

# Installation Cosign : version épinglée + vérification d'empreinte
COSIGN_VERSION=3.1.3
base="https://github.com/sigstore/cosign/releases/download/v${COSIGN_VERSION}"
curl -sSfLO "${base}/cosign-linux-amd64"
curl -sSfLO "${base}/cosign_checksums.txt"
grep " cosign-linux-amd64$" cosign_checksums.txt | sha256sum -c -
chmod +x cosign-linux-amd64 && sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# Générer une paire de clés
cosign generate-key-pair
# Produit cosign.key (privée) et cosign.pub (publique)

# Signer par digest (recommandé : le tag peut être réaffecté)
cosign sign --key cosign.key registry.example.com/myapp@sha256:abc123...

# Signer par tag (acceptable mais moins robuste)
cosign sign --key cosign.key registry.example.com/myapp:1.0.0

# Vérifier la signature
cosign verify --key cosign.pub registry.example.com/myapp:1.0.0

Vérifier que la signature protège vraiment

Une signature qui se vérifie ne prouve rien : il faut voir la vérification échouer quand elle doit échouer. Les trois cas ci-dessous ont été joués sur un registre local avec cosign 3.1.3, et ils rendent trois codes de retour différents.

Avec la bonne clé, cosign détaille ce qu'il a contrôlé :

Verification for localhost:5555/lab-signe:1.0.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

Situation	Code de retour	Message
Signature valide	0	le détail des contrôles ci-dessus
Mauvaise clé publique	1	`no matching attestations: failed to verify log inclusion`
Image non signée	10	`no signatures found`

La distinction entre 1 et 10 est exploitable : une image non signée signale un oubli dans la chaîne de build, une signature qui ne correspond pas signale un problème d'identité, et ces deux incidents n'appellent pas la même réaction.

Où vit la signature

Elle n'est pas dans l'image : c'est un artefact distinct, poussé dans le même dépôt sous un tag dérivé du digest. Après signature, le dépôt contient donc deux tags :

curl -s http://localhost:5555/v2/lab-signe/tags/list

{"name":"lab-signe","tags":["sha256-7c38f24774e3cbd906d2d33c38354ccf787635581c122965132c9bd309754d4a","1.0.0"]}

Deux conséquences pratiques. Copier une image d'un registre à l'autre ne transporte pas sa signature, sauf à copier aussi cet artefact : c'est la cause la plus fréquente d'une vérification qui échoue après une migration de registre. Et le tag étant dérivé du digest, resigner une image reconstruite produit un nouvel artefact, l'ancien restant en place.

Vérification dans Kubernetes avec ImagePolicyWebhook

L'ImagePolicyWebhook est un admission controller historique, désactivé par défaut, qui délègue la décision d'autorisation à un backend externe. Il reste documenté, et utile pour comprendre les mécanismes de contrôle d'images ; mais sur les clusters récents, on rencontre plutôt des webhooks d'admission génériques (ValidatingAdmissionWebhook) ou des moteurs de policy comme Kyverno.

Un point d'architecture qui change la façon d'évaluer ce mécanisme : ImagePolicyWebhook ne décide de rien par lui-même. Il transmet la demande à un service externe joignable en TLS, qui autorise ou refuse. La sécurité réelle du dispositif est donc celle de ce backend, de sa disponibilité et des règles qu'il applique, pas celle du contrôleur Kubernetes, qui se contente de relayer.

La mise en place tient en deux fichiers. D'abord les drapeaux du kube-apiserver, à ajouter dans /etc/kubernetes/manifests/kube-apiserver.yaml sur chaque nœud du plan de contrôle : le premier active le plugin, le second indique où lire sa configuration. Une erreur ici empêche l'apiserver de redémarrer : gardez une copie du manifeste avant de le modifier.

--enable-admission-plugins=...,ImagePolicyWebhook
--admission-control-config-file=/etc/kubernetes/admission/admission-config.yaml

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: /etc/kubernetes/admission/webhook-kubeconfig.yaml
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: false  # Bloquer si le webhook est inaccessible

Un mot sur le mode de signature, puisque deux existent et que le second n'est pas toujours présenté. La signature par clé, celle que ce guide détaille, a l'avantage d'être explicite : vous voyez ce que vous générez et ce que vous vérifiez. Elle vous laisse en revanche une clé privée longue durée à protéger et à faire tourner, ce qui est précisément la matière des incidents de chaîne d'approvisionnement.

La signature keyless supprime ce problème en s'appuyant sur une identité OIDC, celle de votre exécution GitHub Actions ou GitLab CI, et sur un certificat éphémère. C'est ce qu'il faut viser pour une chaîne moderne. Gardez la signature par clé pour comprendre les mécanismes, et pour les environnements isolés où aucun fournisseur OIDC n'est joignable. Le guide Cosign détaille les deux.

5. Limiter les registres autorisés

En plus de la signature, on peut restreindre Kubernetes pour n'accepter que les images venant de registres approuvés. C'est la voie moderne et recommandée, par un moteur de policy que vous installez, Kyverno ou Gatekeeper, plus souple qu'ImagePolicyWebhook. Ni l'un ni l'autre ne fait partie de Kubernetes. Ce qui est natif, en revanche, ce sont les policies d'admission en CEL : ValidatingAdmissionPolicy, stable depuis la 1.30, et MutatingAdmissionPolicy, stable et activée par défaut depuis la 1.36.

Avec Kyverno (recommandé)

La politique ci-dessous s'écrit avec l'API policies.kyverno.io/v1, apparue en Kyverno 1.17 et stable depuis la 1.18. Deux champs portent tout le comportement : validationActions: [Deny] refuse la création au lieu de se contenter d'un rapport, et l'expression CEL parcourt tous les conteneurs du Pod avec all(...), ce qui bloque aussi un Pod dont un seul conteneur viendrait d'ailleurs. Attention, matchConstraints ne cible ici que les Pods : un Deployment passera, puis son Pod sera refusé, avec un message d'erreur qui apparaîtra dans le ReplicaSet et non dans le Deployment.

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: restrict-registries
spec:
  validationActions: [Deny]
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: >-
        object.spec.containers.all(c,
          c.image.startsWith('registry.example.com/')
        )
      message: "Seules les images de registry.example.com sont autorisées."

Avec Gatekeeper (OPA)

Gatekeeper sépare le code de la politique de son paramétrage. Le manifeste ci-dessous est une Constraint, autrement dit une instance : il suppose que le ConstraintTemplate K8sAllowedRepos, fourni par la bibliothèque officielle gatekeeper-library, a déjà été appliqué au cluster. Sans lui, l'API rejette le manifeste sur une ressource inconnue. Le champ repos fonctionne par préfixe de chaîne, et non par expression régulière : une entrée sans barre oblique finale autoriserait aussi un registre dont le nom commence pareil.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    repos:
      - "registry.example.com/"
      - "gcr.io/distroless/"

→ Voir Guide Kyverno et Guide Gatekeeper.

6. Analyser les manifestes avant de les appliquer

Scanner une image cherche des vulnérabilités connues dans des paquets. Cela ne dit rien d'un manifeste qui déclare privileged: true ou monte la racine du nœud : le paquet peut être parfaitement à jour, le déploiement reste dangereux. Le syllabus CKS nomme les deux outils de référence, Kubesec et KubeLinter.

Ils ne font pas le même travail. Le démontrer sur un manifeste volontairement faible, portant privileged: true, runAsUser: 0, une image en latest et un hostPath sur la racine, suffit à comprendre lequel choisir :

Outil	Ce qu'il rend	Sur le manifeste faible	Une fois durci
kube-linter 0.8.3	une liste de défauts nommés, avec la remédiation	8 erreurs, sortie 1	2 erreurs restantes
kubesec 2.14.2	une note chiffrée et un verdict	-30 points, sortie 2	+13, « Passed », sortie 0

kube-linter lint deployment.yaml
kubesec scan deployment.yaml

Retenez la différence d'usage : kube-linter énumère, ce qui sert à corriger ; kubesec note, ce qui sert à poser un seuil en intégration continue.

Deux outils voisins font le même travail sous un autre angle : kube-score, pensé pour l'intégration continue, et Polaris, qui surveille en continu un cluster vivant.

7. Vérifier les binaires de la plateforme

La chaîne d'approvisionnement ne s'arrête pas aux images : le kubectl que vous installez sur un poste d'administration en fait partie. Le syllabus CKS le demande explicitement, « vérifier les binaires de la plateforme avant déploiement ».

Kubernetes publie la somme de contrôle de chaque binaire à côté du binaire :

VER=v1.37.0
curl -LO "https://dl.k8s.io/release/${VER}/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/${VER}/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check

kubectl: OK

C'est le code de sortie qui compte, pas le message. Mesuré sur le binaire 1.37.0 : 0 quand le fichier est intact, 1 dès qu'il est altéré, et un seul octet ajouté à un binaire de 61 Mo suffit à le faire basculer. Dans un script, testez ce code plutôt que de chercher le mot OK dans la sortie.

Workflow supply chain complet

En production et pour le CKS, voici le cycle recommandé :

Build avec une image de base minimale (distroless/alpine) et build multi-stage
Scanner l'image avant le push : grype myapp:1.0.0 --fail-on high
Générer le SBOM et l'attacher à l'image : syft myapp:1.0.0 -o cyclonedx-json
Épingler par digest : référencer l'image par son SHA256 pour garantir l'immuabilité
Signer par digest : cosign sign --key cosign.key registry/myapp@sha256:abc123...
Pousser vers un dépôt d'artefacts privé et contrôlé, un registre interne approuvé
Vérifier à l'admission : politique Kyverno/Gatekeeper ou ImagePolicyWebhook

Dépannage

Les quatre situations ci-dessous ont un point commun : le cluster se comporte exactement comme il a été configuré, et c'est la configuration qui pose problème. Les deux premières lignes décrivent des blocages visibles ; les deux dernières sont plus pernicieuses, car rien n'échoue : le pipeline reste vert alors que le contrôle attendu n'a jamais eu lieu. Vérifiez celles-là en priorité si votre chaîne semble « trop » silencieuse.

Symptôme	Cause probable	Solution
Pod bloqué par ImagePolicyWebhook	Webhook inaccessible avec `defaultAllow: false`	Vérifier la disponibilité du webhook
Signature non vérifiée	Mauvaise clé publique ou image re-taguée	Re-signer ou utiliser le digest SHA256
CVE CRITICAL non bloquantes	Seuil pas configuré	Ajouter `--fail-on critical` dans le CI/CD
Images `latest` en production	Convention de tag permissive	Politique Kyverno pour interdire `latest`

Testez vos connaissances

Les sept questions ci-dessous sont tirées de la banque CKS et ne couvrent que le domaine supply chain. Elles insistent volontairement sur les distinctions que l'examen exploite : scan contre signature, tag contre digest, et contrôle d'admission contre contrôle en CI.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

8 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

À retenir

Images minimales : distroless > alpine > ubuntu, build multi-stage ; scratch réduit l'empreinte base mais la sécurité dépend du binaire embarqué
Scanner avant push : Grype (mon choix prod, EPSS, KEV, OpenVEX) ou Trivy (culture écosystème)
Le scan ne suffit pas : une image sans CVE peut rester malveillante ou compromise, compléter avec signature et admission
SBOM : inventaire exhaustif avec Syft, re-scannable séparément sans rebuild
Signature : Cosign, de préférence par digest et keyless en production
Contrôle admission : Kyverno/Gatekeeper comme voie moderne ; ImagePolicyWebhook comme mécanisme historique
Registres : restreindre aux sources de confiance, préférer un dépôt d'artefacts interne
CI/CD : évitez les installations d'outils à la volée depuis Internet en production

Mettre en pratique

Trois maillons de la chaîne, chacun validé par un refus. Vous signez une image avec cosign et prouvez que la même clé refuse l'autre, corrigez les cinq constats d'une analyse statique de Dockerfile sans changer ce que fait l'image, et épinglez un Deployment sur le digest réellement résolu par le runtime, pas sur un digest qui y ressemble.

Épingler une image par son digest, et prouver que le tag ne suffit pas

$ dsoxlab run cks-image-pinned-digest

Environnement : VM·Durée : ~15 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cks-image-pinned-digest
dsoxlab check cks-image-pinned-digest

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Corriger un Dockerfile que l'analyse statique refuse, sans changer l'application

$ dsoxlab run cks-dockerfile-static-analysis

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cks-dockerfile-static-analysis
dsoxlab check cks-dockerfile-static-analysis

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Signer une image, et prouver la signature en faisant refuser une autre

$ dsoxlab run cks-cosign-verify-image

Environnement : VM·Durée : ~30 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cks-cosign-verify-image
dsoxlab check cks-cosign-verify-image

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

Audit Logs : La trace des déploiements d'images, utile dès qu'un artefact se révèle compromis.
Falco : La détection à l'exécution quand une image malveillante a franchi les contrôles amont.

Supply Chain Security Kubernetes - Sécuriser la chaîne d'approvisionnement

Prérequis

Qu'est-ce que la supply chain d'une image ?

1. Minimiser l'empreinte des images de base

Pourquoi les images légères réduisent la surface d'attaque

Build multi-stage : compiler sans embarquer les outils

Bonnes pratiques images

2. Scanner les vulnérabilités

L'incident Trivy de mars 2026, et ce qu'il change ici

Scanner avec Grype, mon choix principal

Scanner avec Trivy, culture écosystème

3. Générer et exploiter un SBOM

4. Signer et vérifier les images avec Cosign

Signer une image

Vérifier que la signature protège vraiment

Où vit la signature

Vérification dans Kubernetes avec ImagePolicyWebhook

5. Limiter les registres autorisés

Avec Kyverno (recommandé)

Avec Gatekeeper (OPA)

6. Analyser les manifestes avant de les appliquer

7. Vérifier les binaires de la plateforme

Workflow supply chain complet

Dépannage

Testez vos connaissances

Contrôle de connaissances

Informations

Vérification

Profil de compétences

Quoi faire maintenant

À retenir

Mettre en pratique

Pour aller plus loin