Illustration : Trivy : analyser images Docker, dépendances et configurations à risque avant déploiement

Trivy : analyser images Docker, dépendances et configurations à risque avant déploiement

Une image Docker embarque un système de fichiers complet : bibliothèques système, paquets de langage, fichiers de configuration. Chacun peut contenir une vulnérabilité connue, un secret oublié ou un réglage dangereux. Trivy, scanner open source d’Aqua Security, détecte tout cela en une commande, avant que l’image n’arrive en production. Mais 2026 a aussi rappelé une leçon inattendue : l’outil de sécurité lui-même peut devenir le vecteur d’attaque. Voici comment utiliser Trivy efficacement et l’intégrer à vos pipelines en toute sécurité.

L’essentiel en 30 secondes

  • Trivy analyse les images, les dépôts de code, les fichiers d’infrastructure (Dockerfile, Kubernetes, Terraform) et produit des SBOM.
  • Il recherche quatre familles de problèmes : vulnérabilités (CVE), secrets, mauvaises configurations, licences.
  • En CI/CD, il bloque un déploiement si une vulnérabilité critique corrigeable est trouvée.
  • En mars 2026, l’action GitHub officielle de Trivy a été compromise : épinglez vos actions par empreinte SHA complète et faites tourner vos secrets si vous étiez concerné.

Premiers pas

Trivy est un binaire unique, disponible en paquet pour Debian, Ubuntu, RHEL et macOS, ou en image Docker. Les commandes de base :

# Analyser une image (vulnérabilités et secrets par défaut)
trivy image nginx:1.27

# Ne garder que l'actionnable : critique/élevé avec un correctif disponible
trivy image --severity CRITICAL,HIGH --ignore-unfixed mon-registre/app:1.4.2

# Analyser un dépôt local : dépendances, secrets, configurations
trivy fs --scanners vuln,secret,misconfig .

# Contrôler uniquement les fichiers d'infrastructure
trivy config ./deploiement

La première exécution télécharge la base de vulnérabilités ; les suivantes ne la mettent à jour que si nécessaire.

Lire le résultat sans se noyer

Une image basée sur une distribution complète peut afficher des centaines de CVE. Quelques règles pour prioriser :

Critère Ce qu’il faut regarder Décision type
Correctif disponible Colonne « Fixed Version » Si oui : reconstruire l’image avec la version corrigée
Sévérité CRITICAL et HIGH d’abord Traitement avant déploiement
Exploitation active Présence de la CVE dans le catalogue KEV de la CISA Priorité absolue
Composant réellement utilisé Bibliothèque chargée par l’application ou simple outil présent dans l’image Réduire l’image plutôt qu’ignorer
Faux positif avéré Analyse documentée Exception dans .trivyignore avec justification et date de revue

Le meilleur levier reste la réduction de la surface : images de base minimales (distroless, Alpine, images « slim ») et constructions multi-étapes qui ne gardent que le nécessaire. Pour la méthode générale de priorisation, voir prioriser les correctifs après l’annonce d’une vulnérabilité critique.

Secrets et mauvaises configurations

Trivy repère les clés d’API, jetons et clés privées oubliés dans une couche d’image ou un dépôt. Une clé trouvée dans une image publiée doit être considérée comme compromise : la supprimer de l’image ne suffit pas, il faut la révoquer et la remplacer.

Côté configuration, il signale par exemple un Dockerfile qui s’exécute en root, l’absence de HEALTHCHECK, un manifeste Kubernetes avec un conteneur privilégié ou un bucket cloud public dans Terraform. Ces contrôles complètent les bonnes pratiques décrites dans sécurité des conteneurs Docker.

Générer un SBOM

# Produire l'inventaire des composants au format CycloneDX
trivy image --format cyclonedx --output sbom-app.json mon-registre/app:1.4.2

# Réanalyser plus tard ce SBOM avec une base de vulnérabilités à jour
trivy sbom sbom-app.json

Conserver le SBOM de chaque version livrée permet de répondre en minutes à la question « sommes-nous concernés ? » lors de la prochaine faille majeure. Détails dans SBOM : générer l’inventaire des composants logiciels.

Bloquer un déploiement dans la CI

L’option --exit-code 1 fait échouer le pipeline si des résultats correspondent aux filtres :

trivy image --severity CRITICAL --ignore-unfixed --exit-code 1 mon-registre/app:1.4.2

Commencez par bloquer uniquement les vulnérabilités critiques corrigeables, puis durcissez progressivement : un seuil trop strict dès le premier jour pousse les équipes à contourner le contrôle.

Mars 2026 : quand le scanner devient la porte d’entrée

Le 19 mars 2026, Aqua Security a révélé qu’un attaquant avait utilisé des identifiants conservés après une rotation incomplète pour publier une version malveillante de Trivy (0.69.4) et réécrire, par « force-push », la quasi-totalité des étiquettes de l’action GitHub aquasecurity/trivy-action ainsi que plusieurs de setup-trivy. Des images Docker piégées (0.69.5 et 0.69.6) ont aussi été publiées le 22 mars. Le code malveillant cherchait à voler les secrets présents dans les pipelines. La vulnérabilité est référencée CVE-2026-33634.

Les enseignements dépassent Trivy :

  • Une étiquette de version (@v0.35.0) peut être déplacée. Seule une référence par empreinte SHA complète garantit le code exécuté.
  • Les outils de sécurité ont des accès privilégiés : ils lisent tout le code et tournent avec les secrets de la CI.
  • La rotation d’identifiants doit être complète : un seul jeton oublié a suffi.

Si vos pipelines ont exécuté une version compromise pendant la période concernée : faites tourner tous les secrets accessibles au pipeline, vérifiez l’absence de dépôt inattendu nommé tpcp-docs dans votre organisation GitHub et suivez les indicateurs publiés par Aqua Security.

# Épinglage par SHA : la référence ne peut pas être déplacée
- name: Analyse Trivy
  uses: aquasecurity/trivy-action@<empreinte-SHA-complète-vérifiée> # v0.35.0
  with:
    image-ref: mon-registre/app:1.4.2
    severity: CRITICAL,HIGH
    ignore-unfixed: true
    exit-code: '1'

Pour l’ensemble des mesures de protection des pipelines, voir sécuriser GitHub Actions et GitLab CI/CD contre le vol de secrets et notre article sur les attaques de la chaîne d’approvisionnement logicielle.

Questions fréquentes

Trivy est-il toujours fiable après l’incident de 2026 ?

L’incident concernait la chaîne de publication, pas la qualité de l’analyse. Aqua Security a publié des versions saines et un avis détaillé. Comme pour tout outil, utilisez des versions vérifiées, épinglées et mises à jour de façon contrôlée.

Trivy remplace-t-il un scanner de vulnérabilités réseau ?

Non. Trivy analyse des artefacts (images, code, fichiers). Pour les serveurs et équipements en fonctionnement, un scanner réseau comme Greenbone OpenVAS est complémentaire.

Faut-il analyser à chaque construction ou régulièrement ?

Les deux : à chaque construction pour bloquer les nouveautés, et régulièrement (chaque nuit, par exemple) sur les images déjà en production, car de nouvelles CVE sont publiées chaque jour.

Peut-on l’utiliser hors connexion ?

Oui, en préparant la base de vulnérabilités sur un poste connecté et en la transférant, ou via un miroir interne.

Sources

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous auditons vos chaînes de déploiement dans le cadre de nos audits de sécurité. Demandez un devis gratuit ou appelez le 05 32 42 99 98.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *