Trivy, c'est un scanner de sécurité unifié qui couvre cinq domaines depuis une seule interface : vulnérabilités logicielles (CVE), erreurs de configuration d'infrastructure (IaC), secrets en clair dans le code, licences de dépendances et conformité réglementaire. Contrairement à Grype ou Clair, qui se concentrent sur les images de conteneurs, Trivy analyse aussi le contenu d'un système de fichiers Linux directement sur le serveur — un vrai plus quand on audite un parc existant.
En avril 2026, le projet dépasse les 160 000 étoiles sur GitHub et bénéficie du parrainage de la CNCF. Sa base de données de vulnérabilités, distribuée via des OCI artifacts, est rafraîchie plusieurs fois par jour à partir de flux officiels : NVD, GitHub Security Advisories (GHSA), Red Hat OVAL, Alpine SecDB, Debian Security Tracker, et les bulletins Amazon Linux, SUSE, Oracle et Ubuntu.
Points forts par rapport aux alternatives
- Vitesse : un scan d'image Ubuntu 24.04 prend moins de 3 secondes après la première exécution, grâce au cache local de la base de données.
- Précision : détection multi-distribution (Alpine, Debian, RHEL, SUSE, Photon, Amazon Linux, Rocky, AlmaLinux) et multi-langage (Go, Rust, Python, Node.js, Java, .NET, Ruby, PHP).
- Intégration : plugins natifs pour GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI et Harbor.
- Portabilité : binaire unique sans dépendance, disponible pour x86_64, ARM64 et ppc64le.
Installation de Trivy sur Linux
Plusieurs méthodes coexistent. Sur Debian et Ubuntu, le dépôt APT officiel reste la voie recommandée en production, tout simplement parce qu'il permet des mises à jour automatiques via unattended-upgrades.
Installation sur Debian 12 et Ubuntu 24.04
sudo apt-get install -y wget gnupg lsb-release
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 $(lsb_release -sc) main" | \
sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install -y trivy
trivy --version
Installation sur RHEL 10, Fedora 41 et Rocky Linux
sudo tee /etc/yum.repos.d/trivy.repo << 'EOF'
[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 dnf install -y trivy
Installation via binaire statique
Pour les environnements air-gapped (ou les runners éphémères qui vivent dix minutes), le binaire statique reste la méthode la plus rapide.
TRIVY_VERSION=0.58.0
curl -sfL https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz \
| sudo tar -xz -C /usr/local/bin trivy
sudo chmod +x /usr/local/bin/trivy
Scanner une image de conteneur
La commande de base trivy image télécharge automatiquement la base de vulnérabilités lors du premier lancement, puis analyse toutes les couches de l'image. Les résultats sont classés par sévérité : UNKNOWN, LOW, MEDIUM, HIGH et CRITICAL.
trivy image nginx:1.27-alpine
En CI, c'est une autre histoire. Il faut absolument filtrer sur les sévérités critiques et faire échouer le build en cas de détection, sans quoi le rapport part à la corbeille comme tant d'autres. L'option --exit-code 1 combinée à --severity HIGH,CRITICAL fait exactement ce travail.
trivy image \
--severity HIGH,CRITICAL \
--exit-code 1 \
--ignore-unfixed \
--format json \
--output scan-result.json \
registry.example.com/app:v1.2.3
L'option --ignore-unfixed ignore les vulnérabilités pour lesquelles aucun correctif n'est encore disponible en amont. Ça évite de bloquer les livraisons sur des CVE que personne ne peut corriger dans l'immédiat — un compromis qu'on finit tous par adopter.
Utiliser un fichier .trivyignore
Pour accepter certaines CVE après analyse (faux positifs, composants non exploités au runtime), créez un fichier .trivyignore à la racine du projet.
# Faux positif — dépendance non utilisée au runtime
CVE-2024-12345
# Accepté jusqu'au 2026-06-30 — correctif en cours
CVE-2025-54321 exp:2026-06-30
Petit conseil glané sur le terrain : la date d'expiration, c'est vraiment pas optionnel. Sans elle, les dérogations s'accumulent année après année et plus personne ne sait pourquoi telle CVE est encore ignorée.
Scanner un système de fichiers Linux
La sous-commande trivy fs analyse n'importe quel répertoire local. C'est particulièrement pratique pour auditer un serveur de production sans avoir à construire d'image intermédiaire.
sudo trivy fs \
--scanners vuln,secret,misconfig \
--severity HIGH,CRITICAL \
--skip-dirs /proc,/sys,/dev,/run \
/
Les trois scanners activés détectent d'un coup les paquets vulnérables installés via APT ou DNF, les secrets en clair (clés SSH privées, tokens AWS, fichiers .env oubliés après un debug), et les erreurs de configuration dans les fichiers YAML, Terraform ou Dockerfile présents sur la machine.
Scanner les manifestes Kubernetes et l'IaC
Trivy embarque plus de 1 200 règles de sécurité couvrant Terraform, CloudFormation, Ansible, Helm, Kustomize et Dockerfile. Ces règles sont écrites en Rego et alignées sur les benchmarks CIS Docker, CIS Kubernetes et les recommandations de l'ANSSI.
trivy config \
--severity HIGH,CRITICAL \
--exit-code 1 \
./infrastructure/
Exemple typique de détection sur un manifeste Kubernetes :
deployment.yaml (kubernetes)
Tests: 23 (SUCCESSES: 20, FAILURES: 3)
Failures: 3 (HIGH: 2, CRITICAL: 1)
CRITICAL: Container 'app' runs as root
═══════════════════════════════════════
Set securityContext.runAsNonRoot to true.
HIGH: Container 'app' allows privilege escalation
════════════════════════════════════════════════
Set allowPrivilegeEscalation to false.
Détecter les secrets dans le code source
Le moteur de détection de secrets de Trivy reconnaît plus de 100 types de credentials : clés AWS, tokens GitHub, webhooks Slack, clés privées SSH et TLS, tokens JWT, chaînes de connexion de bases de données, clés Stripe, et la liste s'allonge à chaque release.
trivy fs \
--scanners secret \
--format table \
./src/
Pour intégrer ce scan dans un hook Git pre-commit, ajoutez la règle suivante à votre configuration .pre-commit-config.yaml :
repos:
- repo: https://github.com/aquasecurity/trivy
rev: v0.58.0
hooks:
- id: trivy-secret
args: ["--severity", "HIGH,CRITICAL"]
Honnêtement, c'est le genre de hook qu'on installe une fois et qu'on oublie — jusqu'au jour où il vous sauve d'un git push avec une clé AWS en clair. Et ce jour arrive, croyez-moi.
Générer un SBOM au format CycloneDX
Depuis la version 0.56, Trivy génère nativement des SBOM conformes aux normes CycloneDX 1.6 et SPDX 2.3. Ces documents sont essentiels pour répondre aux exigences du Cyber Resilience Act européen, applicable à partir de décembre 2027, et pour alimenter un système de gestion de vulnérabilités comme DependencyTrack.
trivy image \
--format cyclonedx \
--output sbom.cdx.json \
registry.example.com/app:v1.2.3
# Scanner ensuite le SBOM seul, sans réanalyser l'image
trivy sbom sbom.cdx.json
Intégration dans GitLab CI
Voilà un pipeline complet qui construit l'image, bloque le merge en cas de vulnérabilité critique, et publie un rapport SARIF consultable directement dans l'onglet Sécurité de GitLab.
stages:
- build
- security
build_image:
stage: build
image: docker:27
services:
- docker:27-dind
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
trivy_scan:
stage: security
image:
name: aquasec/trivy:0.58.0
entrypoint: [""]
variables:
TRIVY_NO_PROGRESS: "true"
TRIVY_CACHE_DIR: ".trivycache/"
script:
- trivy image
--exit-code 1
--severity HIGH,CRITICAL
--ignore-unfixed
--format sarif
--output trivy-report.sarif
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
cache:
paths:
- .trivycache/
artifacts:
reports:
sast: trivy-report.sarif
when: always
Déployer Trivy Operator sur Kubernetes
Trivy Operator scanne automatiquement chaque nouvelle ressource créée dans le cluster et expose les résultats comme des objets Kubernetes natifs (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport). L'installation via Helm prend moins d'une minute.
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--create-namespace \
--version 0.24.0 \
--set trivy.ignoreUnfixed=true \
--set operator.scanJobTimeout=10m
Après quelques minutes, jetez un œil aux rapports générés :
kubectl get vulnerabilityreports -A
kubectl get configauditreports -A
kubectl describe vulnerabilityreport -n default \
replicaset-nginx-xyz123-container-nginx
Audit de conformité CIS et NIST
Depuis la version 0.46, Trivy intègre un module compliance qui évalue une image ou un cluster contre les benchmarks CIS Docker, CIS Kubernetes et NIST SP 800-190. Le rapport résultant recense les contrôles respectés, les écarts, et les éléments qui nécessitent une investigation manuelle.
trivy image \
--compliance docker-cis-1.6.0 \
--format table \
alpine:3.20
trivy k8s \
--compliance k8s-cis-1.23 \
--report summary \
cluster
Automatiser les mises à jour de la base de vulnérabilités
Par défaut, Trivy retélécharge sa base à chaque exécution si elle date de plus de 24 heures. Dans un environnement à forte cadence de scan, mieux vaut la pré-télécharger via un cron nocturne : ça évite les rate limits du GitHub Container Registry (qui finissent toujours par tomber au mauvais moment).
# /etc/cron.d/trivy-db-update
0 3 * * * root /usr/local/bin/trivy image --download-db-only >/var/log/trivy-db.log 2>&1
Questions fréquentes
Quelle est la différence entre Trivy et Grype ?
Trivy couvre un périmètre bien plus large (IaC, secrets, Kubernetes, SBOM, conformité) tandis que Grype se concentre exclusivement sur les vulnérabilités d'images et de systèmes de fichiers. Les deux outils exploitent des sources de données similaires, mais Trivy dispose d'une communauté plus importante et d'une intégration native avec Kubernetes via Trivy Operator.
Trivy peut-il scanner des images privées sur un registre authentifié ?
Oui. Exportez les variables d'environnement TRIVY_USERNAME et TRIVY_PASSWORD, ou utilisez le fichier ~/.docker/config.json après une commande docker login. Pour AWS ECR, Azure ACR et Google Artifact Registry, Trivy récupère automatiquement les credentials via les SDK cloud si les variables d'environnement standards sont présentes.
Combien de temps prend un scan complet sur un serveur de production ?
Sur un serveur Debian 12 avec environ 1 500 paquets installés, un trivy fs / complet prend entre 15 et 45 secondes selon les scanners activés. L'ajout de la détection de secrets et des misconfigurations allonge la durée d'environ 30 %, mais ça reste tout à fait acceptable pour un cron quotidien.
Trivy respecte-t-il les exigences du Cyber Resilience Act ?
Trivy génère des SBOM conformes à CycloneDX 1.6 et SPDX 2.3, les deux formats reconnus par la norme européenne. Couplé à un gestionnaire de vulnérabilités comme DependencyTrack et à une politique de remédiation documentée, il constitue une brique technique solide pour la conformité CRA applicable en décembre 2027.
Faut-il exécuter Trivy en tant que root pour scanner un système ?
Pour trivy fs / scannant la racine du système, oui : les privilèges root sont nécessaires pour lire certains fichiers protégés (/etc/shadow, configurations de services). Pour scanner uniquement un projet ou une image de conteneur, un utilisateur non privilégié fait largement l'affaire. En CI, privilégiez l'exécution dans un conteneur dédié avec uniquement les droits de lecture nécessaires.
Conclusion
Trivy s'est imposé comme la brique de base d'une stratégie de sécurité cloud-native moderne, et pour de bonnes raisons : polyvalence, vitesse, écosystème vivant. Commencez par l'intégrer dans votre pipeline CI pour bloquer les vulnérabilités critiques au plus tôt, puis étendez son usage avec Trivy Operator sur Kubernetes et les audits de conformité CIS. Couplé à un scanner de runtime comme Falco et à un SIEM comme Wazuh, vous obtenez une chaîne de défense cohérente, du code source jusqu'à la production — et franchement, en 2026, c'est difficile de faire mieux pour un coût aussi réduit.
