Trivy : Scanner vos Conteneurs Docker en 13 Étapes [2026]

Une image Docker mise en production sans scan préalable, c’est une porte ouverte que personne n’a pensé à vérifier. En 2026, avec la montée en puissance du Cyber Resilience Act et de NIS2, les équipes DevSecOps françaises n’ont plus le choix : chaque image doit être analysée, chaque composant tracé, chaque signature vérifiée avant déploiement. Ce tutoriel vous guide, étape par étape, dans l’installation de Trivy, le scanner de vulnérabilités open source d’Aqua Security, jusqu’à la mise en place d’un pipeline complet incluant Grype et la signature Cosign/Sigstore. Comptez environ 60 minutes pour suivre l’ensemble des 13 étapes.

Pourquoi scanner les images de conteneurs en 2026

Un conteneur Docker n’est jamais une boîte vide. Il embarque un système de base (Debian, Alpine, Ubuntu…), des bibliothèques système, un runtime applicatif et, souvent, des dizaines de dépendances tierces récupérées via npm, pip ou Maven. Chacun de ces composants peut porter une faille connue, référencée dans une base CVE, et personne ne le remarque tant que l’image tourne sans incident visible. Le scan de vulnérabilités change cette donne : il inspecte le contenu réel de l’image, couche par couche, et compare chaque paquet à des bases de données de sécurité maintenues par les distributions elles-mêmes (Alpine SecDB, Debian Security Tracker, Red Hat, Ubuntu, Amazon Linux, Oracle Linux).

Trivy, développé par Aqua Security, s’est imposé comme l’outil de référence pour cette tâche. Il scanne des images de conteneurs, des clusters Kubernetes, des dépôts de code, des artefacts binaires et des infrastructures cloud, tout en générant des nomenclatures logicielles (SBOM). Son concurrent direct, Grype, développé par Anchore, adopte une approche container-native et lit directement les daemons Docker, les registres et les archives OCI. Les deux outils sont gratuits, open source, et se complètent plutôt qu’ils ne s’excluent : beaucoup d’équipes les font tourner en parallèle pour croiser les résultats et réduire les faux négatifs.

Ce guide part du principe que vous gérez déjà des images Docker ou un cluster Kubernetes en production ou en pré-production. L’objectif n’est pas de vous apprendre Docker, mais de vous montrer comment intégrer un contrôle de sécurité systématique dans votre flux de travail, du poste du développeur jusqu’au pipeline CI/CD. Si vous travaillez plus largement sur votre infrastructure cloud, ce même réflexe de vérification s’applique à chaque couche, pas seulement aux conteneurs.

NIS2 et Cyber Resilience Act : le contexte qui pousse au scan

Deux textes européens changent la donne pour les équipes qui publient du logiciel. La directive NIS2 étend les obligations de gestion des risques cyber à des milliers d’entités françaises, y compris des PME sous-traitantes de secteurs critiques. Le Cyber Resilience Act, lui, impose aux fabricants de produits numériques une gestion active des vulnérabilités pendant tout le cycle de vie du logiciel, avec une attention particulière portée aux composants open source intégrés dans les produits commercialisés en Europe.

Concrètement, ces textes poussent vers deux pratiques que Trivy et Grype couvrent directement : la génération de SBOM (la liste exhaustive des composants d’un logiciel, avec leurs versions) et la traçabilité des CVE détectées dans ces composants. Sans inventaire précis de ce que contient une image, impossible de démontrer une gestion de vulnérabilités sérieuse face à un audit ou un régulateur. Le format CycloneDX, standardisé par l’OWASP, s’est imposé comme le format SBOM le plus utilisé dans l’écosystème cloud-native, et Trivy le prend en charge nativement depuis sa branche 0.71.x.

Signer une image avec Cosign complète ce dispositif. La signature garantit qu’une image déployée en production est bien celle qui a été scannée et validée, sans altération entre le build et le déploiement. Ce trio scan, SBOM et signature forme aujourd’hui la base d’une chaîne d’approvisionnement logicielle défendable devant un auditeur, un client ou une autorité de contrôle.

