DevSecOps

Trivy : à quoi ça sert ? Guide technique DevSecOps 2025

Trivy expliqué : scanner open-source Aqua Security pour containers, dépendances, IaC, secrets, Kubernetes, SBOM. Cas d'usage CI/CD, comparatif Grype/Snyk, limites.

Naim Aouaichia
14 min de lecture
  • Trivy
  • Scanner vulnérabilités
  • SCA
  • Container security
  • IaC scan
  • SBOM
  • DevSecOps outillage

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
2019Création initiale par Teppei Fukuda (Aqua Security)
2020Intégration GitLab Container Scanning par défaut
2021Ajout scan IaC (rebranding depuis "Trivy CS" vers Trivy complet)
2022Ajout scan secrets + Kubernetes Operator
2023Support SBOM CycloneDX + SPDX, intégration GitHub Action officielle
2024~23 000 stars GitHub, releases toutes les 2-4 semaines
2025Leader 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 selected

2.1 Matrice cas d'usage × classes détectées

Commandevulnmisconfigsecretlicensecompliance
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 :

SourceContenu
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 VDBCharts Helm + containers Bitnami
Red Hat VEXÉtat de correction RHEL / Fedora
Alpine secdbAdvisories Alpine Linux
Debian Security TrackerAdvisories Debian
Ubuntu CVE TrackerAdvisories Ubuntu
Amazon Linux Security CenterAdvisories AL2 / AL2023
GitLab Advisory DBAdditional sources
PhotonOS, Rocky, SUSE, OracleAdvisories 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 --version

4.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.18

4.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/myrepo

5. 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.3

5.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.json

Le 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.3

6. 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 CheckRessourceDescription
AVD-AWS-0028aws_s3_bucketBucket sans encryption côté serveur
AVD-AWS-0087aws_security_groupIngress 0.0.0.0/0 sur port sensible
AVD-AWS-0104aws_iam_policyAction wildcard * sur ressource critique
AVD-AWS-0132aws_db_instanceRDS 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-charts

7. 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: 1

8.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

CRDContenu
VulnerabilityReportCVE détectées par workload
ConfigAuditReportMisconfigurations Pod Security Standards
ClusterConfigAuditReportConfig cluster-scoped
ExposedSecretReportSecrets détectés dans images
SbomReportSBOM par workload
ComplianceReportCIS 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-myapi

10. Comparatif Trivy vs Grype vs Snyk vs Clair vs Docker Scout

CritèreTrivyGrypeSnykClairDocker Scout
LicenceApache 2.0 OSSApache 2.0 OSSCommercialApache 2.0 OSSCommercial (free tier)
ÉditeurAqua SecurityAnchoreSnyk IncRed 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 livePartiel--
Intégration nativeGitHub, GitLab, ECRMoyenneForte (IDE + PR bot)Quay RegistryDocker Hub, Desktop
Vulnerability DBMulti-sources unifiéeMulti-sourcesPropriétaire enrichieMoyenneBase Docker propre
Coût (ETI typique)0 €0 €15-80 k€/an0 €0 € free / 5-20 k$/an team
Courbe apprentissageFaibleTrès faibleMoyenneÉlevéeTrès faible
Leader 2024-2025Oui (OSS SCA)Spécialiste SBOMLeader commercialDé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"
EOF

11.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/trivy

11.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.

Questions fréquentes

  • À quoi sert Trivy concrètement dans un pipeline DevSecOps ?
    Trivy est un scanner open-source unifié qui couvre 7 cas d'usage dans un pipeline DevSecOps : 1) Vulnérabilités dans les images de container (CVE sur packages Alpine, Debian, RHEL, distroless). 2) Dépendances applicatives (npm, PyPI, Maven, Go modules, Rubygems, Cargo, Composer, NuGet). 3) Misconfigurations IaC (Terraform, Helm charts, Kubernetes manifests, Dockerfile, CloudFormation, Ansible). 4) Secrets accidentellement commités (AWS keys, tokens, clés privées). 5) Compliance (CIS Benchmarks, DoD STIG). 6) Génération SBOM au format CycloneDX ou SPDX. 7) Scan cluster Kubernetes live via Trivy Operator. Un seul binaire Go, un seul cache DB, un seul format de sortie JSON/SARIF/table — c'est ce qui explique sa position de leader SCA open-source 2024-2025.
  • Trivy est-il maintenu et fiable en 2025 ?
    Oui, Trivy est le projet de scanner vulnérabilités open-source le plus actif 2024-2025. Maintenu par Aqua Security (éditeur cyber US-israélien, ~400 employés 2024), hébergé sous aquasecurity/trivy sur GitHub, licence Apache 2.0, ~23 000 stars fin 2024 (en forte croissance). Commits hebdomadaires, releases toutes les 2-4 semaines, base de données de vulnérabilités (trivy-db) mise à jour 2 fois par jour via GitHub Actions automatisé depuis NVD, GHSA, OSV, Bitnami VDB, Red Hat VEX, Alpine secdb, distro-specific secdb. Trivy est intégré officiellement dans GitLab (scanning pack par défaut depuis 2022), GitHub (action officielle Aqua), et AWS ECR (scan natif). Aucun signal de stagnation ou dépréciation à l'horizon 2025-2027.
  • Quelle différence pratique entre Trivy, Grype et Snyk ?
    Trivy couvre 7 cas d'usage (container + SCA + IaC + secrets + compliance + SBOM + K8s), open-source, gratuit, leader adoption. Grype (Anchore) est plus ciblé : scan containers + SBOM via Syft, excellent sur la qualité SBOM, moins riche sur IaC et secrets. Snyk est commercial (15-80 k€/an ETI selon nombre de devs), couvre SCA + Container + IaC + Code (SAST), enrichi d'une base vulnérabilités propriétaire avec suggestions de fix IA-assistées, intégrations IDE premium. Règle pragmatique 2025 : Trivy en solution par défaut open-source, Snyk en complément commercial quand budget + suggestions automatiques de remédiation + reporting exécutif sont prioritaires. Grype reste pertinent si l'enjeu SBOM qualité (SLSA compliance) domine.
  • Comment Trivy s'intègre-t-il dans GitHub Actions et GitLab CI ?
    Via la GitHub Action officielle aquasecurity/trivy-action (disponible sur le Marketplace, mise à jour régulière) : ajout de 10-15 lignes dans .github/workflows/ pour scanner une image buildée et bloquer le merge si CVE critique détectée. Intégration SARIF automatique avec l'onglet Security de GitHub. Pour GitLab : Trivy est intégré par défaut dans les templates Container Scanning (SAST.gitlab-ci.yml include) depuis GitLab 15+, avec export Vulnerability Report natif. Docker Hub, AWS ECR, Azure ACR l'intègrent tous en scan-on-push. La courbe d'intégration est très faible : première intégration production < 30 minutes pour un DevSecOps qui connaît son pipeline.
  • Trivy remplace-t-il un SAST comme Semgrep ou CodeQL ?
    Non, ce sont des outils complémentaires. Trivy scanne des références de package (noms, versions) et les croise avec des bases de vulnérabilités connues (CVE, GHSA, OSV) — il ne lit pas le code source applicatif et ne détecte pas les vulnérabilités dans le code écrit par l'équipe. Un SAST (Semgrep, CodeQL, Snyk Code, Checkmarx) analyse l'AST et les flux de données du code source pour détecter des patterns vulnérables (injection SQL, XSS, désérialisation insecure). Une stack DevSecOps complète 2025 combine obligatoirement : SCA (Trivy) + SAST (Semgrep ou CodeQL) + secrets scan (Trivy ou gitleaks) + IaC scan (Trivy ou Checkov) + DAST (ZAP) + IAST si budget (Contrast Security). Aucun ne substitue les autres. Voir SAST vs DAST vs IAST pour le détail.
  • Quelles sont les limites réelles de Trivy qu'on découvre en production ?
    Cinq limites documentées. 1) Faux négatifs sur packages non reconnus — Trivy dépend de la présence de métadonnées de package (manifest, lockfile). Un binaire installé hors package manager est invisible. 2) Faux positifs sur vulnérabilités corrigées non-reflétées dans les distro VEX — le décalage NVD vs distro peut durer 24-72h. 3) Pas d'analyse de code applicatif (voir FAQ précédente). 4) Performance sur très grosses images (> 10 GB) — scan pouvant durer 5-15 minutes, à exclure du hot path CI. 5) Kubernetes Operator consomme des ressources non négligeables sur gros clusters (CPU/mémoire pour scan en continu). Ces limites sont documentées par Aqua, contournées par combinaison avec Grype (secondaire) ou Snyk Code (code scan).

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.