Trivy en 2026 : un excellent scanner, à condition de soigner sa supply chain

⏱️

Temps de lecture estimé
~10 minutes

Trivy reste, en mai 2026, l’un des meilleurs scanners de vulnérabilités open source disponibles. La compromission de son dépôt GitHub en mars 2026 ne change rien à cette qualité technique. Ce qu’elle change, c’est notre regard sur la façon dont les équipes l’utilisent et sur la maturité de leur gestion de supply chain logicielle.

Pourquoi Trivy reste mon scanner de référence en 2026

Trivy, développé par Aqua Security, couvre images de conteneurs, systèmes de fichiers, dépôts Git, configurations IaC et clusters Kubernetes. Sa simplicité d’usage, sa couverture fonctionnelle et son rythme de mise à jour en font, à mes yeux, l’un des meilleurs choix open source du marché.

L’incident de mars 2026 n’a pas changé ce constat technique. En revanche, il a remis sur la table une question que beaucoup d’équipes esquivaient : comment intègre-t-on Trivy, et plus largement comment gère-t-on les outils de sécurité dans sa supply chain logicielle ? C’est sur ce terrain - pas sur le choix de l’outil - que la majorité des organisations ont du travail.

Le débat n’est pas « faut-il garder Trivy ? ». Il est « comment l’utilise-t-on, et avec quelle hygiène supply chain autour ? ».

Ce que Trivy sait faire — et son écosystème

Je liste ici, sans entrer dans les détails techniques, les cas d’usage que Trivy couvre nativement :

Images de conteneurs : OCI, Docker, registres publics et privés.
Système de fichiers : projets locaux, monorepos, dépendances package.json, requirements.txt, go.mod, pom.xml, etc.
Dépôts Git distants : audit ponctuel sans clone explicite.
Infrastructure as Code : Terraform, CloudFormation, Helm, Kubernetes, Dockerfile.
Clusters Kubernetes : ressources déployées, ConfigMaps, Secrets, RBAC.
Secrets exposés : clés API, tokens, credentials commités par accident.
SBOM : génération aux formats CycloneDX et SPDX, signature avec Cosign.

Comparatif rapide des scanners en 2026

Fonctionnalité	Trivy	Grype	Snyk	Clair
Images conteneurs	✅	✅	✅	✅
Filesystem	✅	✅	✅	❌
Dépôts Git distants	✅	❌	✅	❌
Kubernetes runtime	✅	❌	✅	❌
IaC (Terraform, K8s, Helm)	✅	❌	✅	❌
Détection de secrets	✅	❌	✅	❌
SBOM (CycloneDX / SPDX)	✅	✅	✅	⚠️
Open source	✅	✅	⚠️ Limité	✅
Maintenu activement	✅	✅	✅	⚠️

Grype, porté par Anchore, est en 2026 un excellent complément open source à Trivy pour le scan d’images et de SBOM. Je ne le vois pas comme un remplaçant, mais comme un second avis : croiser deux scanners qui s’appuient sur des bases d’advisories partiellement différentes réduit les angles morts. C’est de la défense en profondeur, pas de la défiance vis-à-vis de Trivy.

La leçon de mars 2026 : un problème d’usage, pas un problème de Trivy

Je ne peux pas écrire sur Trivy en 2026 sans revenir sur l’événement de cette année. Le 1er mars 2026, le dépôt aquasecurity/trivy a été compromis par un bot IA autonome baptisé hackerbot-claw, qui a exploité un workflow GitHub Actions vulnérable (apidiff.yaml, déclenché sur pull_request_target) pour voler un Personal Access Token, supprimer des années de releases, renommer le dépôt et publier une extension VSCode malveillante.

J’ai détaillé l’incident complet, kill chain, analyse STRIDE, IoC et remédiations, dans cet article dédié : Trivy compromis : quand le scanner de vulnérabilités devient la vulnérabilité.

Ce qu’il faut bien comprendre : la faille n’est pas dans le code de Trivy, ni dans sa qualité fonctionnelle. C’est un défaut de configuration d’un workflow CI , exactement le genre de défaut que beaucoup d’équipes laissent traîner dans leurs propres dépôts. La vraie leçon de mars 2026 est donc valable pour toutes les organisations, pas seulement pour Aqua Security :