Trivy, Grype, Docker Scout : comparatif des scanners

Trois outils dominent le marché du scan de vulnérabilités pour conteneurs. Trivy et Grype sont open source et gratuits, tandis que Docker Scout est intégré à l’écosystème Docker Desktop et Docker Hub avec un modèle freemium. Le tableau ci-dessous résume leurs différences principales, utiles pour choisir l’outil adapté à votre contexte.

Outil	Éditeur	Licence	Cible principale	Génération SBOM	Intégration CI/CD
Trivy	Aqua Security	Apache 2.0 (open source)	Images, Kubernetes, IaC, dépôts de code, cloud	Oui, CycloneDX et SPDX	Native (GitHub Actions, GitLab CI)
Grype	Anchore	Apache 2.0 (open source)	Images de conteneurs et systèmes de fichiers	Consomme les SBOM générés par Syft	Sortie SARIF pour GitHub code scanning
Docker Scout	Docker Inc.	Propriétaire, offre gratuite limitée	Images publiées sur Docker Hub	Oui, intégré à Docker Desktop	Intégration Docker Hub et Docker Desktop

Trivy se distingue par sa polyvalence : un seul binaire couvre le scan d’image, l’audit de cluster Kubernetes avec trivy k8s, l’analyse de fichiers Terraform ou Kubernetes YAML avec trivy config, et la génération de SBOM. Grype, plus spécialisé, brille par la richesse de ses flux de vulnérabilités par distribution et par sa capacité à lire directement les daemons Docker sans étape intermédiaire. Beaucoup d’équipes utilisent Trivy comme scanner principal en CI/CD et ajoutent Grype comme second avis avant une mise en production sensible, une pratique qui réduit le risque de faux négatif propre à tout scanner basé sur une seule base de données.

Pourquoi ne pas se limiter à Docker Scout

Docker Scout a un avantage évident pour une petite équipe déjà installée dans l’écosystème Docker Hub : il s’active en un clic depuis Docker Desktop, sans binaire supplémentaire à installer. Le problème apparaît dès que vous sortez de ce périmètre. Docker Scout ne scanne pas nativement un cluster Kubernetes complet, ne génère pas de SBOM aussi riche que Trivy et reste, sur son offre gratuite, limité en nombre d’images suivies. Pour une organisation qui doit démontrer une gestion de vulnérabilités couvrant Kubernetes, l’infrastructure cloud et le code source, Trivy ou Grype couvrent un périmètre nettement plus large sans coût de licence.

Prérequis : versions et outils nécessaires

Avant de commencer, assurez-vous de disposer des éléments suivants. Ce tutoriel a été testé sur Linux (Ubuntu 24.04) et macOS, avec des équivalents indiqués pour Windows.

• Docker Engine ou Docker Desktop en version récente, avec le démon actif
• Un cluster Kubernetes accessible via kubectl (Minikube convient pour ce tutoriel, voir notre tutoriel de création de cluster Kubernetes avec Minikube)
• Trivy en dernière version stable (la série 0.71.x/0.73.x publiée entre juin et août 2026 au moment de la rédaction)
• Grype en dernière version stable (série 0.117.x/0.118.x, publiée mi-août 2026)
• Cosign, l’outil de signature du projet Sigstore, en dernière version stable
• Un compte GitHub ou GitLab si vous souhaitez suivre la partie intégration CI/CD
• Accès en ligne de commande (bash ou zsh) avec les droits d’installation de paquets

Un point de vigilance avant de vous lancer : Trivy publie des versions à un rythme mensuel, et Grype suit une cadence encore plus rapprochée. Installez toujours la dernière version disponible plutôt que de figer un numéro précis, car les bases de vulnérabilités évoluent vite et une version ancienne peut manquer des CVE récentes.

Étapes 1 à 3 : installer Trivy sur Linux, macOS et Windows

Étape 1 : installation via le script officiel. Sur Linux et macOS, la méthode la plus rapide passe par le script d’installation officiel d’Aqua Security, qui télécharge le binaire correspondant à votre architecture.

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Vérifier l'installation
trivy --version

