Trivy : scanner open source conteneurs, code et IaC

Introduction

Une image de conteneur embarque en moyenne des centaines de paquets système et de dépendances applicatives, chacun susceptible de porter une vulnérabilité connue. À cela s’ajoutent les fichiers d’infrastructure as code (Terraform, Kubernetes, Dockerfile), où une simple erreur de configuration peut exposer un service entier, et les secrets oubliés dans un dépôt Git. Pour une équipe IT ou sécurité, contrôler tout cela à la main est impossible : il faut un scanner automatisable, rapide et intégrable dans les pipelines CI/CD.

Trivy, développé par Aqua Security, s’est imposé comme l’un des outils open source de référence sur ce créneau. Il réunit dans un seul binaire la détection de vulnérabilités (CVE), l’analyse de mauvaises configurations, la recherche de secrets, l’inventaire des licences et la génération de SBOM. Cet article détaille son fonctionnement, son installation, ses principaux cas d’usage, sa place face aux alternatives et les bonnes pratiques à adopter, notamment depuis l’incident de chaîne d’approvisionnement qui l’a touché en mars 2026.

Qu’est-ce que Trivy ?

Trivy est un scanner de sécurité open source publié sous licence Apache 2.0 et maintenu par Aqua Security sur GitHub (dépôt aquasecurity/trivy, près de 39 000 étoiles). Écrit en Go, il se présente sous la forme d’un binaire unique, sans dépendance, disponible pour Linux, macOS et Windows. À l’heure où nous écrivons ces lignes, la dernière version stable est la v0.76.0, publiée le 14 octobre 2026.

Sa force tient à la combinaison de deux notions :

Les cibles (ce que l’on analyse) : images de conteneurs, systèmes de fichiers, dépôts Git distants, images de machines virtuelles et clusters Kubernetes.
Les scanners (ce que l’on recherche) : paquets et dépendances (SBOM), vulnérabilités connues, mauvaises configurations IaC, secrets et licences logicielles.

La syntaxe suit toujours le même schéma : trivy <cible> [--scanners <scanner1,scanner2>] <sujet>. Cette cohérence permet de passer d’un scan d’image à un audit de cluster sans changer d’outil. Trivy a d’ailleurs absorbé au fil des versions les fonctionnalités de tfsec, l’ancien analyseur Terraform d’Aqua Security.

Architecture et fonctionnement

Le fonctionnement de Trivy repose sur trois étapes successives :

L’inventaire : Trivy extrait le contenu de la cible (couches d’image, arborescence, manifestes) et identifie la distribution du système (Alpine, Debian, Ubuntu, RHEL, AlmaLinux, etc.) ainsi que les fichiers de dépendances des langages (package-lock.json, go.sum, requirements.txt, pom.xml, Cargo.lock, etc.).
La corrélation : chaque composant est comparé à une base de vulnérabilités agrégée à partir des avis des éditeurs de distributions, de la NVD et des bases d’avis des écosystèmes de langages. Cette base est téléchargée et mise en cache localement, puis rafraîchie automatiquement.
L’analyse de règles : pour les mauvaises configurations, Trivy applique des politiques écrites en Rego couvrant Dockerfile, Kubernetes, Helm, Terraform, CloudFormation ou Azure ARM. Des règles personnalisées peuvent être ajoutées.

Trivy peut fonctionner en mode autonome, ou en mode client/serveur : un serveur central héberge la base de vulnérabilités et les clients légers lui délèguent la corrélation, ce qui évite de télécharger la base sur chaque runner. Pour Kubernetes, le projet Trivy Operator exécute les scans en continu dans le cluster et publie les résultats sous forme de ressources personnalisées (CRD).

Installation

Trivy est disponible via les dépôts officiels APT et YUM d’Aqua Security, Homebrew, un script d’installation, ou une image Docker officielle (Docker Hub, GHCR et Amazon ECR Public). Voici les méthodes les plus courantes :

# Debian / Ubuntu (dépôt APT officiel)
sudo apt-get install wget gnupg
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 generic main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

# RHEL / AlmaLinux / Rocky (dépôt YUM officiel)
cat << EOF | sudo tee -a /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
EOF
sudo yum -y install trivy

# macOS / Linux avec Homebrew
brew install trivy

# Docker (en épinglant une version précise)
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/.cache/trivy:/root/.cache/ aquasec/trivy:0.76.0 image alpine:3.20

# Vérification
trivy --version

Utilisation au quotidien

Une fois installé, Trivy s’utilise en une ligne de commande. Au premier lancement, il télécharge sa base de vulnérabilités ; les exécutions suivantes s’appuient sur le cache local, ce qui les rend très rapides.

Scanner une image de conteneur : c’est l’usage historique. Trivy liste les paquets vulnérables, la CVE associée, la sévérité, la version installée et la version corrigée lorsqu’elle existe.
Filtrer le bruit : les options --severity et --ignore-unfixed permettent de ne remonter que les failles critiques ou élevées pour lesquelles un correctif est disponible, c’est-à-dire celles sur lesquelles l’équipe peut réellement agir.
Bloquer un pipeline : avec --exit-code 1, Trivy renvoie un code d’erreur dès qu’une vulnérabilité correspondant aux critères est trouvée, ce qui fait échouer le job CI.
Auditer un projet : la cible fs analyse un répertoire local à la recherche de dépendances vulnérables, de secrets et de mauvaises configurations, avant même la construction de l’image.
Contrôler l’IaC : la commande trivy config vérifie les fichiers Terraform, les manifestes Kubernetes ou les Dockerfile (conteneur lancé en root, port SSH exposé, bucket public, etc.).
Produire et réutiliser un SBOM : Trivy génère des inventaires aux formats CycloneDX ou SPDX, puis peut rescanner ce SBOM ultérieurement sans disposer de l’image d’origine, un atout pour répondre aux exigences de traçabilité du Cyber Resilience Act.
Auditer un cluster : la cible k8s produit un rapport de synthèse sur les charges de travail, les configurations et les droits RBAC du cluster courant.