La sécurité d’un outil de sécurité dépend autant de l’hygiène supply chain de l’éditeur que de celle de ceux qui l’intègrent. Les deux côtés ont leur part à faire.

Ce que les équipes doivent revoir dans leur usage

Je tire trois enseignements opérationnels que j’invite toutes les équipes à appliquer , ils valent pour Trivy comme pour n’importe quelle autre dépendance critique de leur chaîne de build :

Pinner les dépendances CI par digest, pas par tag. Une release republiée par un attaquant sous le même tag reste invisible pour qui ne vérifie pas l’empreinte SHA256. Cela vaut pour aquasecurity/trivy-action comme pour n’importe quelle GitHub Action ou image Docker tirée dans un pipeline.
Vérifier les signatures Cosign à chaque mise à jour des outils embarqués. Aqua Security signe ses artefacts depuis longtemps ; encore faut-il valider la signature côté consommateur, pas juste télécharger.
Traiter les bases de données externes comme des actifs critiques. Héberger un miroir interne de trivy-db et trivy-java-db (ou tout équivalent chez d’autres outils) limite la dépendance à un dépôt public, améliore la performance et permet de figer une version connue en cas d’incident amont.

Ces pratiques ne sont ni propres à Trivy ni nouvelles : ce sont les fondamentaux d’une supply chain logicielle saine, formalisés par SLSA, l’OpenSSF et plus récemment par l’OWASP Top 10 2025 dans A03 : Software Supply Chain Failures.

Je renvoie aussi vers deux articles connexes du blog qui complètent la réflexion supply chain :

Images Docker durcies : faut-il franchir le pas ? — pour réduire la surface d’attaque en amont.
OWASP AST02 — Supply Chain Compromise — la version « agentique » du même problème, appliquée aux skills d’agents IA.

Intégrer Trivy dans un pipeline DevSecOps

Je décris ici l’enchaînement type que l’on peut mettre en place, sans rentrer dans le détail des fichiers de configuration. L’idée est de comprendre où Trivy intervient et pourquoi, plutôt que de copier-coller un YAML.

Pre-commit : barrière précoce

Au niveau du poste développeur, on peut utiliser Trivy en hook pre-commit pour deux contrôles non négociables : secrets exposés (bloquant systématique) et vulnérabilités critiques connues sur les dépendances modifiées. C’est rapide, ça évite que des credentials atteignent le dépôt distant.

CI : scan filesystem + scan d’image

Dans la pipeline CI (GitHub Actions, GitLab CI, Jenkins), on découpe en deux étapes :

Avant le build : scan du filesystem pour secrets et vulnérabilités des dépendances. Génération d’un rapport SARIF remonté dans le DefectDojo par exemple.
Après le build : scan de l’image construite. Seuils différenciés selon l’environnement cible (CRITICAL bloquant en production, HIGH bloquant en staging).

L’utilisation systématique des les formats normalisés : SARIF pour l’intégration aux forges, CycloneDX pour le SBOM, JSON pour le post-traitement.

Registry : scan continu

Les images poussées sur le registre interne sont rescannées périodiquement, pas seulement à la construction. Une CVE publiée demain peut concerner une image construite hier ; le scan « one-shot » en CI ne suffit pas.

Admission Kubernetes : politique d’entrée

Côté cluster, on peut coupler Trivy avec un contrôleur d’admission (Kyverno ou Gatekeeper) qui refuse le déploiement d’images non scannées récemment ou dépassant un seuil de vulnérabilités. Le Trivy Operator automatise cette boucle : il scanne en continu les workloads déployés et expose les résultats sous forme de Custom Resources Kubernetes (VulnerabilityReport, ConfigAuditReport).

Runtime : ce que Trivy ne fait PAS

Trivy s’arrête au déploiement. Il ne détecte pas les comportements anormaux à l’exécution, les exploits zero-day en cours d’utilisation, ni les escalades de privilèges runtime. C’est le rôle de Falco, que je traiterai dans le prochain article.

Surveillance Kubernetes continue

Le Trivy Operator est, à mon avis, la brique la plus sous-exploitée de l’écosystème. Une fois déployé dans un cluster, il :

scanne automatiquement chaque pod nouvellement créé ;
rescanne périodiquement les workloads existants pour détecter les CVE publiées après le déploiement ;
expose des métriques Prometheus consommables par Grafana ;
permet de router les alertes vers Slack, PagerDuty, Microsoft Teams ou un SIEM via webhook.