Étape 2 : installation via un gestionnaire de paquets. Sur macOS avec Homebrew, ou sur Ubuntu/Debian avec le dépôt APT officiel, préférez cette méthode pour bénéficier des mises à jour automatiques.

# macOS avec Homebrew
brew install trivy

# Ubuntu/Debian avec le dépôt APT officiel
sudo apt-get install -y wget gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo gpg --dearmor -o /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install -y trivy

Un incident survenu en avril 2026, lors de la sortie de la version 0.70.0, a forcé Aqua Security à faire tourner les clés de signature GPG des dépôts deb/rpm après un problème de sécurité interne. Si vous aviez configuré ce dépôt avant cette date, vous devez réimporter la nouvelle clé publique avant toute mise à jour, sous peine d’obtenir une erreur de vérification de signature au moment du apt update.

Étape 3 : télécharger la base de données de vulnérabilités. Trivy a besoin d’une base de données locale, mise à jour régulièrement, pour comparer les paquets détectés aux CVE connues. Le premier scan la télécharge automatiquement, mais vous pouvez la précharger pour accélérer les scans suivants.

trivy image --download-db-only

# Vérifier l'âge de la base locale
trivy image --cache-dir ~/.cache/trivy --list-all-pkgs alpine:3.20 2>&1 | head -n 5

Étapes 4 et 5 : scanner votre première image Docker

Étape 4 : lancer un scan simple. Choisissez une image que vous utilisez en production, ou testez sur une image publique pour vous familiariser avec la sortie. La commande de base scanne toutes les couches et liste les vulnérabilités trouvées, classées par sévérité.

trivy image mon-registre.local/mon-app:2026.08

Voici un exemple de sortie typique, tronquée pour la lisibilité :

mon-registre.local/mon-app:2026.08 (debian 12.5)
==================================================
Total: 14 (UNKNOWN: 0, LOW: 3, MEDIUM: 6, HIGH: 4, CRITICAL: 1)

┌───────────┬────────────────┬──────────┬──────────┬───────────────────┬───────────────┐
│  Library  │ Vulnerability  │ Severity │  Status  │ Installed Version │ Fixed Version │
├───────────┼────────────────┼──────────┼──────────┼───────────────────┼───────────────┤
│ libssl3   │ CVE-2026-XXXXX │ CRITICAL │ fixed    │ 3.0.13-1          │ 3.0.15-1      │
│ zlib1g    │ CVE-2025-YYYYY │ HIGH     │ fixed    │ 1:1.3.dfsg-3      │ 1:1.3.dfsg-4  │
└───────────┴────────────────┴──────────┴──────────┴───────────────────┴───────────────┘

Étape 5 : filtrer par sévérité et changer le format de sortie. En pratique, vous ne voulez pas noyer votre équipe sous des dizaines de vulnérabilités mineures. Trivy permet de filtrer par niveau de sévérité et de choisir un format exploitable par d’autres outils (JSON, SARIF, table).

# N'afficher que les failles critiques et élevées
trivy image --severity CRITICAL,HIGH mon-registre.local/mon-app:2026.08

# Sortie au format JSON pour traitement automatisé
trivy image --format json --output resultats-scan.json mon-registre.local/mon-app:2026.08

# Faire échouer le build si une faille critique est trouvée (utile en CI/CD)
trivy image --exit-code 1 --severity CRITICAL mon-registre.local/mon-app:2026.08

Le paramètre --exit-code 1 transforme Trivy en porte automatique : si une vulnérabilité critique est détectée, la commande retourne un code d’erreur qui peut interrompre votre pipeline avant le déploiement. C’est le mécanisme central pour transformer un scan manuel en contrôle systématique.

Étapes 6 et 7 : auditer un cluster Kubernetes et vos manifests

Étape 6 : scanner un cluster Kubernetes en cours d’exécution. Trivy ne se limite pas aux images statiques. La sous-commande trivy k8s inspecte directement les charges de travail d’un cluster, en s’appuyant sur votre configuration kubectl existante.

