Trivy : Scanner de Vulnérabilités Cloud-Native 2026

Trivy est le scanner de vulnérabilités open source le plus largement adopté de l'écosystème cloud-native, développé et maintenu par Aqua Security depuis 2019, distribué sous licence Apache 2.0 et capable d'analyser en quelques secondes des images de conteneurs, des systèmes de fichiers, des dépôts Git, des manifestes Kubernetes, des modules Terraform, des templates AWS CloudFormation, des Dockerfiles, des charts Helm, des SBOM CycloneDX/SPDX, ainsi que les comptes AWS et clusters Kubernetes en production. En 2026, Trivy dépasse les 26 000 étoiles GitHub et s'impose comme le scanner par défaut dans la plupart des pipelines CI/CD modernes (GitHub Actions, GitLab Security, Jenkins, CircleCI, Azure DevOps), supplantant les solutions historiques telles que Clair ou Anchore Engine grâce à son installation triviale (brew install trivy ou binaire statique de 60 Mo), sa base de vulnérabilités Trivy DB mise à jour toutes les six heures, et son extension Trivy Operator qui industrialise la sécurité Kubernetes via des CRD (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport). Ce guide entity-first détaille l'historique du projet, ses capacités de scan, ses bases de vulnérabilités, la génération et l'analyse de SBOM, la détection de mauvaises configurations IaC, le secret scanning, la conformité licence, les intégrations CI/CD, le Trivy Operator, son positionnement face à Grype, Snyk, Clair et Anchore, ainsi que ses limites et cas d'usage DevSecOps.

Définition : qu'est-ce que Trivy ?

Trivy est un scanner de vulnérabilités et d'exposition de sécurité open source, écrit en Go, conçu pour identifier les CVE connues, les mauvaises configurations Infrastructure-as-Code, les secrets exposés et les problèmes de conformité licence dans les artefacts modernes du développement logiciel : images de conteneurs, dépôts Git, systèmes de fichiers locaux, manifestes Kubernetes, modules Terraform, templates AWS CloudFormation, charts Helm et SBOM. Le projet se positionne comme un all-in-one security scanner : là où la concurrence scinde traditionnellement les outils par périmètre (Grype pour les CVE, Checkov pour l'IaC, Gitleaks pour les secrets, Syft pour les SBOM), Trivy unifie ces fonctionnalités en une seule CLI sans dépendances. Cette philosophie en fait l'outil de prédilection des équipes DevSecOps qui veulent shift-left la sécurité dès la phase de build, sans imposer d'orchestrateur lourd ni de licence commerciale.

Contrairement aux scanners commerciaux (Snyk, Prisma Cloud, Aqua Enterprise, Wiz) qui exigent une plateforme SaaS et une facturation par image scannée ou par développeur, Trivy est totalement gratuit, sans télémétrie obligatoire, et exécutable en mode air-gap dans les environnements souverains ou OIV. Le binaire pèse environ 60 Mo, démarre instantanément, et embarque sa propre base de vulnérabilités locale (Trivy DB) téléchargée depuis un registre OCI public (ghcr.io/aquasecurity/trivy-db). Cette architecture cache-first permet de scanner des centaines d'images dans un pipeline CI sans solliciter d'API externe à chaque exécution, et garantit une exécution déterministe et reproductible. Trivy est officiellement intégré au CNCF Landscape dans la catégorie Security & Compliance (Sandbox depuis 2024), et fait partie des outils recommandés par la NSA Kubernetes Hardening Guide et le CIS Kubernetes Benchmark.

Historique : d'Aqua Security 2019 à Trivy 0.62 en 2026

Trivy a été initialement développé par Teppei Fukuda (knqyf263), ingénieur japonais, et publié en open source en mai 2019. Quelques mois après sa publication, le projet attire l'attention d'Aqua Security, éditeur israélien spécialisé dans la sécurité conteneurs, qui acquiert le projet en septembre 2019 et embauche son créateur. Cette acquisition transforme Trivy en projet phare de l'écosystème CNCF cloud-native et bénéficie de l'investissement R&D d'Aqua. En 2020, GitHub intègre Trivy dans GitHub Actions via l'action officielle aquasecurity/trivy-action, ce qui catalyse son adoption massive. La même année, GitLab sélectionne Trivy comme moteur de son Container Scanning dans GitLab Security, en remplacement de Clair (sortie de Clair v3 problématique).