On peut le coupler avec des dashboards Grafana qui montrent l’évolution des vulnérabilités par namespace. C’est ce qui transforme Trivy d’outil ponctuel en capteur de sécurité continu.

Bonnes pratiques d’usage en 2026

Voici les pratiques que je considère désormais comme un minimum viable côté équipes — la plupart sont des principes supply chain génériques, simplement appliqués au cas Trivy :

Pinner les actions et images par SHA, jamais par tag ni par branche. Cela vaut pour aquasecurity/trivy-action comme pour toute dépendance CI.
Vérifier les signatures Cosign des binaires et images, idéalement de manière automatisée avant exécution.
Maintenir un miroir interne de la base trivy-db pour ne pas dépendre d’un dépôt public en cas d’incident, et pour des raisons de performance.
Documenter chaque entrée d’un fichier .trivyignore : CVE, justification métier, date d’ajout, date de revue prévue. Sans ce process, le fichier devient une poubelle qui masque les vrais risques.
Différencier les seuils par environnement : tolérance zéro CRITICAL en production, tolérance limitée HIGH en staging, alerte non bloquante MEDIUM en développement.
Croiser avec un second scanner (Grype, Snyk ou commercial) pour réduire les angles morts liés à la qualité ou au délai des advisories , pas pour douter de Trivy, mais pour ne dépendre d’aucune source unique.
Bannir pull_request_target sur tout workflow qui checkout le code d’une PR. C’est précisément la faille exploitée en mars 2026, et elle existe encore dans des centaines de projets internes.

Limites et angles morts

Je suis un grand utilisateur de Trivy, et précisément parce que je le recommande, je tiens à être clair sur ce qu’il ne fait pas , ces limites ne sont pas spécifiques à Trivy, elles sont structurelles à la catégorie « scanner statique de vulnérabilités » :

Pas de détection runtime. Une fois l’image démarrée, Trivy ne voit plus rien. Falco prend le relais.
Faux positifs fréquents sur les dépendances de développement non embarquées en production. D’où l’importance d’un .trivyignore documenté.
Dépendance à la qualité des advisories. Trivy agrège plusieurs sources (NVD, GHSA, OSV, advisories distributions). Une CVE non encore publiée est invisible — pour Trivy comme pour ses concurrents.
Pas de contexte d’exploitabilité. Une CRITICAL dans une lib non importée à l’exécution n’a pas le même impact réel qu’une CRITICAL dans le chemin critique. L’EPSS et l’analyse de reachability (offerts par Snyk ou Endor Labs) restent des compléments utiles.
Comme tout outil tiers, il fait partie de votre supply chain. L’incident de mars 2026 le rappelle : un scanner s’intègre avec les mêmes précautions qu’une dépendance applicative ,pinning, signatures, miroir, monitoring.

À retenir

À retenir 📌

✓ Trivy reste l'un des meilleurs scanners open source en 2026 ; le sujet n'est pas de le remplacer, mais d'aligner son usage sur les standards supply chain (pinning par SHA, Cosign, miroir DB)
✓ L'incident Aqua de mars 2026 est avant tout une leçon d'hygiène CI/CD applicable à toutes les équipes : la même faille `pull_request_target` existe dans des centaines de dépôts internes
✓ Défense en profondeur : pre-commit, CI, registre, admission K8s, runtime ; Trivy couvre les quatre premières étapes, Falco prend le relais sur la dernière
✓ Compléter Trivy avec Grype ou un scanner commercial réduit les angles morts liés aux advisories manquantes ou tardives ; c'est de la défense en profondeur, pas de la défiance
✓ Le Trivy Operator transforme un scanner ponctuel en capteur de sécurité continu pour Kubernetes ; à coupler avec Prometheus et un canal d'alerting
✓ Bannir `pull_request_target` sur les workflows qui checkout le code de la PR : c'est le pattern « Pwn Request » qui a coûté le dépôt à Aqua

Quelques références pour aller plus loin

Sur l’incident Aqua / Trivy :

Trivy compromis : quand le scanner de vulnérabilités devient la vulnérabilité — analyse complète de l’incident (blog Mais Encore)

Articles connexes du blog :

Documentation officielle et écosystème :

Référentiels et bonnes pratiques :