Scanner les images Kubernetes - Grype, Trivy et CVE

Scanner les images conteneurs avant de les déployer est un contrôle indispensable, mais ce n'est qu'un maillon de la supply chain security. Un scanner compare les composants d'une image avec des bases de données de CVE pour identifier les failles connues, mais il ne prouve pas l'intégrité, la provenance ou la conformité de l'image.

Ce guide poursuit deux objectifs : montrer les commandes et concepts autour du scan de vulnérabilités dans l'écosystème Kubernetes, et expliquer pourquoi je privilégie Grype comme scanner principal en production depuis l'incident majeur ayant touché l'écosystème Trivy en mars 2026. Trivy reste néanmoins très présent dans l'écosystème et dans les préparations à l'examen CKS.

Incident supply chain Trivy, position retenue dans ce guide

En mars 2026, l'écosystème Trivy a subi une compromission majeure : binaire malveillant, tags GitHub Actions réécrits en masse, images DockerHub compromises, le tout via des identifiants volés. Aqua a publié les détails et les remédiations.

Position retenue dans ce guide : je ne recommande plus Trivy comme scanner principal en production.

Je conserve toutefois ses commandes pour la culture générale, pour lire des pipelines existants et pour la préparation CKS. Voir le guide Trivy et Grype pour les détails.

Prérequis

• Docker ou containerd installé
• Accès à des images à scanner
• Bases en sécurité : notions de CVE, CVSS, EPSS (→ guide CVE)

Comprendre une CVE

Avant de scanner, il faut savoir lire les résultats. Une CVE (Common Vulnerability and Exposure) est un identifiant unique pour une faille de sécurité connue. Format : CVE-ANNÉE-NUMÉRO.

Les scores de sévérité CVSS v3 :

Score	Sévérité	Action recommandée
9.0 – 10.0	CRITICAL	Corriger immédiatement, bloquer le déploiement
7.0 – 8.9	HIGH	Traiter en priorité, dans les 48h
4.0 – 6.9	MEDIUM	Planifier dans le sprint suivant
0.1 – 3.9	LOW	Backlog, corriger lors des mises à jour régulières

Glissez pour voir

EPSS : un signal de priorisation

Le score EPSS (Exploit Prediction Scoring System) estime la probabilité qu'une CVE soit exploitée dans les 30 prochains jours. Il aide à prioriser selon la probabilité d'exploitation réelle, mais il ne remplace pas la sévérité CVSS. Il faut croiser les deux, ainsi que le contexte réel d'exposition. Grype intègre EPSS, KEV et OpenVEX dans son approche de priorisation par le risque.

Grype, mon choix principal pour le scan de vulnérabilités d'images

Grype est développé par Anchore. Je le privilégie pour le scan d'images et de SBOM, notamment pour son intégration avec Syft et sa prise en compte d'EPSS, de KEV et d'OpenVEX.

Installation

Installez Grype depuis un binaire officiel vérifié par empreinte SHA256, jamais par un script curl | sh : récupérez l'archive et les checksums des GitHub Releases, contrôlez l'empreinte, puis extrayez le binaire.

GRYPE_VERSION=0.111.0
cd /tmp
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
grype version

Commandes essentielles

Grype prend en argument une référence d'image, un chemin local ou un SBOM, et choisit sa source d'analyse selon le préfixe utilisé. Sans option, il affiche toutes les vulnérabilités trouvées et se termine avec un code de retour 0 : c'est --fail-on qui transforme le scan en verrou de pipeline.

# Scanner une image depuis une registry
grype nginx:1.25.3

# Ne montrer que les CVE ayant un fix disponible
grype nginx:1.25.3 --only-fixed

# Faire échouer si CVE CRITICAL détectée (CI/CD)
grype nginx:1.25.3 --fail-on critical

# Sortie JSON pour parsing
grype nginx:1.25.3 -o json > report.json

# Depuis un SBOM Syft
grype sbom:/path/to/sbom.json

Exemple de sortie

