Trivy 0.76.0 testé pour de vrai : protocole, mesures et limites (2026-10-18)

En résumé

Le 2026-10-18, nous avons téléchargé Trivy 0.76.0, vérifié l'empreinte du zip, puis exécuté trivy fs sur un dossier jetable de 5 fichiers que nous avons construit : un package-lock.json avec lodash 4.17.15, un requirements.txt avec flask 0.12 et pyyaml 5.3, un Dockerfile volontairement fautif et un fichier de faux identifiants AWS générés au hasard. Ce test porte sur une seule machine, une seule version et un jeu de 708 octets : il décrit ce que nous avons observé, il ne mesure pas un taux de détection et ne se généralise pas à vos projets. Il complète l'avis MagicMate sur Trivy, qui reste une lecture des sources publiques.

Ce que nous avons observé, dans l'ordre :

• Au premier lancement, Trivy a téléchargé sa base de vulnérabilités (128,72 Mio transférés, 1,6 Go une fois écrite sur le disque) puis un lot de règles de configuration. Cette première exécution a duré 11,7 s ; les exécutions suivantes, sur le cache, ont duré de 1 024 à 1 158 ms.
• Le scan a trouvé 7 vulnérabilités dans le fichier npm, 6 dans le fichier pip, 5 problèmes de configuration dans le Dockerfile et 2 secrets dans le fichier d'identifiants.
• Le code de sortie vaut 0 par défaut, même quand des problèmes sont trouvés ; il faut ajouter --exit-code pour bloquer une intégration continue.
• Notre premier jeu de faux identifiants contenait un identifiant AWS tronqué, par une erreur de notre générateur : aucun secret n'a alors été signalé sur cette ligne, ce qui ne dit rien sur Trivy. Après correction, les deux règles AWS ont déclenché.

Protocole et commandes

Machine : Windows 11, shell Git Bash. Tout s'est fait dans un dossier de travail neuf, hors du projet. Dans les commandes, T désigne trivy.exe, sample le dossier de test et cache un dossier de cache dédié.

1. Version : l'API GitHub indique, le 2026-10-18, la dernière release v0.76.0, publiée le 2026-10-14 (la précédente, v0.75.0, date du 2026-10-01). Licence Apache-2.0 (champ SPDX de l'API et fichier LICENSE du zip, lu).
2. Vérification : le zip trivy_0.76.0_windows-64bit.zip (53 449 911 octets) a pour SHA-256 7b4762a5a5326cb4b83dfd2bb5d9aaf15a1ed867c75cad7dd8b38840a28e7be6, identique à la ligne du fichier de sommes de contrôle publié avec la release.
3. Extraction : unzip trivy.zip -d bin. Le dossier contient trivy.exe (178 127 360 octets), LICENSE, README.md et un dossier contrib. T --version affiche Version: 0.76.0.
4. Jeu de test (708 octets au total) :

Fichier	Contenu
package-lock.json, package.json	lodash 4.17.15
requirements.txt	flask 0.12 et pyyaml 5.3
Dockerfile	FROM ubuntu:latest, ADD app.tar.gz, apt-get install -y curl, EXPOSE 22, aucun USER, aucun HEALTHCHECK
deploy.cfg	un identifiant de forme AWS et une clé secrète de 40 caractères, tous deux tirés au hasard (jamais affichés ici)

5. Scan principal : T fs sample --cache-dir cache --scanners vuln,misconfig,secret --format json -o out/fs.json. Le journal indique le téléchargement de la base (miroir mirror.gcr.io/aquasec/trivy-db:2), puis celui du lot de règles de configuration, un message d'information sur le secret, un avertissement (WARN) sur l'absence de site-packages (détection des licences pip ignorée), puis le nombre de fichiers par langage.
6. Exécutions suivantes, sans mise à jour réseau : ajouter --skip-db-update --skip-check-update. Temps mesuré avec l'horloge du shell autour de l'appel.
7. Variantes lancées : --exit-code 5, --severity CRITICAL, --format table, --format sarif, --format cyclonedx (ces deux derniers avec --scanners vuln), --offline-scan, et la sous-commande T config sample --cache-dir cache.

Résultats mesurés

Mesure	Valeur observée
Première exécution (téléchargements inclus)	11,7 s
Exécutions suivantes (3, avec --skip-db-update --skip-check-update)	1 024 ms, 1 152 ms, 1 158 ms
Base de vulnérabilités sur disque	1 637 498 880 octets (1,6 Go)
Lot de règles de configuration sur disque	2,7 Mo
Code de sortie par défaut	0
Code de sortie avec --exit-code 5	5

Détections de T fs :