# Scanner tout le cluster (namespace courant)
trivy k8s --report summary cluster

# Scanner un namespace précis
trivy k8s --namespace production --report all deployment/mon-api

Cette commande remonte non seulement les vulnérabilités des images utilisées par vos pods, mais aussi les mauvaises configurations : conteneurs lancés en root, absence de limites de ressources, ports exposés sans nécessité. Si vous débutez avec Kubernetes, notre guide pour durcir un cluster Kubernetes face aux CVE de containerd complète bien cette étape.

Étape 7 : auditer les fichiers de configuration avant déploiement. Plutôt que d’attendre qu’une charge de travail tourne pour la scanner, Trivy peut analyser vos Dockerfiles et manifests Kubernetes directement dans votre dépôt de code, avant même le build.

trivy config ./Dockerfile
trivy config ./k8s/manifests/

Cette analyse statique détecte, par exemple, un Dockerfile qui installe des paquets sans nettoyer le cache APT ensuite, ou un manifest Kubernetes qui ne fixe pas de securityContext. Corriger ces points en amont coûte infiniment moins cher que de les découvrir en production.

Étape 8 : générer un SBOM au format CycloneDX

La branche 0.71.x de Trivy a ajouté le support de CycloneDX 1.6, la version la plus récente de ce standard porté par l’OWASP. Un SBOM (Software Bill of Materials) liste tous les composants d’une image avec leurs versions exactes, un peu comme une étiquette d’ingrédients pour un logiciel. C’est l’artefact que les auditeurs et les équipes conformité réclament de plus en plus souvent dans le cadre du Cyber Resilience Act.

# Générer un SBOM CycloneDX
trivy image --format cyclonedx --output sbom.cdx.json mon-registre.local/mon-app:2026.08

# Générer un SBOM au format SPDX (alternative standardisée)
trivy image --format spdx-json --output sbom.spdx.json mon-registre.local/mon-app:2026.08

# Réutiliser un SBOM existant pour scanner les vulnérabilités sans re-scanner l'image
trivy sbom sbom.cdx.json

Conservez ce fichier SBOM à côté de chaque version publiée de votre image, idéalement dans le même registre ou dans un stockage versionné. En cas d’incident touchant une bibliothèque tierce, un SBOM à jour permet de savoir en quelques secondes si vos images sont concernées, sans relancer un scan complet.

Étape 9 : croiser les résultats avec Grype

Aucun scanner ne couvre 100 % des cas. Grype, développé par Anchore, s’appuie sur des flux de vulnérabilités légèrement différents de ceux de Trivy et peut remonter des failles que ce dernier a manquées, ou inversement. Faire tourner les deux outils sur les images sensibles constitue une pratique de défense en profondeur simple à mettre en place.

# Installer Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Vérifier l'installation et la base de données
grype version
grype db status

# Scanner la même image
grype mon-registre.local/mon-app:2026.08

Grype lit nativement les images depuis le daemon Docker, les registres distants et les archives OCI, sans passer par une étape d’export intermédiaire. Il s’appuie en interne sur Syft, l’outil de catalogage d’Anchore, pour identifier précisément chaque paquet avant de le confronter à sa base de vulnérabilités. Pour réduire le bruit dans vos pipelines, Grype propose aussi un mécanisme de règles d’ignore, utile quand un même correctif apparaît sous plusieurs identifiants sur des images Alpine.

Étapes 10 et 11 : signer et vérifier vos images avec Cosign

Étape 10 : installer Cosign et générer une paire de clés. Un scan propre ne garantit rien si l’image peut être remplacée entre le moment du scan et le déploiement. Cosign, l’outil de signature du projet Sigstore, résout ce problème en attachant une signature cryptographique vérifiable à chaque image.

# Installer Cosign (Linux/macOS via script officiel ou brew)
brew install cosign

# Générer une paire de clés (une clé privée protégée par mot de passe, une clé publique)
cosign generate-key-pair