La sortie par défaut est un tableau, une ligne par couple paquet/vulnérabilité. Un même identifiant peut donc apparaître plusieurs fois s'il touche plusieurs paquets de l'image, comme CVE-2024-0727 ci-dessous sur libssl3 et openssl.

NAME          INSTALLED  FIXED-IN   TYPE  VULNERABILITY  SEVERITY
libssl3       3.0.11     3.0.13     deb   CVE-2024-0727  MEDIUM
openssl       3.0.11     3.0.13     deb   CVE-2024-0727  MEDIUM
expat         2.5.0      (none)     deb   CVE-2023-52425 MEDIUM
zlib1g        1:1.2.13   (none)     deb   CVE-2023-45853 MEDIUM

La colonne FIXED-IN est clé : si elle est vide, aucun correctif n'est actuellement référencé pour ce package dans les sources du scanner. Il faut alors évaluer les alternatives : mise à jour applicative, changement d'image de base, suppression du composant, ou acceptation temporaire du risque documentée.

Workflow SBOM + Grype

Séparer l'inventaire de l'analyse change la façon de travailler : Syft produit la liste des composants une fois pour toutes, Grype la confronte aux bases de vulnérabilités du jour. L'image n'a plus besoin d'exister ni d'être téléchargée pour être réévaluée six mois plus tard.

# 1. Générer l'inventaire (SBOM)
syft nginx:1.25.3 -o cyclonedx-json > sbom.json

# 2. Scanner le SBOM pour les CVE
grype sbom:sbom.json --fail-on high

# Avantage : le SBOM peut être archivé et re-scanné plus tard
# quand de nouvelles CVE sont publiées sans rebuilder l'image

→ Voir le guide SBOM complet et le guide Syft.

Trivy, outil très présent dans l'écosystème, que je n'intègre plus comme scanner principal

Trivy d'Aqua Security est un outil très fréquent dans les préparations CKS et dans la littérature autour de l'examen. Je conserve ses commandes pour la culture générale et pour lire des pipelines existants. En revanche, pour un nouveau pipeline de production, je préfère désormais Grype pour le scan de vulnérabilités d'images.

Installation

L'installation passe par le dépôt APT signé d'Aqua : la clé publique est convertie en trousseau binaire dans /usr/share/keyrings/, puis référencée par signed-by= dans la source. Ce mécanisme limite la confiance accordée à cette clé au seul dépôt Trivy, contrairement à l'ancien apt-key add qui l'autorisait pour tous les dépôts du système.

# Debian/Ubuntu
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install trivy

Commandes essentielles CKS

Trivy s'organise par sous-commandes selon la cible : image pour un conteneur, fs pour un répertoire de code, config pour un manifeste. L'examen CKS attend surtout la maîtrise du filtrage par sévérité et de --exit-code, qui décide si le scan bloque ou non la chaîne.

# Scanner une image
trivy image nginx:1.25.3

# Ignorer les CVE sans fix disponible
trivy image --ignore-unfixed nginx:1.25.3

# Filtrer par sévérité
trivy image --severity CRITICAL,HIGH nginx:1.25.3

# Code de sortie 1 si CVE critique (CI/CD)
trivy image --exit-code 1 --severity CRITICAL nginx:1.25.3

# Générer un SBOM CycloneDX
trivy image --format cyclonedx nginx:1.25.3 > sbom.json

# Scanner le filesystem local (dépendances applicatives)
trivy fs --scanners vuln .

# Scanner un manifest Kubernetes
trivy config deployment.yaml

Comparer Grype vs Trivy

Les deux outils font le même travail de base, la comparaison porte donc sur leur périmètre et sur leur façon de hiérarchiser les résultats. Trivy couvre plus de types de cibles (configuration, IaC, cluster), Grype se concentre sur les images et les SBOM en poussant plus loin la priorisation par le risque réel d'exploitation. Le tableau ci-dessous sert à trancher selon ce que vous avez à couvrir, pas à désigner un vainqueur absolu.

Critère	Grype	Trivy
Cible principale	Images, file systems, SBOM	Images + config/IaC + Kubernetes + SBOM
EPSS / priorisation	Fort accent : EPSS, KEV, risk score, OpenVEX	Couverture plus large, priorisation moins mise en avant
SBOM	Scan de SBOM existants	Génération et exploitation natifs
Kubernetes natif	Pas d'operator officiel équivalent	Trivy Operator
Position dans ce guide	Mon choix principal pour la prod	Conservé pour culture écosystème / préparation

Glissez pour voir

Trivy Operator, Scan continu dans Kubernetes

Le Trivy Operator installe un CRD dans le cluster et scanne automatiquement toutes les images à intervalle régulier. Les résultats sont stockés comme ressources Kubernetes.

# Installation via Helm
helm install trivy-operator aquasecurity/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set trivy.ignoreUnfixed=true

# Voir les rapports de vulnérabilités
kubectl get vulnerabilityreports -A

# Détail d'un rapport
kubectl describe vulnerabilityreport <name> -n <namespace>

Trivy Operator et l'incident de mars 2026

Je présente Trivy Operator parce qu'il reste une référence connue pour le scan continu dans Kubernetes. Si vous ne souhaitez plus introduire Trivy dans le cluster après l'incident, considérez cette section comme culture produit plutôt que comme recommandation de déploiement immédiat.

Intégration CI/CD

Un scan n'a d'effet que s'il peut arrêter la chaîne. Le principe est identique sur toutes les plateformes : construire l'image, la scanner, et laisser le code de retour non nul du scanner faire échouer le job. Reste à décider du seuil de blocage, sachant qu'un --fail-on critical trop strict sur une image de base ancienne bloque tout le monde dès le premier jour.

Téléchargement à la volée en CI/CD

Les exemples suivants montrent la mécanique minimale de scan. En production, évitez de télécharger les scanners depuis Internet à chaque exécution. Préférez une image de job interne, validée et versionnée, avec le scanner et ses bases déjà intégrés.

GitHub Actions

L'action de checkout est épinglée par SHA et non par tag, seule protection contre la réécriture d'un tag Git dans le dépôt de l'action, exactement le mode opératoire observé lors de l'incident de mars 2026. Le permissions: {} du workflow retire tout droit par défaut au GITHUB_TOKEN, et le job ne reprend que la lecture du dépôt.

.github/workflows/scan.yml

name: scan-image
on: [push]

permissions: {}

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scanner avec Grype
        run: |
          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
          grype myapp:${{ github.sha }} --fail-on critical

GitLab CI

Le job télécharge l'archive Grype et son fichier de sommes, vérifie l'empreinte avec sha256sum -c avant d'extraire quoi que ce soit. Cette séquence est le strict minimum pour un binaire récupéré depuis Internet, et elle échoue bruyamment si l'archive a été altérée.

.gitlab-ci.yml

scan:
  stage: test
  image: docker:24@sha256:9b17a9f25adf17b88d0a013b4f00160754adf4b07ccbe9986664a49886c2c98e
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - apk add --no-cache curl tar
    - |
      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 -
      tar -C /usr/local/bin -xzf "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" grype
      grype $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --fail-on critical

Dépannage

La difficulté du scan n'est presque jamais technique : elle tient au volume de résultats et à leur interprétation. Un premier scan sur une image applicative remonte couramment plusieurs centaines de lignes, dont une majorité sans correctif disponible ni exploitabilité dans votre contexte. Les symptômes ci-dessous couvrent les cas rencontrés lors de la mise en place, du bruit initial aux divergences entre outils.