Fichier	Résultat
package-lock.json (lodash 4.17.15)	7 vulnérabilités : 4 HIGH, 3 MEDIUM, dont CVE-2020-8203 (corrigée en 4.17.19) et CVE-2021-23337 (corrigée en 4.17.21)
requirements.txt (flask 0.12, pyyaml 5.3)	6 vulnérabilités : 2 CRITICAL (CVE-2020-14343 et CVE-2020-1747, pyyaml), 3 HIGH et 1 LOW (flask)
Dockerfile	5 problèmes : DS-0001 (balise :latest, MEDIUM), DS-0002 (utilisateur root, HIGH), DS-0004 (port 22 exposé, MEDIUM), DS-0026 (pas de HEALTHCHECK, LOW), DS-0029 (apt-get sans --no-install-recommends, HIGH)
deploy.cfg	2 secrets CRITICAL : aws-access-key-id (ligne 1) et aws-secret-access-key (ligne 2)

Autres observations :

• Lecture du rapport : le format table affiche un tableau par fichier avec la version installée et la version corrigée (par exemple lodash 4.17.15, corrigée en 4.17.19). Le JSON contient les identifiants, la gravité, le statut et les versions.
• Les secrets sont masqués par défaut dans le rapport JSON : la valeur de la clé secrète est remplacée par des astérisques dans les champs Match et Code.
• --severity CRITICAL --exit-code 5 : seules les 2 vulnérabilités CRITICAL de pyyaml restent et le code de sortie vaut 5.
• Reproductibilité : le JSON de la première exécution et celui d'une exécution ultérieure sont identiques une fois retirés les champs ReportID et CreatedAt.
• SBOM : --format cyclonedx --scanners vuln produit un fichier de 72 838 octets, au format CycloneDX 1.7, avec 5 composants (2 fichiers de dépendances et 3 paquets) et 13 vulnérabilités.
• SARIF : --format sarif --scanners vuln produit un fichier de 48 410 octets.
• T config sample ne scanne que les configurations et a retrouvé les mêmes 5 problèmes du Dockerfile.
• --offline-scan avec la base en cache : code de sortie 0.

Un faux départ, un échec, une absence

1. Notre générateur de faux identifiants a produit un identifiant AWS de 8 caractères au lieu de 20 (4 caractères tirés après le préfixe). Aucun secret n'a été signalé sur la ligne de l'identifiant, tandis que la clé secrète de la ligne suivante l'a été (règle aws-secret-access-key). Nous avons contrôlé la longueur de la ligne (29 octets), régénéré un identifiant complet de 20 caractères (ligne de 41 octets) et relancé : les deux règles ont déclenché. Le défaut venait de notre jeu de test, pas de Trivy.
2. T config sample --cache-dir cache --skip-db-update --skip-check-update a échoué avec « unknown flag: --skip-db-update » : cette sous-commande n'accepte pas cette option. Sans ces options, la commande fonctionne.
3. Un lancement avec un dossier de cache vide et --skip-db-update s'arrête avec « --skip-db-update cannot be specified on the first run » : la première exécution exige un accès réseau pour télécharger la base.
4. Le ADD app.tar.gz du Dockerfile n'a produit aucune alerte. Nous n'avons pas cherché la règle concernée : nous ne connaissons pas la raison.
5. Aucun scan de licences n'a été produit : Trivy a signalé que la détection des licences pip est ignorée sans dossier site-packages ; nous n'avons pas installé les dépendances.

Limites du test

• Une seule machine (Windows 11), une seule version (0.76.0), configuration par défaut hors options citées.
• Un jeu de 5 fichiers et 708 octets, synthétique : les temps d'exécution ne disent rien sur un projet réel ou volumineux.
• Les vulnérabilités trouvées dépendent de la base téléchargée le 2026-10-18 (mise à jour à 18 h 32 UTC selon son fichier de métadonnées) : un autre jour, le décompte peut différer.
• Les détections portent sur quelques cas choisis par nous et ne constituent pas un taux de détection ; nous n'avons pas vérifié si chaque vulnérabilité signalée est exploitable dans un vrai usage de la bibliothèque.
• Les secrets sont inventés et générés par nous : nous ne savons pas si de vrais secrets d'autres formats seraient détectés.
• Les 270 tickets et demandes de fusion ouverts annoncés par l'API GitHub n'ont pas été examinés.

Ce que nous n'avons pas testé

• Le scan d'une image de conteneur (trivy image) : Docker n'est pas installé sur la machine de test.
• Les manifestes Kubernetes, Terraform, le scan d'un dépôt distant, d'une machine virtuelle ou d'un cluster.
• L'intégration CI réelle, l'action GitHub, l'opérateur Kubernetes, le mode client-serveur.
• Les systèmes Linux et macOS, d'autres versions, y compris toute version postérieure à 0.76.0.
• Des projets réels ou volumineux, la mémoire utilisée, la performance à grande échelle.
• Une comparaison avec d'autres outils (Grype, Snyk, Gitleaks, etc.) et la mesure de faux positifs sur du code réel.
• L'historique de sécurité de la chaîne de distribution de Trivy lui-même, au-delà de la vérification d'empreinte du zip.

Sources

• Notre test du 2026-10-18, décrit ci-dessus (version 0.76.0, empreinte SHA-256 du zip vérifiée).
• https://github.com/aquasecurity/trivy (page de la version v0.76.0, README et LICENSE lus)
• Avis MagicMate sur Trivy pour la lecture des sources publiques.