Les résultats peuvent être exportés en tableau, JSON, SARIF (pour GitHub Code Scanning), CycloneDX, SPDX ou via des modèles personnalisés. Un fichier .trivyignore placé à la racine du projet permet de documenter les exceptions acceptées.

# Scanner une image (critiques et élevées, avec correctif disponible)
trivy image --severity HIGH,CRITICAL --ignore-unfixed nginx:1.27

# Faire échouer un job CI si une faille critique est trouvée
trivy image --exit-code 1 --severity CRITICAL registry.local/app:1.4.2

# Analyser un projet local : vulnérabilités, secrets, mauvaises configurations
trivy fs --scanners vuln,secret,misconfig ./mon-projet

# Contrôler les fichiers IaC (Terraform, Kubernetes, Dockerfile)
trivy config ./infra

# Générer un SBOM CycloneDX puis le rescanner plus tard
trivy image --format cyclonedx --output sbom.cdx.json registry.local/app:1.4.2
trivy sbom sbom.cdx.json

# Export SARIF pour GitHub Code Scanning
trivy fs --format sarif --output trivy.sarif .

# Synthèse de sécurité du cluster Kubernetes courant
trivy k8s --report summary cluster

# Mode client/serveur
trivy server --listen 0.0.0.0:4954
trivy image --server http://trivy.interne:4954 alpine:3.20

Comparaison avec les alternatives

Trivy n’est pas seul sur le marché de l’analyse de composants et de conteneurs. Les principales alternatives se positionnent ainsi :

Grype et Syft (Anchore) : un duo open source très apprécié. Syft génère les SBOM, Grype les corrèle avec les bases de vulnérabilités. L’approche est plus modulaire, mais ne couvre ni l’IaC ni les secrets ; Trivy fait tout en un seul outil.
Clair : scanner historique intégré notamment au registre Quay. Il fonctionne en service et convient aux registres, mais il est moins adapté à un usage ponctuel en ligne de commande ou en CI.
Docker Scout : intégré à Docker Desktop et Docker Hub, pratique pour les développeurs, mais lié à l’écosystème Docker et en partie commercial.
Snyk : solution SaaS commerciale très complète (code, dépendances, conteneurs, IaC), avec une excellente expérience développeur et des correctifs proposés automatiquement, mais payante au-delà de l’offre gratuite.

Le point fort de Trivy reste sa polyvalence pour un coût nul : un seul binaire couvre les conteneurs, le code, l’IaC, les secrets, les licences et Kubernetes. Ses limites tiennent à l’absence de console centrale native (il faut l’alimenter vers un outil tiers comme DefectDojo ou Dependency-Track, ou passer par l’offre commerciale d’Aqua) et au volume de résultats qu’il faut apprendre à filtrer.

Bonnes pratiques

Un scanner de sécurité dispose par nature d’accès étendus : registres, code source, secrets de CI. L’incident de mars 2026 l’a rappelé. Entre le 19 et le 20 mars, des attaquants ont compromis la chaîne de publication du projet : la version v0.69.4 du binaire, les images Docker 0.69.5 et 0.69.6, ainsi que les GitHub Actions aquasecurity/trivy-action et aquasecurity/setup-trivy ont diffusé un voleur d’identifiants ciblant les secrets des runners. Les recommandations suivantes en découlent directement :

Épingler les versions : utilisez une version précise du binaire ou de l’image (jamais latest) et référencez les GitHub Actions par leur SHA de commit complet plutôt que par un tag modifiable.
Vérifier son historique : si vos pipelines ont exécuté Trivy ou ses actions autour du 19 mars 2026, consultez l’avis officiel d’Aqua Security, recherchez les connexions vers le domaine typosquatté utilisé par l’attaque et faites tourner les secrets exposés.
Restreindre les flux sortants des runners CI à une liste blanche de destinations.
Scanner tôt et souvent : dans l’IDE ou en pre-commit avec trivy fs, en CI à chaque build, puis en continu dans le registre et dans le cluster avec Trivy Operator, car de nouvelles CVE apparaissent chaque jour sur des images déjà déployées.
Prioriser : commencez par bloquer uniquement les vulnérabilités critiques corrigeables, puis durcissez progressivement les seuils. Un pipeline qui échoue en permanence finit toujours contourné.
Documenter les exceptions dans .trivyignore ou via des documents VEX, avec une justification et une date de revue.
Mettre en cache la base ou déployer le mode serveur pour éviter les limites de téléchargement et accélérer les scans à grande échelle.
Centraliser les résultats (SARIF, JSON, SBOM) dans un outil de gestion des vulnérabilités pour suivre les tendances et les délais de correction.

Conclusion

Trivy s’est imposé comme un standard de fait pour la sécurité des conteneurs et de la chaîne logicielle : gratuit, rapide, simple à intégrer et couvrant à lui seul vulnérabilités, mauvaises configurations, secrets, licences et SBOM. Pour une DSI ou une équipe DevSecOps, c’est l’un des moyens les plus efficaces de passer d’une sécurité réactive à un contrôle systématique à chaque étape du cycle de vie des applications.

L’incident de 2026 ne remet pas en cause son intérêt, mais il rappelle une règle essentielle : les outils de sécurité doivent eux-mêmes être traités comme des composants critiques, avec des versions épinglées, des sources vérifiées et des privilèges limités. Bien encadré, Trivy reste un allié de premier plan pour réduire durablement la surface d’attaque de vos applications.

Partagez cet article !