Symptôme	Cause probable	Solution
Trop de CVE MEDIUM/LOW	Pas de filtrage	Utiliser --severity HIGH,CRITICAL ou --fail-on high
CVE sans FIXED-IN	Pas de correctif référencé	Évaluer alternatives : MAJ applicative, changement de base, suppression du composant
Faux positifs répétés	CVE non applicable à votre contexte	Créer .grype.yaml avec ignore: ou formaliser avec OpenVEX
Trivy DB outdated	Base locale expirée	trivy image --download-db-only
Scan lent en CI/CD	Téléchargement de la DB à chaque run	Mettre la DB en cache dans le pipeline
Image distroless / Wolfi	Moins de paquets OS	Scanner quand même, bibliothèques applicatives restent visibles
Résultats différents entre deux scanners	Sources et règles de matching différentes	Normal, définissez un scanner de référence et documentez les écarts
CVE non exploitable dans votre contexte	Faux positif contextuel	Formaliser l'acceptation de risque avec OpenVEX ou .grype.yaml

Glissez pour voir

Divergence entre scanners

Deux scanners peuvent remonter des résultats différents sur la même image. Cela ne signifie pas qu'un outil se trompe : les bases de données, les règles de matching et les métadonnées de packages ne sont pas identiques. En production, définissez un scanner de référence et documentez votre politique d'exception.

Ignorer les faux positifs avec Grype

Le fichier .grype.yaml placé à la racine du projet retire des résultats les vulnérabilités listées sous ignore:. Chaque exception doit porter une raison écrite : une exclusion sans justification devient invérifiable dès que son auteur quitte l'équipe, et personne n'ose plus la supprimer.

.grype.yaml

ignore:
  # CVE ne s'applique pas à notre build (Java non utilisé)
  - vulnerability: CVE-2023-XXXXX
    reason: "Not applicable - Java runtime not present"
  # Toutes les CVE LOW pour ce package
  - package:
      name: libcurl
    fix-state: not-fixed
    severity: low

Limites du scan de vulnérabilités

Un scanner répond à une seule question : les composants présents dans cette image figurent-ils dans une base de vulnérabilités connues. Il ne dit rien de ce que fait le code, ni de qui l'a construit, ni de ce que l'image exécutera une fois déployée. Confondre l'absence de CVE critiques avec la sûreté de l'image est l'erreur la plus fréquente, et l'incident Trivy de mars 2026 en donne un exemple direct.

Le scan ne garantit pas l'intégrité de l'image

Une image peut être exempte de CVE critiques connues et tout de même être malveillante, compromise ou non conforme. Le scan de vulnérabilités ne remplace pas :

• la signature d'image (Cosign) pour vérifier l'intégrité
• la provenance (SLSA, attestations) pour vérifier l'origine du build
• la politique d'admission pour contrôler ce qui peut être déployé
• la surveillance runtime pour détecter les comportements anormaux en production

C'est précisément ce que couvre la supply chain security au sens large dans le CKS.

Testez vos Connaissances

Les questions portent sur ce qui vient d'être expliqué : lecture d'un résultat de scan, priorisation CVSS et EPSS, et périmètre exact de ce qu'un scanner prouve.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 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

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Grype : mon choix principal pour scanner images et SBOM en production, avec focus sur EPSS, KEV et OpenVEX
• Trivy : outil toujours très connu et fonctionnellement large, que je ne retiens plus comme scanner principal après l'incident de mars 2026
• Un scan d'image ne suffit pas : compléter avec signature, provenance, politiques d'admission et contrôles runtime
• EPSS + CVSS : croiser les deux signaux pour prioriser, l'EPSS seul ne suffit pas
• En CI/CD : évitez de télécharger les scanners à la volée ; préférez des images de job internes et figées
• FIXED-IN vide : pas de correctif référencé à cet instant, évaluer les alternatives plutôt qu'attendre
• SBOM : générer avec Syft, scanner avec Grype = séparation claire des responsabilités

Prochaines étapes

Supply Chain Security Kubernetes Vue d'ensemble : images minimales, signature, SBOM, contrôle des registries

SBOM : Software Bill of Materials Générer, exploiter et distribuer un SBOM avec Syft

Grype, Guide complet Scanner de vulnérabilités recommandé avec EPSS natif

Comprendre les CVE, CVSS et EPSS Interpréter et prioriser les résultats de scan

×

📖 Voir la documentation →