Trivy est un scanner de vulnérabilités open-source développé par Aqua Security (licence Apache 2.0, ~23 000 stars GitHub fin 2024), devenu en quelques années l'outil de référence du DevSecOps 2024-2025 pour 7 cas d'usage couverts par un seul binaire Go : scan de containers (CVE sur packages Alpine, Debian, RHEL, distroless), scan de dépendances applicatives (npm, PyPI, Maven, Go modules, Rubygems, Cargo, Composer, NuGet), scan Infrastructure-as-Code (Terraform, Helm charts, Kubernetes manifests, Dockerfile, CloudFormation, Ansible), scan de secrets (AWS keys, tokens, clés privées), compliance (CIS Benchmarks, DoD STIG), génération SBOM au format CycloneDX et SPDX, et scan de clusters Kubernetes en continu via le Trivy Operator. Cet article détaille ce que fait Trivy exactement avec exemples de commandes concrètes, son architecture interne (base de vulnérabilités multi-sources : NVD, GHSA, OSV, Bitnami VDB, Red Hat VEX, Alpine secdb), les patterns d'intégration CI/CD (GitHub Actions, GitLab CI, Jenkins), le Trivy Operator pour scanner un cluster live, la génération SBOM SLSA-compatible, le comparatif honnête avec Grype (Anchore), Snyk, Clair, Docker Scout, les 5 limites documentées à connaître avant déploiement, et les patterns de tuning pour maîtriser les faux positifs et les performances. Pour le positionnement général de ces outils dans un pipeline, voir SAST vs DAST vs IAST et Étapes pour devenir DevSecOps.
1. Qu'est-ce que Trivy exactement
Trivy est un scanner de vulnérabilités unifié, écrit en Go, distribué comme binaire unique (~50 MB) ou image Docker. Il est maintenu par Aqua Security (éditeur cyber US-israélien) sous le repository github.com/aquasecurity/trivy, licence Apache 2.0.
1.1 Genèse et position marché
| Année | Événement |
|---|---|
| 2019 | Création initiale par Teppei Fukuda (Aqua Security) |
| 2020 | Intégration GitLab Container Scanning par défaut |
| 2021 | Ajout scan IaC (rebranding depuis "Trivy CS" vers Trivy complet) |
| 2022 | Ajout scan secrets + Kubernetes Operator |
| 2023 | Support SBOM CycloneDX + SPDX, intégration GitHub Action officielle |
| 2024 | ~23 000 stars GitHub, releases toutes les 2-4 semaines |
| 2025 | Leader SCA open-source devant Grype, Clair |
1.2 Ce qui rend Trivy spécifique
- Un seul binaire pour 7 cas d'usage distincts, alors que la plupart des outils se limitent à 1-2 cas.
- Base de données fusionnée multi-sources (NVD, GHSA, OSV, Bitnami VDB, Red Hat VEX, Alpine secdb) mise à jour 2 fois par jour via GitHub Actions automatisé.
- Zéro dépendance externe en fonctionnement offline (après pull de la DB).
- Format de sortie homogène (table, JSON, SARIF, CycloneDX, SPDX, GitHub, GitLab) facilitant l'intégration CI.
- Intégration officielle GitLab (2022), GitHub (2023), AWS ECR, Azure ACR, Docker Hub.
2. Les 7 types de scans supportés
Périmètre fonctionnel de Trivy 2025
────────────────────────────────────
Types de scan (commande "trivy ...")
image ─► containers Docker / OCI (local, registry, tarball)
filesystem ─► SCA sur un répertoire de code (package managers)
repository ─► SCA + secrets + IaC sur un repo Git distant
kubernetes ─► scan d'un cluster live (workloads + images)
rootfs ─► scan d'un rootfs extrait (Debian package, AMI)
sbom ─► génération SBOM CycloneDX / SPDX
vm ─► scan d'une image VM (AMI AWS, disk image)
Classes détectées par scan
vuln ─► vulnérabilités CVE / GHSA / OSV
misconfig ─► Terraform, Helm, K8s manifests, Dockerfile, CloudFormation
secret ─► AWS keys, tokens, private keys (regexes + contexte)
license ─► scan des licences des dépendances
compliance ─► CIS Benchmark Kubernetes, DoD STIG, PCI-DSS selected2.1 Matrice cas d'usage × classes détectées
| Commande | vuln | misconfig | secret | license | compliance |
|---|---|---|---|---|---|
trivy image | ✓ | - | - | ✓ | - |
trivy fs | ✓ | ✓ | ✓ | ✓ | ✓ |
trivy repo | ✓ | ✓ | ✓ | ✓ | - |
trivy k8s | ✓ | ✓ | - | - | ✓ |
trivy sbom | ✓ (en reverse) | - | - | ✓ | - |
3. Architecture interne : DB + scanners
3.1 La base de vulnérabilités trivy-db
Le binaire Trivy embarque un client qui pull trivy-db (une DB BoltDB embarquée, ~500 MB décompressée) depuis un registry OCI public. Cette DB est construite 2 fois par jour par Aqua depuis 30+ sources :
| Source | Contenu |
|---|---|
| NVD (NIST) | Base officielle CVE, détails techniques |
| GHSA (GitHub Security Advisory DB) | Vulnérabilités écosystème dev (npm, PyPI, etc.) |
| OSV.dev (Google) | Aggregator open source vulnerabilities |
| Bitnami VDB | Charts Helm + containers Bitnami |
| Red Hat VEX | État de correction RHEL / Fedora |
| Alpine secdb | Advisories Alpine Linux |
| Debian Security Tracker | Advisories Debian |
| Ubuntu CVE Tracker | Advisories Ubuntu |
| Amazon Linux Security Center | Advisories AL2 / AL2023 |
| GitLab Advisory DB | Additional sources |
| PhotonOS, Rocky, SUSE, Oracle | Advisories distros spécifiques |
3.2 Architecture de scan
Trivy — flux interne de scan d'une image
─────────────────────────────────────────
1. trivy image myapp:v1.2.3
2. Pull image (depuis registry ou local daemon)
─► décomposition en layers
─► extraction des métadonnées OS + package managers
3. Enumération des packages
─► apk (Alpine), dpkg (Debian/Ubuntu), rpm (RHEL/Fedora)
─► package.json / yarn.lock / pnpm-lock.yaml (Node)
─► Pipfile.lock / requirements.txt / poetry.lock (Python)
─► pom.xml / build.gradle (Java)
─► go.sum (Go), Gemfile.lock (Ruby), Cargo.lock (Rust), etc.
4. Lookup trivy-db
─► matching (name, version) sur les sources pertinentes
─► application VEX (statement de non-exploitabilité)
─► filtrage sévérité et ignored CVE
5. Output
─► table (terminal), JSON, SARIF, CycloneDX, SPDX, etc.4. Installation et premier scan
4.1 Installation
# macOS (Homebrew)
brew install aquasec/trivy/trivy
# Linux (script officiel)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
| sudo sh -s -- -b /usr/local/bin
# Docker (sans install locale)
docker run --rm -v "$(pwd):/scan" aquasec/trivy:latest fs /scan
# Version spécifique (important pour CI reproductibles)
docker run --rm aquasec/trivy:0.50.1 --version4.2 Premier scan d'image
# Scan d'une image publique, toutes sévérités
trivy image alpine:3.18
# Filtrage sévérité + sortie JSON
trivy image --severity HIGH,CRITICAL --format json --output scan.json nginx:1.25-alpine
# Scan de l'image locale Docker, exit code 1 si CVE HIGH ou CRITICAL trouvée
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest
# Scan offline (pré-pull de la DB)
trivy --cache-dir /tmp/trivy-cache image --skip-db-update alpine:3.184.3 Premier scan d'un repo de code
# Scan SCA + misconfig + secrets sur le répertoire courant
trivy fs --scanners vuln,misconfig,secret .
# Scan ciblé sur les dépendances applicatives uniquement
trivy fs --scanners vuln --ignore-unfixed .
# Scan repo Git distant
trivy repo https://github.com/myorg/myrepo5. Scan d'images de container (use case dominant)
5.1 Cas d'usage concret : durcir une image avant push registry
# Build
docker build -t myapi:dev .
# Scan pré-push, bloque si CVE critique non-fixable
trivy image \
--severity CRITICAL \
--ignore-unfixed \
--exit-code 1 \
--format table \
myapi:dev
# Si OK, tag + push
docker tag myapi:dev registry.internal/myapi:v1.2.3
docker push registry.internal/myapi:v1.2.35.2 Format SBOM CycloneDX intégré
# Génération SBOM pour compliance SLSA / CRA / DORA
trivy image --format cyclonedx --output myapi.cdx.json myapi:v1.2.3
# Ou au format SPDX
trivy image --format spdx-json --output myapi.spdx.json myapi:v1.2.3
# Scan à partir d'un SBOM existant (utile en archive post-build)
trivy sbom myapi.cdx.jsonLe SBOM CycloneDX contient pour chaque package : nom, version, PURL, license, hash. C'est l'artefact demandé par le Cyber Resilience Act (applicable 2027) et DORA (applicable janvier 2025) pour la traçabilité supply chain. Voir Pourquoi les entreprises recrutent des DevSecOps pour le contexte réglementaire.
5.3 Politiques VEX et exceptions
# Fichier .trivyignore pour exclure des CVE non applicables
cat > .trivyignore <<'EOF'
# CVE-2023-12345 — pas applicable, feature désactivée dans notre config
CVE-2023-12345
# CVE-2024-99999 — false positive, confirmé par équipe sécurité 2024-05
CVE-2024-99999
EOF
trivy image --severity HIGH,CRITICAL myapi:v1.2.36. Scan Infrastructure-as-Code (IaC)
Trivy couvre Terraform, Helm, Kubernetes manifests, Dockerfile, CloudFormation, Ansible. Les règles sont issues du projet trivy-checks (anciennement tfsec + defsec), maintenues par Aqua.
6.1 Exemple scan Terraform
# Scan d'un répertoire Terraform
trivy config ./terraform/
# Exit code 1 sur misconfig HIGH et plus
trivy config --severity HIGH,CRITICAL --exit-code 1 ./terraform/Exemple de findings courants détectés sur Terraform AWS :
| ID Check | Ressource | Description |
|---|---|---|
| AVD-AWS-0028 | aws_s3_bucket | Bucket sans encryption côté serveur |
| AVD-AWS-0087 | aws_security_group | Ingress 0.0.0.0/0 sur port sensible |
| AVD-AWS-0104 | aws_iam_policy | Action wildcard * sur ressource critique |
| AVD-AWS-0132 | aws_db_instance | RDS sans chiffrement activé |
6.2 Scan Helm chart
# Scan direct d'un chart rendu
helm template mychart ./mychart | trivy config -
# Ou via repo-scan
trivy repo --scanners misconfig https://github.com/myorg/helm-charts7. Scan de secrets
Trivy utilise un ensemble de regex + validateurs contextuels pour détecter les secrets. Moins puissant que gitleaks pour l'historique Git complet, mais adéquat en scan d'image ou répertoire courant.
# Scan secrets uniquement
trivy fs --scanners secret .
# Exemple de détection
# SECRET High - AWS Access Key ID
# file: ./scripts/deploy.sh:5
# value: AKIA****************8. Intégration CI/CD
8.1 GitHub Actions (intégration officielle)
# .github/workflows/security.yml
name: Security scan
on:
pull_request:
push:
branches: [main]
jobs:
trivy-scan:
runs-on: ubuntu-latest
permissions:
contents: read
security-events: write # pour upload SARIF vers GitHub Security
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapi:${{ github.sha }} .
- name: Run Trivy on image
uses: aquasecurity/trivy-action@0.28.0
with:
image-ref: myapi:${{ github.sha }}
format: sarif
output: trivy-results.sarif
severity: HIGH,CRITICAL
ignore-unfixed: true
exit-code: 1 # fail PR si CVE critique détectée
- name: Upload SARIF to GitHub Security
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: trivy-results.sarif
- name: Trivy SCA + misconfig + secret on filesystem
uses: aquasecurity/trivy-action@0.28.0
with:
scan-type: fs
scanners: vuln,misconfig,secret
severity: HIGH,CRITICAL
exit-code: 18.2 GitLab CI (intégration native)
# .gitlab-ci.yml — container scanning intégré
include:
- template: Security/Container-Scanning.gitlab-ci.yml # utilise Trivy par défaut
container_scanning:
variables:
CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
CS_SEVERITY_THRESHOLD: "HIGH"9. Trivy Operator : scan continu Kubernetes
Le Trivy Operator (aquasecurity/trivy-operator) est un opérateur Kubernetes qui scan en continu les workloads déployés sur un cluster, publie les résultats dans des CRDs (Custom Resource Definitions), et peut intégrer avec Prometheus + Grafana.
9.1 Installation (Helm)
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.2 \
--set trivy.ignoreUnfixed=true \
--set trivy.severity="HIGH,CRITICAL"9.2 CRDs exposées
| CRD | Contenu |
|---|---|
VulnerabilityReport | CVE détectées par workload |
ConfigAuditReport | Misconfigurations Pod Security Standards |
ClusterConfigAuditReport | Config cluster-scoped |
ExposedSecretReport | Secrets détectés dans images |
SbomReport | SBOM par workload |
ComplianceReport | CIS Benchmarks, DoD STIG |
# Lister les rapports de vulnérabilités
kubectl get vulnerabilityreports -A
# Détail d'un workload
kubectl describe vulnerabilityreport -n default deployment-myapi10. Comparatif Trivy vs Grype vs Snyk vs Clair vs Docker Scout
| Critère | Trivy | Grype | Snyk | Clair | Docker Scout |
|---|---|---|---|---|---|
| Licence | Apache 2.0 OSS | Apache 2.0 OSS | Commercial | Apache 2.0 OSS | Commercial (free tier) |
| Éditeur | Aqua Security | Anchore | Snyk Inc | Red Hat (orig.) | Docker Inc |
| Scan containers | ✓ | ✓ | ✓ | ✓ | ✓ |
| SCA dépendances | ✓ (large) | ✓ | ✓ (large + IA) | - | ✓ (limité) |
| IaC scan | ✓ | - | ✓ | - | - |
| Secrets scan | ✓ | - | - | - | - |
| SBOM génération | ✓ | ✓ (via Syft, qualité top) | ✓ | - | ✓ |
| K8s operator live | ✓ | Partiel | ✓ | - | - |
| Intégration native | GitHub, GitLab, ECR | Moyenne | Forte (IDE + PR bot) | Quay Registry | Docker Hub, Desktop |
| Vulnerability DB | Multi-sources unifiée | Multi-sources | Propriétaire enrichie | Moyenne | Base Docker propre |
| Coût (ETI typique) | 0 € | 0 € | 15-80 k€/an | 0 € | 0 € free / 5-20 k$/an team |
| Courbe apprentissage | Faible | Très faible | Moyenne | Élevée | Très faible |
| Leader 2024-2025 | Oui (OSS SCA) | Spécialiste SBOM | Leader commercial | Déclin | Émergent |
10.1 Recommandation par contexte
- ETI / PME sans budget dédié outillage : Trivy en couverture principale (container + SCA + IaC + secrets + SBOM). Complément gitleaks pour historique Git.
- Grand compte avec budget > 50 k€/an : Trivy + Snyk en dual-stack — Trivy pour coverage large, Snyk pour suggestions remédiation IA et reporting exécutif.
- Focus SLSA compliance supply chain : Syft (génération SBOM) + Grype (scan SBOM) en primary, Trivy en secondary.
- Stack full Docker : Docker Scout intégré par défaut, complété par Trivy pour coverage IaC + secrets.
Pour le positionnement parmi les techniques AppSec, voir SAST vs DAST vs IAST et SAST vs DAST (article court).
11. Limites et patterns de tuning
11.1 Faux positifs récurrents
# Ignorer les CVE non-fixables (pas de patch upstream)
trivy image --ignore-unfixed myapi:v1.2.3
# Ignorer des CVE spécifiques via .trivyignore ou --ignorefile
trivy image --ignorefile .trivyignore-app myapi:v1.2.3
# Expiration des ignorés (syntaxe YAML depuis v0.40+)
cat > .trivyignore.yaml <<'EOF'
vulnerabilities:
- id: CVE-2024-12345
expired_at: 2026-12-31
reason: "Feature non activée dans notre config, re-review fin 2026"
EOF11.2 Performance
Pour les images lourdes (> 2 GB), activer le cache partagé en CI :
# GitHub Actions : cache trivy-db entre builds
- uses: actions/cache@v4
with:
path: ~/.cache/trivy
key: trivy-${{ runner.os }}-${{ hashFiles('.github/trivy-version') }}
- uses: aquasecurity/trivy-action@0.28.0
with:
cache-dir: ~/.cache/trivy11.3 Quand ne pas utiliser Trivy
- Scan du code source applicatif (détection SQL injection, XSS) : Trivy ne fait pas ça → utiliser Semgrep / CodeQL / Snyk Code.
- Scan historique Git (secrets commités puis retirés) : Trivy ne fait pas ça → gitleaks, truffleHog.
- Pentest dynamique : Trivy est statique → utiliser OWASP ZAP, Burp, Nuclei.
- Analyse runtime behavior : Trivy ne voit pas l'exécution → utiliser Falco, Tetragon, eBPF.
Points clés à retenir
- Trivy : scanner open-source Apache 2.0 par Aqua Security, ~23 000 stars GitHub, leader SCA open-source 2024-2025.
- 7 cas d'usage : images containers, dépendances applicatives, IaC, secrets, compliance, SBOM, clusters Kubernetes live.
- Base de données trivy-db unifiée depuis 30+ sources (NVD, GHSA, OSV, Bitnami VDB, Red Hat VEX, distro secdb), mise à jour 2× par jour.
- Intégration native GitHub, GitLab (container scanning par défaut), AWS ECR, Azure ACR, Docker Hub.
- Trivy Operator Kubernetes pour scan continu workloads live via CRDs.
- SBOM CycloneDX + SPDX nativement — obligation CRA 2027 et DORA 2025.
- Comparé à Snyk : gratuit mais sans suggestions IA de fix ; complémentaire sur grosses ETI.
- Limites : ne scanne pas le code source (SAST requis), pas l'historique Git (gitleaks requis), pas le runtime (Falco requis).
- Budget effort : première intégration production < 30 minutes pour un DevSecOps, maintenance ~2-5 j par an.
Pour mettre en place la stack DevSecOps complète, voir Roadmap DevSecOps et Étapes pour devenir DevSecOps. Pour le contexte réglementaire qui justifie Trivy en 2025, Pourquoi les entreprises recrutent des DevSecOps.