Les versions clés ont été : Trivy 0.16 (2020) avec scan filesystem ; Trivy 0.20 (2021) avec scan IaC (Terraform, CloudFormation) ; Trivy 0.30 (2022) avec secret scanning intégré ; Trivy 0.40 (2023) avec SBOM CycloneDX/SPDX ; Trivy 0.50 (2024) avec scan AWS et Kubernetes cluster mode ; Trivy 0.55 (2025) avec VEX (Vulnerability Exploitability eXchange) support et signatures Sigstore. La version 0.62 (avril 2026) apporte une refonte du moteur misconfiguration basé sur Rego/OPA via le projet sœur Trivy-Checks, l'intégration native EPSS (Exploit Prediction Scoring System) pour prioriser les CVE selon leur probabilité d'exploitation réelle, et le support des images distroless Google et Wolfi Chainguard. Aqua continue de maintenir Trivy en open-source OSS-first, tout en commercialisant Aqua Platform (l'offre enterprise) et Aqua Trivy Premium (Trivy avec feeds vulnérabilités exclusifs et support 24/7).

Capacités de scan : 7 cibles, 5 catégories de findings

Trivy scanne sept types de cibles distinctes via des sous-commandes dédiées : trivy image (images Docker/OCI locales ou en registre), trivy fs (système de fichiers et code source), trivy repo (dépôts Git distants ou locaux), trivy k8s (cluster Kubernetes complet via kubeconfig), trivy aws (compte AWS via APIs), trivy sbom (analyse d'un SBOM CycloneDX ou SPDX existant) et trivy config (fichiers de configuration IaC isolés). Pour chaque cible, Trivy produit jusqu'à cinq catégories de findings : (1) vulnerabilities (CVE dans les paquets OS et libraries), (2) misconfigurations (erreurs IaC selon CIS, NSA, custom Rego), (3) secrets (clés API, tokens, mots de passe en clair), (4) licenses (compliance copyleft GPL/AGPL/LGPL), et (5) SBOM (génération inventaire dépendances).

L'orchestration combinée s'invoque via les flags --scanners vuln,misconfig,secret,license, ce qui permet de produire un rapport unifié pour une image ou un dépôt en une seule commande. Cette approche multi-scanner réduit considérablement le nombre d'outils à maintenir dans un pipeline CI/CD, comparé à une stack hétérogène Grype + Checkov + Gitleaks + Syft. Pour aller plus loin sur l'audit complet d'un pipeline, voir notre guide Audit sécurité pipeline CI/CD : SAST, DAST, SCA.

Targets supportés : Docker, OCI, Kubernetes, AWS, IaC

Trivy supporte une matrice de cibles particulièrement large, ce qui en fait un couteau suisse pour la sécurité cloud-native. Pour les images de conteneurs, Trivy lit les formats Docker (v1, v2, OCI), Podman, Buildah, Singularity (SIF), et peut puller depuis n'importe quel registre OCI (Docker Hub, Amazon ECR, Google Artifact Registry, Azure Container Registry, GitHub Container Registry, Harbor, Quay, GitLab Registry). Le scan est layer-aware : Trivy identifie quelle couche introduit chaque vulnérabilité, ce qui aide les développeurs à comprendre s'il faut modifier le Dockerfile ou simplement updater une FROM.

Pour Kubernetes, Trivy peut scanner un cluster entier (trivy k8s --report all cluster) ou un namespace spécifique, en énumérant tous les workloads (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Pods) et en scannant leurs images, leurs RBAC, leurs Pod Security Standards, leurs NetworkPolicies. Pour AWS, trivy aws énumère via SDK les services S3, EKS, ECR, IAM, CloudTrail, Lambda, RDS, EC2, et applique les benchmarks CIS AWS Foundations. Côté Infrastructure-as-Code, Trivy parse Terraform (HCL2 et plan JSON), OpenTofu, AWS CloudFormation (YAML/JSON), Azure ARM/Bicep, Google Cloud Deployment Manager, Helm charts (rendu et brut), Kustomize overlays, Dockerfile et GitHub Actions workflows. Cette couverture large permet d'utiliser Trivy comme policy gate unique en pre-commit hook, en pull request CI, et en runtime via Trivy Operator.

Modes de scan : image, fs, repo, k8s, sbom, config, secret

La CLI Trivy expose des sous-commandes orthogonales, chacune optimisée pour un workflow précis. Le mode trivy image est le plus utilisé : il accepte une référence d'image (avec ou sans tag), pulle si nécessaire, extrait les couches, parse les métadonnées de l'OS (Alpine, Debian, Ubuntu, RHEL, AmazonLinux, Photon, SUSE, Wolfi, Chainguard), inspecte les dépendances applicatives (npm, pip, Maven, Gradle, Go modules, Cargo, Composer, Bundler, Conan, Pub, Swift), et croise tout cela avec la Trivy DB. Le mode trivy fs . scanne un répertoire local, idéal pour le pre-commit hook ou l'analyse d'un projet en dev avant push. trivy repo https://github.com/... clone temporairement un dépôt Git et le scanne, sans nécessiter de Docker daemon, ce qui est pratique pour des audits ad-hoc.

Le mode trivy k8s utilise le kubeconfig courant pour énumérer les workloads et appliquer une chaîne de scans : images des containers, manifests YAML rendus, RBAC du cluster, Pod Security Standards. Le mode trivy sbom consomme un SBOM existant (CycloneDX, SPDX, SPDX-JSON) et produit une analyse de vulnérabilités, sans avoir besoin de l'image source : utile pour les organisations qui gèrent une chaîne d'approvisionnement avec SBOM signés au build time. Les modes trivy config et trivy secret sont des sous-ensembles de trivy fs, dédiés respectivement à l'analyse IaC seule ou à la détection de secrets seule. Tous ces modes partagent les flags communs : --severity HIGH,CRITICAL, --ignore-unfixed, --exit-code 1, --format sarif, --output report.json, ce qui simplifie la composition dans un pipeline.

Bases de vulnérabilités : Trivy DB, NVD, GHSA, OSV, vendors

La force de Trivy réside dans sa Trivy DB, une base de vulnérabilités agrégée et prétraitée, distribuée sous forme d'image OCI publique (ghcr.io/aquasecurity/trivy-db) téléchargée à chaque scan (cache local 24h par défaut). Cette base agrège plus de quinze sources : NVD (National Vulnerability Database NIST), GitHub Security Advisories (GHSA), OSV (Open Source Vulnerabilities Google), Red Hat Security Data API, Debian Security Tracker, Ubuntu CVE Tracker, Alpine secdb, Amazon Linux Security Center, SUSE OVAL, Photon OS, Wolfi advisories, Chainguard advisories, Rocky Linux, AlmaLinux, Oracle Linux. Chaque entrée est dédupliquée, normalisée au format CVE-YYYY-NNNNN, scoring CVSSv3.x et v4 quand disponible, et enrichie de métadonnées vendor (fixed version, severity vendor, advisory URL).

Cette agrégation offre un taux de couverture supérieur à NVD seul, particulièrement pour les paquets Linux où les vendor advisories sont plus précis sur les fixed versions spécifiques au backport (ex: une CVE patchée dans openssl 1.1.1k-1ubuntu0.4 alors que NVD ne mentionne que la version upstream 3.0). Trivy applique une logique de vendor preference : si une CVE existe dans NVD ET dans Red Hat Security Data, c'est l'entrée Red Hat qui prime pour les paquets Red Hat, ce qui réduit fortement les faux positifs. Depuis Trivy 0.55, la base inclut également les scores EPSS (Exploit Prediction Scoring System) de FIRST.org, indiquant la probabilité (0 à 1) qu'une CVE soit exploitée dans les 30 jours, et les indicateurs CISA KEV (Known Exploited Vulnerabilities Catalog) pour identifier les CVE activement exploitées. Cette enrichissement est crucial pour passer d'un mode scan-and-pray à une priorisation rationnelle.

SBOM : génération et analyse CycloneDX, SPDX

Trivy est l'un des rares outils open source à générer ET consommer des SBOM (Software Bill of Materials) dans les deux formats standards : CycloneDX 1.5/1.6 (porté par OWASP) et SPDX 2.3 / 3.0 (porté par la Linux Foundation). La génération s'effectue via trivy image --format cyclonedx --output sbom.json myimage:latest ou trivy fs --format spdx-json --output sbom.spdx ./myproject. Le SBOM produit liste les composants OS, applicatifs, et leurs hashes, ce qui répond aux exigences réglementaires de l'Executive Order 14028 (USA), du Cyber Resilience Act (CRA) européen et de la directive NIS2 qui imposent la fourniture d'un SBOM pour tout logiciel commercialisé.

L'analyse de SBOM via trivy sbom existing-sbom.json est un cas d'usage de plus en plus courant : une équipe d'éditeur signe son SBOM au build time (cosign attest), le distribue avec l'image, et le client peut re-scanner ce SBOM contre la dernière Trivy DB sans accès à l'image source. Cette approche découple la phase de production du logiciel et la phase de surveillance vulnérabilités, et permet un continuous monitoring sans pull d'image. Trivy supporte également l'attestation VEX (Vulnerability Exploitability eXchange) qui permet à l'éditeur de déclarer formellement qu'une CVE n'est pas exploitable dans son contexte (par exemple, fonction non utilisée), réduisant le bruit pour les opérateurs en aval. Le format OpenVEX est supporté nativement depuis Trivy 0.50.

Misconfigurations IaC : CIS, NSA, Terraform, Kubernetes

Trivy intègre Trivy-Checks (anciennement Defsec, projet open source maintenu par Aqua), une bibliothèque de plus de 500 règles Rego détectant les mauvaises configurations dans les manifests IaC. Les benchmarks couverts incluent : CIS Docker Benchmark, CIS Kubernetes Benchmark v1.9, CIS AWS Foundations Benchmark, CIS Azure Benchmark, CIS GCP Benchmark, NSA/CISA Kubernetes Hardening Guidance, NIST 800-53/190, Pod Security Standards (Privileged, Baseline, Restricted), HIPAA, PCI DSS. Pour Kubernetes, Trivy détecte les workloads sans readOnlyRootFilesystem, les conteneurs privileged: true, l'absence de resources.limits, les ServiceAccounts trop larges, les RBAC bindings sur ClusterRole admin.

Pour Terraform, Trivy détecte les ressources S3 sans encryption, les Security Groups 0.0.0.0/0 sur SSH/RDP, les RDS sans backup, les IAM policies *:*, les KMS sans rotation, les CloudFront sans HTTPS forcé. Pour CloudFormation, des règles équivalentes s'appliquent. Le moteur de règles est extensible : les organisations peuvent écrire leurs propres politiques en Rego (langage OPA — Open Policy Agent), les distribuer via un registre OCI --config-policy registry/policies:tag, et les versionner dans Git pour le Policy-as-Code. Cette approche s'intègre parfaitement avec les pipelines GitOps (ArgoCD, FluxCD) où chaque pull request déclenche une validation Trivy avant merge. Pour approfondir la sécurisation des clusters, voir Kubernetes RBAC : guide de sécurisation et notre offre Audit Kubernetes.

Secrets detection : regex, entropy, custom rules

Le module secret scanning de Trivy utilise une combinaison de patterns regex pré-définis (~150 patterns couvrant AWS Access Keys, AWS Secret Keys, Google Cloud SA Keys, Azure SP credentials, GitHub PAT, GitLab tokens, Slack webhooks, Stripe keys, Twilio keys, JWT tokens, RSA/SSH private keys) et d'un calcul d'entropie de Shannon pour détecter les chaînes aléatoires non listées explicitement. La détection est rapide (binaire compilé en Go), avec un taux de faux positifs comparable à Gitleaks ou TruffleHog. Trivy scanne par défaut tous les types de fichiers texte ; l'exclusion de chemins ou de patterns spécifiques s'effectue via .trivyignore ou un fichier de configuration trivy-secret.yaml.

Les règles personnalisées sont définies en YAML, avec champs id, category, title, severity, regex, keywords, path, et allowlist. Cette extensibilité permet à une organisation de détecter ses propres conventions de secrets internes (tokens d'API maison, certificats de signature CI). En 2026, Trivy peut également scanner les git history via trivy repo --scanners secret, ce qui débusque les secrets commités puis supprimés en surface mais toujours dans l'historique. Pour une remédiation complète, il est recommandé de combiner Trivy avec BFG Repo Cleaner ou git-filter-repo pour effacer définitivement les secrets de l'historique, et avec un coffre-fort (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) pour la gestion des secrets en production.

License scanning : compliance copyleft

Trivy embarque un scanner de licences logicielles qui inventorie les licences déclarées dans les paquets et signale celles incompatibles avec une politique d'organisation (ex: GPLv3, AGPLv3 interdites pour un produit propriétaire commercial). Le scanner identifie environ 60 licences SPDX standards via parsing des champs License dans les manifestes (package.json, pyproject.toml, pom.xml, go.mod, Cargo.toml, RubyGems gemspec) ainsi que les fichiers LICENSE et COPYING via fingerprinting. La sortie classe les résultats en quatre niveaux : FORBIDDEN, RESTRICTED, RECIPROCAL, NOTICE, PERMISSIVE, UNENCUMBERED, UNKNOWN.

Cette fonctionnalité est précieuse pour les éditeurs de logiciels commerciaux qui doivent prouver à leurs clients la conformité de leur stack open source, notamment dans les secteurs régulés (banque, défense, santé). Elle s'intègre également dans les démarches de conformité OpenChain (ISO/IEC 5230) qui imposent la traçabilité des licences dans la supply chain. Trivy peut alimenter automatiquement un Defectdojo ou un OWASP Dependency Track avec les données de licence pour orchestrer la gouvernance.

Intégrations CI/CD : GitHub Actions, GitLab, Jenkins, Azure DevOps

Trivy s'intègre nativement à toutes les plateformes CI/CD majeures. Pour GitHub Actions, l'action officielle aquasecurity/trivy-action@master est utilisée par plus de 200 000 dépôts publics en 2026 ; elle scanne images, filesystems, configs, et exporte les résultats au format SARIF directement consommé par GitHub Code Scanning, ce qui affiche les vulnérabilités dans l'onglet Security du dépôt et les annotations de pull request. Pour les supply chain modernes, voir notre guide dédié Trivy + GitHub Actions : supply chain 2026.

Pour GitLab CI, Trivy est le moteur intégré du Container Scanning dans le template Container-Scanning.gitlab-ci.yml ; les résultats sont remontés dans la Security Dashboard et le Vulnerability Report du projet GitLab. Pour Jenkins, le plugin Trivy ou un simple sh "trivy image ..." dans une étape Jenkinsfile suffit, avec publication des résultats via le plugin Warnings Next Generation. Pour CircleCI, l'orb circleci/trivy est disponible. Pour Azure DevOps, l'extension Aqua Security Trivy Marketplace ajoute une task build pipeline dédiée. Pour Bitbucket Pipelines, la pipe officielle aquasecurity/trivy-pipe existe. Tous ces environnements supportent le format SARIF de sortie pour intégration avec les plateformes de gestion de vulnérabilités (DefectDojo, ThreadFix, Faraday, OWASP Dependency Track). Pour bâtir un pipeline DevSecOps complet, consultez DevSecOps cloud : pipeline CI/CD sécurisé.

Trivy Operator : sécurité Kubernetes continue via CRD

Le Trivy Operator est une extension Kubernetes qui industrialise le scan continu d'un cluster en production. Déployé via Helm chart aqua/trivy-operator, il installe un opérateur (Deployment) qui watche en permanence les ressources du cluster et déclenche des jobs de scan à chaque création ou modification de workload. Les résultats sont stockés dans des CRD (Custom Resource Definitions) dédiés : VulnerabilityReport (CVE par container), ConfigAuditReport (mauvaises configs Pod), ExposedSecretReport (secrets exposés dans env vars ou ConfigMap), RbacAssessmentReport (audit RBAC), InfraAssessmentReport (audit master/node config), ClusterComplianceReport (CIS/NSA cluster-wide).

L'opérateur expose ses métriques au format Prometheus (trivy_image_vulnerabilities, trivy_resource_configaudits) ce qui permet d'alerter automatiquement sur l'apparition d'une CVE Critical via Alertmanager. Une intégration native avec Lens IDE, Octant, et Headlamp affiche les rapports directement dans l'UI. Le Trivy Operator peut également alimenter en flux push un OpenSearch ou Elasticsearch via webhook pour la corrélation centralisée. Couplé à Falco pour la détection runtime cloud-native, on obtient une couverture défense en profondeur : Trivy détecte les vulnérabilités statiques avant et pendant le déploiement, Falco détecte les comportements dynamiques anormaux à l'exécution. Cette dualité est désormais la norme dans les architectures Kubernetes matures.

Comparatif : Trivy vs Grype vs Snyk vs Clair vs Anchore

En résumé : Trivy domine sur le scope fonctionnel le plus large (vuln + IaC + secrets + license + SBOM), avec des performances équivalentes à Grype mais une couverture nettement supérieure. Grype, qui partage une partie de son code avec Syft, reste un excellent choix si l'on veut un outil minimaliste limité aux vulnérabilités. Snyk brille sur l'expérience développeur et la priorisation contextuelle propriétaire (Snyk Priority Score), au prix d'un coût élevé par développeur. Clair, historiquement intégré à Quay et OpenShift, accuse un retard fonctionnel mais reste utilisé dans certains environnements Red Hat. Anchore Enterprise vise les très grands comptes avec des besoins de gouvernance et de policy avancés (workflow d'approbation, intégration JIRA, dashboards exécutifs).

Performance et faux positifs : optimisations 2026

Les performances de Trivy en 2026 atteignent un niveau remarquable grâce à plusieurs optimisations cumulées. Une image Alpine 3.20 (~7 Mo, 17 paquets) se scanne en 1,5 seconde sur un MacBook M3 ; une image Python:3.13-slim (~125 Mo) en 4 secondes ; une image OpenJDK 21 Spring Boot (~800 Mo) en 10 à 15 secondes. Le démarrage à froid (cold start) de la CLI est inférieur à 200 ms, et le cache local de la Trivy DB (~/.cache/trivy, ~150 Mo décompressé) permet de scanner des centaines d'images dans un pipeline sans solliciter le réseau. Pour les pipelines CI massifs, l'option --server permet de déployer Trivy en mode client/serveur, avec un seul serveur partageant la DB pour des dizaines de workers, économisant énormément de bande passante.

Côté faux positifs, Trivy en a historiquement été accusé sur certaines distributions, mais la situation s'est largement améliorée depuis 2024 grâce à : (1) la prise en compte des vendor advisories qui surclassent les entrées NVD génériques, (2) le VEX support qui permet aux éditeurs d'attester l'inexploitabilité d'une CVE dans leur produit, (3) le --ignore-unfixed qui exclut automatiquement les CVE sans patch disponible (réduit le bruit de 30 à 50%), et (4) l'enrichissement EPSS et CISA KEV pour prioriser. Une bonne pratique consiste à filtrer le rapport en --severity HIGH,CRITICAL --ignore-unfixed en CI, et à conserver le rapport complet en revue trimestrielle pour les CVE LOW/MEDIUM. Le fichier .trivyignore ou .trivyignore.yaml centralise les exceptions documentées.

Cas d'usage : DevSecOps shift-left, runtime, supply chain

Les cas d'usage de Trivy en 2026 couvrent l'ensemble du cycle de vie logiciel. (1) Shift-left development : intégration Trivy en pre-commit hook (pre-commit-hooks/trivy), en IDE plugin (VSCode, JetBrains), ou en GitHub Actions sur chaque pull request, pour bloquer le merge si une CVE Critical apparaît. (2) Build time : scan des images dans le pipeline avant push registry, avec quality gate (--exit-code 1 --severity CRITICAL). (3) Runtime Kubernetes : Trivy Operator déployé dans tous les clusters (dev, staging, prod), avec rapports CRD consultés via kubectl get vuln et exposés en Prometheus pour alerting. (4) Supply chain : génération SBOM signé Sigstore au build time, distribution avec l'image, scan continu du SBOM par les clients en aval. (5) Compliance : audits CIS/NSA Kubernetes périodiques via trivy k8s --compliance k8s-cis avec exports HTML/PDF pour les auditeurs.

Un cas d'usage emblématique en 2026 est l'audit cloud souverain : Trivy étant exécutable en mode air-gap (téléchargement préalable de la DB OCI, exécution offline ensuite), il s'adapte parfaitement aux environnements SecNumCloud ANSSI, aux clouds étatiques (TchapCloud, S3NS Bleu, Sens), et aux infrastructures OIV où aucune télémétrie sortante n'est tolérée. Cette caractéristique le distingue des solutions SaaS commerciales (Snyk, Wiz, Aqua Platform) qui exigent une connectivité Internet permanente vers leurs backends. Pour un pentest ou audit complet, voir notre offre audit Kubernetes et explorer nos datasets de cybersécurité.

Limites et contraintes : couverture, signature, ML

Malgré ses qualités, Trivy présente plusieurs limites à connaître. (1) Couverture langagière : si Trivy supporte les principaux écosystèmes (npm, pip, Maven, Gradle, Go, Cargo, Composer, Bundler, NuGet), certains langages de niche (Erlang, Crystal, Nim, Zig) sont peu ou pas couverts ; pour ces écosystèmes, des scanners dédiés ou des SCA payants restent supérieurs. (2) Pas de scan de signature natif au sens code mining : Trivy ne fait pas de SAST sur le code source applicatif (au contraire de SonarQube, Semgrep, CodeQL) ; il se limite à l'analyse de dépendances et de configurations. (3) Faux positifs résiduels sur les images custom non basées sur des distributions standards (par exemple, des images scratch avec compilation manuelle), où le matching de versions est moins fiable.

Autres limites : (4) Pas d'intelligence ML propriétaire de priorisation contextuelle équivalente à Snyk Priority Score ou Wiz Cloud-Sec Graph ; Trivy se repose sur les scores publics CVSS/EPSS/KEV, ce qui peut donner moins de finesse pour des organisations matures. (5) Pas de runtime defense : Trivy est strictement statique ; pour la détection à l'exécution (anomalies syscall, escape container), il faut le coupler avec Falco ou Tetragon. (6) UI limitée : Trivy n'a pas d'interface web propre ; les rapports se consomment en CLI, JSON, SARIF, HTML statique, ou via Defectdojo/Dependency Track. Pour une UI complète et le gouvernance, l'offre commerciale Aqua Platform est la voie naturelle d'évolution.

Bonnes pratiques de déploiement

L'adoption de Trivy gagne à suivre quelques bonnes pratiques éprouvées. Pinner la version de la CLI Trivy dans les pipelines CI (aquasecurity/trivy-action@v0.62.0 plutôt que @master) pour éviter les régressions surprise. Mettre en cache la Trivy DB entre les jobs CI via le cache Actions/GitLab pour éviter le téléchargement répété (gain de 5 à 10 secondes par run). Définir des seuils de sévérité gradués par environnement : block sur CRITICAL en prod, warn sur HIGH en staging, log sur MEDIUM en dev. Exclure .git, node_modules, vendor du scan filesystem via .trivyignore pour les performances.

Pour les organisations matures : déployer un Trivy Server central (trivy server --listen :4954) qui maintient une seule DB partagée par tous les workers CI ; signer les SBOM générés avec Cosign et stocker les attestations dans un registre OCI ; alimenter Defectdojo ou OWASP Dependency Track en push des résultats SARIF pour la consolidation cross-projets ; configurer des règles Rego custom dans un dépôt Git séparé, distribué en OCI artifact, pour le policy-as-code versionné. Enfin, monitorer la fraîcheur de la Trivy DB via les métriques du Trivy Operator pour s'assurer qu'aucun cluster n'utilise une base de plus de 24h, ce qui réduirait la pertinence des détections récentes.

Foire aux questions

Quelle différence entre Trivy et Grype ?

Trivy et Grype sont tous deux des scanners de vulnérabilités open source en Go, mais avec des philosophies différentes. Grype (Anchore) se concentre exclusivement sur le scan de vulnérabilités dans les images et systèmes de fichiers, en s'appuyant sur Syft (du même éditeur) pour la génération de SBOM. Trivy (Aqua) est un scanner all-in-one qui couvre vulnérabilités, misconfigurations IaC, secrets, licences et SBOM dans un seul binaire. En pratique, les deux ont des performances et une couverture vulnérabilités très proches ; Trivy l'emporte sur le scope fonctionnel élargi et l'écosystème (Trivy Operator, intégrations cloud), tandis que Grype reste apprécié pour sa simplicité minimaliste lorsqu'on veut juste scanner les CVE.

Trivy est-il vraiment 100% gratuit ?

Oui, le projet Trivy est open source sous licence Apache 2.0, sans restriction d'usage commercial, sans télémétrie obligatoire, sans paywall sur les fonctionnalités principales. La Trivy DB publique est également gratuite et téléchargeable sans authentification. Aqua propose en parallèle Aqua Trivy Premium (offre commerciale) qui ajoute des feeds de vulnérabilités exclusifs (avec des CVE détectées plus tôt que la base publique), un support 24/7 et des SLA contractuels, mais ces offres sont totalement optionnelles et la version gratuite reste pleinement fonctionnelle pour la majorité des cas d'usage.

Peut-on scanner des images de production avec Trivy ?

Absolument, Trivy est conçu pour scanner aussi bien des images en pré-production que des images live en runtime via le Trivy Operator Kubernetes. Le scan est entièrement non intrusif : Trivy ne s'exécute jamais dans le container scanné, il en lit uniquement les couches en lecture seule. Pour les images privées, Trivy supporte l'authentification Docker config (~/.docker/config.json), les secrets imagePullSecrets Kubernetes, et l'authentification cloud native (IRSA AWS, Workload Identity GCP, Managed Identity Azure). Pour les contraintes air-gap, la base peut être pré-téléchargée et chargée offline.

Trivy peut-il fonctionner comme admission controller Kubernetes ?

Oui, le Trivy Operator peut être combiné avec un admission controller (typiquement Kyverno ou OPA Gatekeeper) qui consulte les VulnerabilityReport CRD avant d'autoriser un déploiement. Concrètement, Kyverno peut interdire la création d'un Pod si l'image associée présente un VulnerabilityReport avec des CVE de sévérité Critical. Une autre approche est l'usage de Trivy Plugin Krew ou de webhooks custom appelant trivy image en mode bloquant. Pour une intégration plus poussée, l'écosystème Aqua Enforcer (commercial) propose un admission controller dédié.

Trivy supporte-t-il les containers Windows ?

Le support Windows containers est partiel. Trivy peut scanner les images Windows pour détecter les paquets Chocolatey, les modules PowerShell, et les CVE applicatives (Java, Node.js, Python embarqués), mais la couverture des vulnérabilités OS Windows reste limitée comparée aux distributions Linux supportées. Microsoft ne publie pas de Security Data API équivalente à Red Hat OVAL ou Debian Security Tracker, ce qui réduit la précision. Pour les workloads Windows critiques, des scanners spécialisés Windows (Microsoft Defender for Cloud, Tenable, Qualys) restent plus pertinents en complément de Trivy pour la couche applicative.

Comment intégrer Trivy avec Defectdojo ou Dependency Track ?

L'intégration s'effectue via export SARIF ou JSON. Pour OWASP Defectdojo, exécuter trivy image --format json --output report.json myimage puis uploader via l'API Defectdojo (endpoint /api/v2/import-scan/ avec scan_type=Trivy Scan). Pour OWASP Dependency Track, exporter en CycloneDX (--format cyclonedx) et uploader via l'API /api/v1/bom. Les deux plateformes consolident ensuite les vulnérabilités cross-projets, attribuent des owners, suivent les remédiations et alimentent des dashboards exécutifs. Cette boucle ferme le cycle DevSecOps en transformant les rapports CI bruts en gouvernance vulnérabilités à l'échelle de l'organisation.

Liens approfondis

Pour aller plus loin, consultez nos guides connexes : Audit sécurité pipeline CI/CD : SAST, DAST, SCA, Kubernetes RBAC : guide de sécurisation, DevSecOps cloud : pipeline CI/CD sécurisé, Trivy + GitHub Actions : supply chain 2026, Falco : détection runtime cloud-native CNCF, ainsi que nos offres audit Kubernetes et nos datasets de cybersécurité open data. Les ressources officielles externes : trivy.dev (documentation officielle Aqua), github.com/aquasecurity/trivy (code source et issues), aquasec.com (page produit éditeur).