Étape 11 : signer l’image après un scan réussi et vérifier la signature avant déploiement. L’ordre compte : on scanne d’abord, on signe seulement si le scan passe, puis on vérifie systématiquement la signature au moment du déploiement.

# Signer l'image après validation du scan
cosign sign --key cosign.key mon-registre.local/mon-app:2026.08

# Vérifier la signature avant tout déploiement
cosign verify --key cosign.pub mon-registre.local/mon-app:2026.08

Pour aller plus loin, Cosign prend aussi en charge un mode sans clé, basé sur une identité OIDC (compte GitHub ou Google par exemple) et un registre de transparence public. Cette approche évite la gestion manuelle de clés privées, un point sensible pour les équipes qui manquent encore de maturité en gestion de secrets. Notre article sur la signature numérique obligatoire sous le Cyber Resilience Act détaille les implications réglementaires de cette pratique.

Étapes 12 et 13 : intégrer le scan dans votre pipeline CI/CD

Étape 12 : ajouter Trivy à un workflow GitHub Actions. L’action officielle trivy-action simplifie l’intégration et peut faire échouer un pull request si une vulnérabilité critique apparaît.

name: Scan de sécurité des conteneurs
on: [push, pull_request]

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Construire l'image
        run: docker build -t mon-app:${{ github.sha }} .
      - name: Scanner avec Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'mon-app:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
      - name: Envoyer les résultats vers GitHub Code Scanning
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Étape 13 : bloquer les images non conformes au moment du déploiement. Le scan en CI/CD empêche de fusionner du code vulnérable, mais rien n’empêche un opérateur de déployer manuellement une image non scannée si aucun contrôle n’existe côté cluster. Un contrôleur d’admission comme Kyverno ou OPA Gatekeeper referme cette porte en refusant tout pod dont l’image n’est pas signée par une clé Cosign de confiance.

# Exemple de politique Kyverno qui exige une signature Cosign valide
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verifier-signature-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verifier-signature-cosign
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences: ["mon-registre.local/*"]
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      (contenu de cosign.pub)
                      -----END PUBLIC KEY-----

Avec ce dernier verrou, un pipeline complet est en place : scan Trivy et Grype en CI, génération de SBOM, signature Cosign après validation, puis contrôle d’admission qui bloque toute image non signée avant même qu’elle atteigne un nœud du cluster. Pour la gestion des secrets utilisés dans ce pipeline (clés Cosign, jetons de registre), notre guide sur la gestion des secrets Kubernetes couvre les bonnes pratiques de stockage.

Automatiser le scan sur un registre privé

Le scan en pipeline CI/CD couvre les nouvelles images au moment du build, mais votre registre privé (Harbor, GitLab Container Registry, Amazon ECR) contient probablement des dizaines, voire des centaines d’images plus anciennes qui ne repasseront jamais par ce pipeline. Une CVE publiée sur une bibliothèque courante peut toucher une image vieille de six mois, encore utilisée en production, sans qu’aucun scan récent ne l’ait détecté. Trivy peut interroger directement un registre distant, ce qui permet de programmer un balayage périodique de l’ensemble du parc d’images sans passer par un rebuild.

# Scanner une image directement depuis un registre privé
trivy image --username monutilisateur --password $REGISTRY_TOKEN mon-registre.local/mon-app:2025.12

