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

Lab vs production

Pour un lab ou un poste de test, curl | sh est pratique. En production ou en CI, préférez un binaire versionné, vérifié et signé, ou une image de build interne contenant déjà l’outil approuvé.

# Linux (lab / poste de test)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
grype version

Commandes essentielles

# 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

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

# 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

# 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

# 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

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

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

.github/workflows/scan.yml

name: scan-image
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scanner avec Grype
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
          grype myapp:${{ github.sha }} --fail-on critical

GitLab CI

.gitlab-ci.yml

scan:
  stage: test
  image: docker:24
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - |
      curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
      grype $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --fail-on critical

Dépannage

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

.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

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

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 →