# Lister puis scanner en boucle toutes les images d'un dépôt (exemple Harbor via son API)
for tag in $(curl -s -u "monutilisateur:$REGISTRY_TOKEN" \
  https://harbor.entreprise.fr/api/v2.0/projects/prod/repositories/mon-app/artifacts | jq -r '.[].tags[0].name'); do
  echo "Scan de mon-app:$tag"
  trivy image --severity CRITICAL --exit-code 0 harbor.entreprise.fr/prod/mon-app:$tag
done

Programmer le scan avec une tâche planifiée Kubernetes

Si votre registre tourne à l’intérieur d’un cluster Kubernetes, un CronJob exécutant Trivy chaque nuit constitue la manière la plus simple d’automatiser ce balayage sans dépendre d’un serveur CI/CD externe. Le job peut écrire ses résultats dans un bucket de stockage ou les pousser vers un webhook Slack en cas de faille critique détectée, ce qui donne à l’équipe de sécurité une visibilité continue sur l’état réel du parc d’images, plutôt qu’une photographie prise uniquement au moment du dernier déploiement.

Ce contrôle a posteriori complète, sans le remplacer, le blocage en amont réalisé au moment du build. Les deux mécanismes répondent à des questions différentes : le scan en CI/CD demande “cette nouvelle image est-elle sûre avant de partir en production”, tandis que le scan planifié sur le registre demande “les images déjà en production le sont-elles encore aujourd’hui”. Une organisation mature répond aux deux questions, pas uniquement à la première.

Images distroless : réduire la surface d’attaque

Scanner une image, c’est bien. Réduire ce qu’il y a à scanner, c’est encore mieux. Les images distroless, popularisées par Google, retirent tout ce qui n’est pas strictement nécessaire à l’exécution de l’application : pas de gestionnaire de paquets, pas de shell, pas d’outils réseau. Moins de composants installés signifie mécaniquement moins de surface exposée aux CVE, puisque chaque paquet système absent est une vulnérabilité potentielle en moins à corriger.

Caractéristique	Image classique (ex. debian:12)	Image distroless
Gestionnaire de paquets (apt, apk)	Présent	Absent
Shell interactif (bash, sh)	Présent	Absent dans la variante stricte
Outils de diagnostic (curl, ping, netcat)	Souvent présents	Absents
Bibliothèques système installées	Ensemble complet de la distribution	Uniquement les dépendances runtime de l’application
Facilité de débogage en direct	Élevée (accès shell)	Faible, nécessite un conteneur de debug séparé

Le compromis est réel : sans shell, impossible de faire un docker exec classique pour investiguer un problème en production. La pratique recommandée consiste à utiliser un build multi-étapes, où l’étape de compilation utilise une image complète avec tous les outils nécessaires, tandis que l’image finale, distroless, ne contient que le binaire compilé et ses dépendances strictes. Trivy scanne ces images distroless exactement comme les autres, mais le nombre de lignes dans le rapport chute nettement, simplement parce qu’il y a moins de paquets à examiner.

Erreurs courantes à éviter

Voici les pièges les plus fréquents observés chez les équipes qui démarrent avec le scan de conteneurs.

• Scanner une seule fois, au moment du build. Une image jugée saine aujourd’hui peut devenir vulnérable demain si une CVE est publiée sur l’un de ses composants. Planifiez des scans périodiques sur les images déjà déployées, pas uniquement au moment du build.
• Ignorer les vulnérabilités de sévérité MEDIUM par défaut. Filtrer uniquement sur CRITICAL et HIGH est raisonnable pour bloquer un build, mais une accumulation de failles MEDIUM non traitées finit par constituer un risque réel. Gardez une revue périodique de ces alertes.
• Oublier de mettre à jour la base de données locale de Trivy. Un cache de vulnérabilités périmé donne un faux sentiment de sécurité. Automatisez le rafraîchissement de la base dans votre pipeline plutôt que de vous fier au cache local d’un poste de développeur.
• Signer sans jamais vérifier. Générer une signature Cosign ne sert à rien si aucun contrôleur d’admission ne la vérifie réellement au moment du déploiement. Sans étape de vérification obligatoire côté cluster, la signature reste un artefact décoratif.
• Traiter le SBOM comme un simple fichier de conformité. Un SBOM généré une fois et jamais consulté n’apporte aucune valeur opérationnelle. Utilisez-le activement pour évaluer l’impact d’une nouvelle CVE annoncée sur une bibliothèque tierce.
• Faire confiance à un seul scanner. Trivy et Grype n’ont pas exactement les mêmes bases de vulnérabilités. Se limiter à un seul outil augmente le risque de faux négatif sur certaines familles de paquets.

Dépannage : problèmes fréquents et solutions

Voici les incidents les plus signalés lors de la mise en place d’un pipeline de scan, avec leur cause probable et la correction à appliquer.

Symptôme	Cause probable	Solution
Erreur de vérification de signature GPG lors de apt update	Clé de dépôt Trivy périmée depuis la rotation d’avril 2026	Réimporter la clé publique actuelle depuis le dépôt officiel Aqua Security
Le scan reste bloqué sur “downloading vulnerability DB”	Pare-feu ou proxy d’entreprise bloquant l’accès au registre GitHub Container Registry	Autoriser le domaine du registre ou configurer un miroir interne de la base de données
Trivy et Grype donnent des résultats différents sur la même image	Bases de vulnérabilités différentes entre les deux outils	Comportement normal : traiter les deux rapports comme complémentaires, pas contradictoires
cosign verify échoue alors que l’image a bien été signée	Mauvaise clé publique utilisée, ou image reconstruite après la signature	Vérifier que la clé publique correspond à la clé privée utilisée et resigner après tout rebuild
Le pipeline CI/CD dépasse le temps imparti pendant le scan	Base de données de vulnérabilités retéléchargée à chaque exécution	Mettre en cache le répertoire de la base Trivy entre les exécutions du pipeline
Faux positifs répétés sur un paquet déjà corrigé	Correctif backporté par la distribution mais non détecté par le scanner	Ajouter une règle d’ignore documentée avec une date de revue, plutôt que de désactiver le scan
Le contrôleur d’admission Kyverno bloque tous les pods, y compris les images internes non concernées	Politique de vérification de signature trop large	Restreindre la politique aux préfixes de registre concernés par la règle imageReferences
La génération de SBOM échoue sur une image multi-architecture	Trivy scanne par défaut l’architecture de la machine hôte	Préciser la plateforme cible avec l’option --platform lors du scan

Astuces avancées

Une fois le socle scan, SBOM et signature en place, plusieurs ajustements permettent de gagner en maturité. D’abord, exportez systématiquement vos résultats au format SARIF vers GitHub code scanning ou GitLab, ce qui centralise les alertes de sécurité au même endroit que les autres contrôles qualité du code, sans obliger l’équipe à consulter un tableau de bord supplémentaire.

Ensuite, exploitez le format VEX (Vulnerability Exploitability eXchange), pris en charge par Grype via un transformeur CSAF. Le VEX permet de documenter qu’une CVE présente dans une bibliothèque n’est en réalité pas exploitable dans votre contexte précis, par exemple parce que la fonction vulnérable n’est jamais appelée. Cette pratique évite de rouvrir sans cesse un même ticket de sécurité déjà analysé et jugé non critique.

Enfin, pensez à scanner régulièrement les images déjà en production, pas uniquement au moment du build. Une image jugée saine en janvier peut devenir vulnérable en mars si une nouvelle CVE touche l’une de ses bibliothèques. Un scan hebdomadaire automatisé sur votre registre, avec alerte si une image en production active dépasse un seuil de sévérité, referme cette fenêtre de risque que la plupart des pipelines CI/CD classiques laissent ouverte.

Adapter le pipeline à la taille de l’équipe

Une startup de cinq développeurs n’a pas besoin du même dispositif qu’un grand groupe soumis à un audit NIS2 annuel. Pour une petite équipe, Trivy seul en CI/CD, avec blocage sur les failles critiques, couvre déjà l’essentiel du risque à un coût d’implémentation faible. Pour une organisation plus grande, avec plusieurs équipes et un registre partagé, ajoutez Grype en second avis, un contrôleur d’admission Kyverno et un tableau de bord centralisé des SBOM. La progression naturelle consiste à démarrer simple, mesurer combien de vulnérabilités critiques sont effectivement bloquées sur trois mois, puis étoffer le dispositif si le volume de failles détectées justifie l’investissement en temps d’équipe.

Projet complet : un pipeline de sécurité de bout en bout

En suivant les 13 étapes de ce tutoriel, vous disposez désormais d’une chaîne complète et fonctionnelle. Un développeur pousse du code, le pipeline CI/CD construit l’image, Trivy la scanne et bloque le build en cas de faille critique, un SBOM CycloneDX est généré et archivé, Grype confirme les résultats en second avis, l’image est signée avec Cosign une fois validée, puis un contrôleur d’admission Kyverno vérifie cette signature avant d’autoriser le moindre déploiement sur le cluster. Un scan planifié sur le registre referme la boucle en surveillant les images déjà déployées, longtemps après leur build initial.

Chaque maillon de cette chaîne est indépendant et peut être adopté progressivement. Une équipe qui démarre peut se contenter des étapes 1 à 5, un scan Trivy simple bloquant les failles critiques en local, avant d’ajouter le reste au fil des mois. C’est la combinaison de ces maillons, et non un seul outil isolé, qui transforme un contrôle ponctuel en défense structurée. Pour une organisation soumise au Cyber Resilience Act ou à NIS2, cette combinaison représente aussi la preuve la plus tangible d’une gestion de vulnérabilités réellement opérationnelle, plutôt qu’un simple document de politique interne resté sans application concrète.

Questions fréquentes

Trivy est-il vraiment gratuit pour un usage en entreprise ?
Oui. Trivy est distribué sous licence Apache 2.0, sans limite d’usage commercial. Aqua Security propose en complément une offre payante avec fonctionnalités de gestion centralisée, mais l’outil en ligne de commande reste entièrement gratuit.

Faut-il utiliser Trivy et Grype en même temps, ou choisir l’un des deux ?
Les deux outils sont complémentaires plutôt que redondants, car ils s’appuient sur des flux de vulnérabilités partiellement différents. Pour un premier déploiement, Trivy suffit largement grâce à sa polyvalence (images, Kubernetes, IaC, SBOM). Ajoutez Grype ensuite comme second avis sur vos images les plus sensibles.

Le scan de conteneurs ralentit-il vraiment le pipeline CI/CD ?
Un scan bien configuré, avec la base de données mise en cache entre les exécutions, ajoute généralement moins d’une minute au pipeline. Le vrai coût de temps vient du premier téléchargement de la base de vulnérabilités, qu’il faut absolument mettre en cache.

Les images distroless sont-elles compatibles avec tous les langages ?
Les images distroless conviennent bien aux binaires compilés statiquement (Go, Rust) et aux runtimes gérés (Java, Node.js, Python) via des variantes dédiées. Certains cas nécessitant des outils système au runtime peuvent demander des ajustements spécifiques.

Comment gérer les faux positifs sans désactiver totalement le scan ?
Trivy et Grype permettent tous deux de créer des fichiers d’exceptions documentées (.trivyignore pour Trivy, règles d’ignore YAML pour Grype). Documentez toujours la raison et prévoyez une date de revue plutôt que d’ignorer une CVE indéfiniment.

La signature Cosign remplace-t-elle un certificat TLS classique ?
Non, ce sont deux mécanismes différents. Le certificat TLS sécurise une connexion réseau, tandis que la signature Cosign atteste l’intégrité et la provenance d’une image de conteneur. Les deux sont complémentaires dans une architecture cloud-native sécurisée.

Ce pipeline est-il suffisant pour être conforme au Cyber Resilience Act ?
Le scan, le SBOM et la signature couvrent une partie importante des exigences techniques liées à la gestion des vulnérabilités et à la traçabilité des composants. La conformité complète implique aussi des processus organisationnels (déclaration d’incidents, documentation) qui dépassent le cadre purement technique de cet article. Consultez notre dossier sur les critères de sécurité des conteneurs sous le CRA et le référentiel C5 pour la vue d’ensemble réglementaire.

Peut-on appliquer ce pipeline à un cluster Kubernetes géré (EKS, GKE, AKS) ?
Oui, l’ensemble des commandes présentées fonctionne à l’identique sur un cluster géré, à condition que votre configuration kubectl pointe vers le bon contexte. Les contrôleurs d’admission comme Kyverno s’installent normalement via Helm sur ces clusters managés, sans particularité liée au fournisseur cloud.