Trivy : scanner de vulnérabilités, secrets et IaC

Tu viens de construire une image Docker. Elle fonctionne, les tests passent, tu es prêt à déployer. Mais sais-tu vraiment ce qu’elle contient ? Peut-être une bibliothèque avec une faille critique publiée la semaine dernière. Ou un bucket S3 public dans ton Terraform. Ou pire : un mot de passe en clair oublié dans le code.

Trivy, c’est le détecteur de fumée de ton code. En quelques secondes, il scanne tes images, ton Infrastructure as Code et ton code source pour t’alerter avant que ces problèmes n’arrivent en production.

Trivy en 30 secondes

# Scanner une image Docker
trivy image nginx:latest

# Scanner ton code source
trivy fs --scanners vuln .

# Scanner du Terraform
trivy config ./infra/

C’est tout. Pas de configuration complexe, pas de base de données à installer.

Ce guide est fait pour toi si…

Tu débutes en sécurité Comprendre ce que Trivy détecte et pourquoi c'est important.

Tu veux scanner tes images Commandes essentielles pour analyser tes conteneurs Docker.

Tu intègres en CI/CD Exemples GitHub Actions et GitLab CI prêts à l'emploi.

Tu sécurises Kubernetes Trivy Operator pour un scan continu de ton cluster.

Pourquoi Trivy est devenu incontournable

Dans le monde du développement logiciel, la sécurité est souvent reléguée au second plan dans les cycles de développement. Cependant, avec l’émergence du DevSecOps, il est devenu impératif d’intégrer la sécurité dès les premières étapes du développement (Shift Left).

C’est ici qu’intervient Trivy : un outil d’analyse de sécurité open source développé par Aqua Security, devenu rapidement populaire pour sa fiabilité, sa rapidité et sa facilité d’intégration.

L’histoire de Trivy

Trivy a été développé par Aqua Security avec la vision de simplifier la sécurité pour les développeurs et les équipes d’opérations. Contrairement à d’autres outils qui nécessitaient une configuration complexe et une compréhension approfondie des aspects de sécurité, Trivy se distinguait par sa simplicité d’utilisation. Cette facilité d’accès a permis même aux développeurs moins expérimentés en matière de sécurité de l’intégrer dans leurs workflows.

L’outil a évolué rapidement, passant d’un simple scanner de vulnérabilités à une solution complète pour la sécurité des applications et des infrastructures. Aujourd’hui, Trivy est capable de détecter non seulement les vulnérabilités dans les images de conteneurs, mais aussi les mauvaises configurations dans l’Infrastructure as Code (IaC), les secrets exposés, les risques de sécurité des clusters Kubernetes et bien plus encore.

Comprendre les CVE et leurs scores

Avant de plonger dans Trivy, je te conseille de lire mon guide sur les CVE, CVSS et EPSS pour comprendre ce que signifient vraiment les vulnérabilités remontées et comment les prioriser intelligemment.

Fonctionnalités de Trivy

Trivy se distingue non seulement par sa facilité d’utilisation, mais aussi par son éventail complet de fonctionnalités qui en font un outil polyvalent pour la sécurité dans le développement logiciel. Les bases de données de Trivy sont constamment mises à jour avec les dernières informations sur les failles, garantissant ainsi que les scans sont basés sur les données les plus récentes.

Trivy est capable de scanner une variété de targets :

• Images de conteneurs : Docker, Podman, OCI, images distroless et Chainguard
• Systèmes de fichiers : code source, dépendances applicatives
• Dépôts Git : analyse directe depuis GitHub, GitLab, Bitbucket
• Infrastructure as Code : Terraform, Kubernetes YAML, Helm, Dockerfile, CloudFormation
• Machines virtuelles : images VMDK, AMI AWS
• Clusters Kubernetes : workloads, configurations, RBAC
• Comptes AWS : audit de configuration cloud

Gestionnaires de paquets supportés

Trivy détecte automatiquement les dépendances dans de nombreux écosystèmes :

Langage	Gestionnaires
Python	pip, Poetry, Pipenv, conda
JavaScript	npm, yarn, pnpm
Go	go.mod, binaires compilés
Java	Maven, Gradle, JAR/WAR
Ruby	Bundler, Gemfile
Rust	Cargo
PHP	Composer
.NET	NuGet, packages.config

Glissez pour voir

Génération de SBOM

Trivy génère des SBOM (Software Bill of Materials) et KBOM (Kubernetes BOM) détaillés, fournissant un inventaire complet des composants logiciels. Les SBOM permettent une compréhension approfondie des composants utilisés lors de la construction.

Les SBOM peuvent être signés avec Cosign, ainsi que l’image. Ces signatures pourront ensuite être vérifiées avant déploiement dans un cluster Kubernetes pour confirmer leur origine.

Trivy peut également lancer des benchs permettant de vérifier que les artefacts produits sont conformes aux normes. Vous l’aurez compris Trivy ne se limite plus au simple scan d’images de conteneurs. Voyons comment l’utiliser.

Installation de Trivy

L’installation de Trivy est assez simple, car le package ne contient qu’un seul binaire.

Installation sur Linux

Sur les systèmes Linux, Trivy peut être installé via le gestionnaire de paquets. Mais je vous conseille de le faire avec asdf qui permet d’installer les dernières versions.

asdf plugin add trivy
asdf install trivy latest
asdf set --home trivy latest

Si vous préférez une installation manuelle, vous pouvez télécharger le binaire depuis la page des releases de Trivy sur GitHub.

Installation sur macOS

Pour les utilisateurs de macOS, Trivy peut être installé via Homebrew en exécutant la commande suivante :

brew install trivy

Installation sur Windows

Sur Windows, Trivy peut être installé en téléchargeant le fichier exécutable depuis la page de releases de Trivy sur GitHub et en l’ajoutant au PATH du système. Un moyen est d’utiliser chocolatey.

Vérification de l’Installation

Une fois installé, vous pouvez vérifier que Trivy fonctionne correctement en exécutant la commande suivante :

trivy --version

Cette commande affichera la version de Trivy installée, confirmant que l’installation a été réussie.

Utilisation de la CLI Trivy

La CLI Trivy utilise ce format de commande :

  trivy [global flags] command [flags] target

Les principales commandes de scan

Trivy propose plusieurs cibles de scan (targets) :

• image : analyse les images de conteneurs (Docker, OCI)
• fs : scanne un système de fichiers ou dossier local
• repository : analyse un dépôt Git directement
• rootfs : scanne le système de fichiers racine d’une image ou VM
• sbom : analyse un SBOM existant (CycloneDX, SPDX)
• vm : scanne les images de machines virtuelles (VMDK, AMI AWS)
• k8s : analyse un cluster Kubernetes complet

Trivy peut utiliser des scanners spécifiques :

• vuln : détection des vulnérabilités (CVE)
• misconfig : analyse des mauvaises configurations (IaC, Dockerfile, Kubernetes)
• secret : recherche de secrets exposés (clés API, tokens, mots de passe)
• license : inventaire des licences logicielles

Par défaut, seuls les scanners vuln et secret sont activés. Pour activer les autres, utilisez le flag --scanners.

Exemples de combinaisons de scanners :

# Scan répertoire source : vulnérabilités uniquement (recommandé)
trivy fs --scanners vuln .

# Scan complet projet : vulnérabilités + secrets + IaC
trivy fs --scanners vuln,secret,misconfig .

Exemple réel : scan du projet devops-status-api :

trivy fs --scanners vuln . -q

Report Summary
┌──────────────────┬──────┬─────────────────┐
│      Target      │ Type │ Vulnerabilities │
├──────────────────┼──────┼─────────────────┤
│ requirements.txt │ pip  │        4        │
└──────────────────┴──────┴─────────────────┘

requirements.txt (pip)
Total: 4 (LOW: 0, MEDIUM: 3, HIGH: 0, CRITICAL: 1)

┌─────────────┬────────────────┬──────────┬───────────────────┬───────────────┐
│   Library   │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │
├─────────────┼────────────────┼──────────┼───────────────────┼───────────────┤
│ python-jose │ CVE-2024-33663 │ CRITICAL │ 3.3.0             │ 3.4.0         │
│             ├────────────────┼──────────┤                   │               │
│             │ CVE-2024-33664 │ MEDIUM   │                   │               │
│             ├────────────────┤          │                   │               │
│             │ CVE-2016-1000  │          │                   │               │
├─────────────┼────────────────┤          │───────────────────┼───────────────┤
│ requests    │ CVE-2024-35195 │ MEDIUM   │ 2.32.3            │ (no fix)      │
└─────────────┴────────────────┴──────────┴───────────────────┴───────────────┘

Ce qu’on observe :

• 4 CVE détectées dans requirements.txt
• 1 Critical (python-jose) : vulnérabilité de confusion d’algorithme
• 3 Medium : déni de service, injection CRLF
• Fix disponible : python-jose 3.3.0 → 3.4.0

Scan Infrastructure as Code (IaC)

Trivy analyse Terraform, Kubernetes, Dockerfile, Helm, CloudFormation pour détecter les mauvaises configurations :

# Scanner un Dockerfile
trivy config --file-patterns "dockerfile:Dockerfile" .

# Scanner Terraform
trivy config ./infra/terraform

# Scanner manifestes Kubernetes
trivy fs --scanners misconfig ./k8s/

# Scan complet : vulnérabilités + IaC + secrets
trivy fs --scanners vuln,misconfig,secret .

Exemple : scan Dockerfile de devops-status-api :

trivy config --file-patterns "dockerfile:Dockerfile" .

Report Summary
┌────────────┬────────────┬───────────────────┐
│   Target   │    Type    │ Misconfigurations │
├────────────┼────────────┼───────────────────┤
│ Dockerfile │ dockerfile │         0         │
└────────────┴────────────┴───────────────────┘
Legend:
- '0': Clean (no security findings detected)

Résultat : Dockerfile conforme aux bonnes pratiques Trivy :

• ✅ Utilise multi-stage build (réduction de taille)
• ✅ Image de base récente (Alpine 3.23.2)
• ✅ Pas de secrets hardcodés
• ✅ USER non-root configuré dans l’image de base Python

main.tf (terraform)
Tests: 8 (SUCCESSES: 0, FAILURES: 8)
Failures: 8 (UNKNOWN: 0, LOW: 1, MEDIUM: 1, HIGH: 6, CRITICAL: 0)

AVD-AWS-0086 (HIGH): Public access block does not block public ACLs
══════════════════════════════════════════════════════════════════════
S3 buckets should block public ACLs on buckets and any objects they contain.

See https://avd.aquasec.com/misconfig/avd-aws-0086
──────────────────────────────────────────────────────────────────────
 main.tf:8
──────────────────────────────────────────────────────────────────────
   5   resource "aws_s3_bucket_public_access_block" "example" {
   8 [   block_public_acls       = false
──────────────────────────────────────────────────────────────────────

AVD-AWS-0088 (HIGH): Bucket does not have encryption enabled
══════════════════════════════════════════════════════════════════════
S3 Buckets should be encrypted to protect the data stored within them.

See https://avd.aquasec.com/misconfig/avd-aws-0088
──────────────────────────────────────────────────────────────────────
 main.tf:1-3
──────────────────────────────────────────────────────────────────────
   1 ┌ resource "aws_s3_bucket" "example" {
   2 │   bucket = "my-tf-test-bucket"
   3 └ }
──────────────────────────────────────────────────────────────────────

Trivy s’appuie sur des règles intégrées (Rego policies) pour détecter :

• Conteneurs exécutés en root (runAsNonRoot: false)
• Ressources Kubernetes sans limites CPU/mémoire
• Buckets S3 publics ou sans chiffrement
• Secrets en clair dans les configurations Terraform
• Ports sensibles exposés (22, 3389, etc.)
• Images sans tag fixe (utilisation de latest)
• Privilèges élevés (privileged: true, CAP_SYS_ADMIN)

Scan de machines virtuelles et rootfs

Trivy propose deux commandes pour auditer des systèmes complets :

Commande rootfs (machine locale ou image montée)

La commande rootfs scanne le système de fichiers racine d’une machine. L’exécution en root est quasi indispensable pour une visibilité complète sur tous les packages installés :

# Scanner le système de fichiers racine (nécessite les droits root)
sudo trivy rootfs --scanners vuln --severity HIGH,CRITICAL /

# Scanner une image de VM montée
sudo trivy rootfs --scanners vuln /mnt/vm-disk/

Scan rootfs

Le scan rootfs doit être exécuté sur la machine cible ou sur un système de fichiers monté. L’option --privileged n’est pas requise, mais les droits root sont nécessaires pour accéder à tous les fichiers système.

Commande vm (images de machines virtuelles)

La commande vm cible spécifiquement les images de VM (VMDK, QCOW2, AMI exportées). Idéal pour valider des golden images avant déploiement :

# Scanner une image QCOW2
trivy vm --severity HIGH,CRITICAL ./disk.qcow2

# Scanner une image VMDK avec rapport détaillé
trivy vm --format table ./windows-server.vmdk

Tests de compliance

Trivy permet de lancer des audits de compliance basés sur les référentiels des principales organisations sur les images de container, les clusters kubernetes et les comptes AWS.

$ trivy image --compliance docker-cis-1.6.0 nginx:latest
2025-12-10T07:18:07Z    INFO    [image] Container image config scanners scanners=[misconfig secret]
2025-12-10T07:18:07Z    INFO    [vuln] Vulnerability scanning is enabled
2025-12-10T07:18:07Z    INFO    [misconfig] Misconfiguration scanning is enabled
2025-12-10T07:18:09Z    INFO    Detected OS     family="debian" version="13.2"
2025-12-10T07:18:09Z    INFO    [debian] Detecting vulnerabilities...

Summary Report for compliance: CIS Docker Community Edition Benchmark v1.6.0
┌──────┬──────────┬──────────────────────────────────────────────────────────────┬────────┬────────┐
│  ID  │ Severity │                         Control Name                         │ Status │ Issues │
├──────┼──────────┼──────────────────────────────────────────────────────────────┼────────┼────────┤
│ 4.1  │   HIGH   │ Ensure a user for the container has been created             │  FAIL  │   1    │
│ 4.2  │   HIGH   │ Ensure that containers use only trusted base images (Manual) │   -    │   -    │
│ 4.3  │   HIGH   │ Ensure unnecessary packages are not installed in the         │   -    │   -    │
│      │          │ container (Manual)                                           │        │        │
│ 4.4  │ CRITICAL │ Ensure images are scanned and rebuilt to include security    │  PASS  │   0    │
│      │          │ patches                                                      │        │        │
│ 4.5  │   LOW    │ Ensure Content trust for Docker is Enabled (Manual)          │   -    │   -    │
│ 4.6  │   LOW    │ Ensure HEALTHCHECK instructions have been added to the       │  FAIL  │   1    │
│      │          │ container image                                              │        │        │
│ 4.7  │   HIGH   │ Ensure update instructions are not used alone in the         │  PASS  │   0    │
│      │          │ Dockerfile                                                   │        │        │
│ 4.9  │   LOW    │ Ensure COPY is used instead of ADD                           │  PASS  │   0    │
│ 4.10 │ CRITICAL │ Ensure secrets are not stored in Dockerfiles                 │  PASS  │   0    │
│ 4.11 │  MEDIUM  │ Ensure only verified packages are installed (Manual)         │   -    │   -    │
│ 4.12 │  MEDIUM  │ Ensure all signed artifacts are validated (Manual)           │   -    │   -    │
└──────┴──────────┴──────────────────────────────────────────────────────────────┴────────┴────────┘

Les référentiels de compliance disponibles varient selon la cible :

• Images Docker (trivy image --compliance) :
  • docker-cis-1.6.0 : CIS Docker Community Edition Benchmark v1.6.0
• Clusters Kubernetes (trivy k8s --compliance) :
  • k8s-cis-1.23 : CIS Kubernetes Benchmark v1.23
  • k8s-nsa : NSA Kubernetes Hardening Guide
  • k8s-pss-baseline / k8s-pss-restricted : Pod Security Standards
• Comptes AWS (trivy aws --compliance) :
  • aws-cis-1.2 / aws-cis-1.4 : CIS AWS Foundations Benchmark

Exemple de scan compliance sur un cluster Kubernetes :

# Audit NSA Kubernetes Hardening Guide
trivy k8s --compliance k8s-nsa --report summary

# Audit CIS Kubernetes Benchmark v1.23
trivy k8s --compliance k8s-cis-1.23 --report all

Gestion de configuration

Trivy peut être configuré via (par ordre de priorité) :

1. Flags CLI (priorité max)
2. Variables d’environnement (préfixées TRIVY_)
3. Fichier trivy.yaml

Exemple de fichier trivy.yaml :

# Cache et timeout
cache:
  dir: "/tmp/trivy-cache"
timeout: 10m

# Format et sévérité
format: "table"
exit-code: 1
severity:
  - HIGH
  - CRITICAL

# Scanners
scan:
  scanners:
    - vuln
    - secret
  skip-dirs:
    - /lib64
    - /usr/lib

# Vulnérabilités
vulnerability:
  ignore-unfixed: true

Documentation complète des paramètres

Formats de sortie et rapports

Trivy supporte plusieurs formats d’export pour s’intégrer dans différents outils :

# Format JSON (pour traitement automatisé)
$ trivy image --format json --output report.json alpine:latest

# Format SARIF (intégration GitHub Security, Azure DevOps, GitLab)
$ trivy image --format sarif --output report.sarif alpine:latest

# Format CycloneDX SBOM (standard OWASP)
$ trivy image --format cyclonedx --output sbom.json alpine:latest

# Format SPDX SBOM (standard Linux Foundation)
$ trivy image --format spdx-json --output sbom.spdx.json alpine:latest

Exemple de sortie JSON :

{
  "SchemaVersion": 2,
  "CreatedAt": "2025-12-10T07:19:20Z",
  "ArtifactName": "alpine:latest",
  "ArtifactType": "container_image",
  "Metadata": {
    "OS": {
      "Family": "alpine",
      "Name": "3.23.0"
    },
    "ImageID": "sha256:7acffee03fe864cd6b88219a1028855d6c912e7cf6fac..."
  }
}

Format SARIF

Le format SARIF (Static Analysis Results Interchange Format) est le standard pour l’intégration avec GitHub Advanced Security, Azure DevOps et d’autres plateformes. Les vulnérabilités apparaissent directement dans l’onglet Security.

Génération et consommation de SBOM

Le SBOM (Software Bill of Materials) est un inventaire complet des composants. Trivy peut le générer puis le scanner ultérieurement :

SBOM et vulnérabilités

--format cyclonedx ou spdx-json génère un SBOM et désactive le scan de vulnérabilités. Pour analyser les failles, scannez ensuite le SBOM avec trivy sbom.

# Étape 1 : Générer le SBOM (format CycloneDX)
trivy fs --format cyclonedx --output sbom.json .

# Étape 2 : Scanner le SBOM (sans accès au code source)
trivy sbom sbom.json

Report Summary
┌──────────────────┬──────┬─────────────────┐
│      Target      │ Type │ Vulnerabilities │
├──────────────────┼──────┼─────────────────┤
│ sbom.json (pip)  │ pip  │        4        │
└──────────────────┴──────┴─────────────────┘

Cette approche découple la génération de l’analyse (idéal pour environnements air-gapped ou supply-chain security). Le SBOM permet de tracer tous les composants et de rescanner lors de nouvelles CVE.

Intégration de Trivy dans les pipelines CI/CD

L’intégration de Trivy dans vos pipelines CI/CD permet d’automatiser les scans de sécurité à chaque commit, pull request ou déploiement. Cette approche Shift Left détecte les vulnérabilités avant la mise en production.

Exemple avec Gitlab CI/CD

Pour analyser une image construite et transférée dans le registre GitLab. Le cache persistant améliore les temps de scan en évitant de retélécharger la base de vulnérabilités :

container_scanning:
  image:
    name: docker.io/aquasec/trivy:0.68.2
    entrypoint: [""]
  variables:
    # Pas besoin de cloner le repo, on travaille uniquement sur l'image
    GIT_STRATEGY: none
    TRIVY_USERNAME: "$CI_REGISTRY_USER"
    TRIVY_PASSWORD: "$CI_REGISTRY_PASSWORD"
    TRIVY_AUTH_URL: "$CI_REGISTRY"
    TRIVY_NO_PROGRESS: "true"
    TRIVY_CACHE_DIR: ".trivycache/"
    FULL_IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  script:
    - trivy --version
    # Téléchargement de la base de vulnérabilités
    - time trivy image --download-db-only
    # Génération du rapport GitLab (format template)
    - time trivy image --exit-code 0 --format template --template "@/contrib/gitlab.tpl"
        --output "$CI_PROJECT_DIR/gl-container-scanning-report.json" "$FULL_IMAGE_NAME"
    # Affichage du rapport complet
    - time trivy image --exit-code 0 "$FULL_IMAGE_NAME"
    # Échec sur vulnérabilités critiques
    - time trivy image --exit-code 1 --severity CRITICAL "$FULL_IMAGE_NAME"
  cache:
    paths:
      - .trivycache/
  artifacts:
    when: always
    reports:
      container_scanning: gl-container-scanning-report.json
  tags:
    - docker-runner

GitLab 15+

GitLab 15.0+ intègre Trivy nativement. Utilisez simplement le template officiel :

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

Exemple avec GitHub Actions

Pour intégrer Trivy dans GitHub Actions, utilisez l’action officielle aquasecurity/trivy-action. L’action gère automatiquement le cache des bases de données de vulnérabilités :

name: Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  trivy-scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.33.1
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
          ignore-unfixed: true

      - name: Upload Trivy scan results to GitHub Security
        uses: github/codeql-action/upload-sarif@v4
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

Le format SARIF permet d’afficher les vulnérabilités directement dans l’onglet Security de GitHub, avec des liens vers les CVE et les fichiers concernés.

Cache intégré

L’action trivy-action gère automatiquement le cache des bases de données. Pour désactiver le cache, ajoutez cache: 'false' dans les inputs.

Scan Kubernetes avec Trivy Operator

Pour un scan continu de votre cluster Kubernetes, installez Trivy Operator. Cet opérateur analyse automatiquement tous les workloads déployés et stocke les résultats dans des Custom Resources (CR) Kubernetes :

# Ajout du dépôt Helm
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

# Installation de Trivy Operator
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --version 0.29.0

Vous pouvez aussi installer depuis l’OCI registry (Helm 3.8+) :

helm install trivy-operator \
  oci://ghcr.io/aquasecurity/helm-charts/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --version 0.29.0

L’opérateur crée des CRD pour stocker les rapports de sécurité :

# Lister les rapports de vulnérabilités de tous les namespaces
kubectl get vulnerabilityreports -A

# Lister les rapports de configuration (misconfigs)
kubectl get configauditreports -A

# Voir les secrets exposés
kubectl get exposedsecretreports -A

# Détails d'un rapport spécifique
kubectl describe vulnerabilityreport -n default <nom-du-pod>

Les rapports peuvent être exportés vers des outils de monitoring comme Prometheus/Grafana ou Datadog pour un suivi centralisé.

Optimisation des performances

Pour accélérer les scans dans vos pipelines :

# Utiliser un cache persistant
export TRIVY_CACHE_DIR="/path/to/cache"

# Télécharger la DB une seule fois
trivy image --download-db-only

# Scanner sans mise à jour de la DB
trivy image --skip-db-update alpine:latest

# Scanner uniquement les vulnérabilités (plus rapide)
trivy image --scanners vuln alpine:latest

# Ignorer les vulnérabilités non corrigées
trivy image --ignore-unfixed alpine:latest

Performance

En CI/CD, cachez le répertoire ~/.cache/trivy entre les jobs pour éviter de retélécharger la base de vulnérabilités à chaque exécution.

Gestion des exceptions avec .trivyignore

Pour documenter les exceptions métier (faux positifs, risques acceptés), créez un fichier .trivyignore à la racine du projet :

# .trivyignore - Exceptions documentées
# CVE acceptée car non exploitable dans notre contexte
CVE-2023-12345

# Vulnérabilité mitigée par configuration réseau
CVE-2024-67890

# Secret de test (non utilisé en production)
secret:generic-api-key

Trivy supporte également les dates d’expiration pour forcer une revue périodique des exceptions :

# Expire le 31 mars 2025 - à revoir
CVE-2024-11111 exp:2025-03-31

--ignore-unfixed

L’option --ignore-unfixed est très utile en CI pour réduire le bruit sur les CVE sans correctif disponible. Pragmatique sur des images OS récentes.

Bonnes pratiques et limites

Ce que Trivy fait bien

• Détection rapide des vulnérabilités connues (CVE) dans les images et dépendances
• Multi-cibles : images, IaC, code source, SBOM, Kubernetes
• Intégration CI/CD simple avec GitHub Actions, GitLab CI, Jenkins
• Génération de SBOM (CycloneDX, SPDX) pour la traçabilité supply-chain
• Scan offline possible grâce à la consommation de SBOM

Ce que Trivy ne remplace pas

Limites à connaître

Trivy est un outil complémentaire, pas une solution de sécurité complète :

• Faux positifs/négatifs possibles — croisez les résultats avec d’autres outils
• Vulnérabilités 0-day non détectées tant qu’elles ne sont pas publiées dans les bases
• Tests dynamiques (DAST/pentest) non couverts — Trivy fait de l’analyse statique
• Revue de code manuelle toujours nécessaire pour la logique métier
• Binaires compilés : analyse limitée si pas de métadonnées SBOM

Recommandations DevSecOps

• Combinez plusieurs outils : Trivy + Grype + tests manuels
• Images minimalistes : utilisez des images distroless ou Chainguard pour réduire la surface d’attaque
• Mettez à jour régulièrement Trivy et ses bases de vulnérabilités
• Signez vos artefacts avec Cosign pour garantir l’intégrité
• Auditez régulièrement vos systèmes avec Lynis
• Définissez des seuils : bloquez les builds sur les CVE CRITICAL et HIGH
• Archivez les SBOM pour pouvoir rescanner lors de nouvelles CVE
• Utilisez .trivyignore pour documenter les exceptions avec dates d’expiration

Cross-check avec Grype

Pour une couverture maximale, croisez les résultats de Trivy avec Grype (≥0.87). Les versions récentes de Grype apportent le support CSAF (Custom Vulnerability Sources) et des améliorations VEX :

# Scan avec Trivy
trivy image --severity HIGH,CRITICAL nginx:latest > trivy-report.txt

# Scan avec Grype (même image)
grype nginx:latest --only-fixed --fail-on high > grype-report.txt

# Comparer les résultats pour identifier les écarts
diff trivy-report.txt grype-report.txt

Cette approche multi-scanner réduit les risques de faux négatifs et renforce la confiance dans vos audits de sécurité.

Conclusion

Trivy s’impose comme un outil incontournable pour les équipes DevSecOps. Sa capacité à scanner images, IaC, dépôts Git et clusters Kubernetes en fait une solution polyvalente pour intégrer la sécurité dès les premières étapes du développement.

L’approche Shift Left que Trivy facilite permet de détecter les vulnérabilités avant la production, réduisant ainsi les coûts de remédiation et les risques de sécurité. Combiné à la génération de SBOM et à l’intégration dans les pipelines CI/CD, Trivy devient un pilier de la supply-chain security.

Pour aller plus loin

Tu maîtrises maintenant Trivy pour scanner images, code et IaC. Mais la sécurité ne s’arrête pas là. Voici comment compléter ton arsenal DevSecOps :

Approfondir la sécurité

Comprendre les CVE Avant de corriger des vulnérabilités, comprends ce qu'elles signifient vraiment.

Scanner avec Grype Croise les résultats avec un second scanner pour plus de fiabilité.

Signer avec Cosign Garantis l'intégrité de tes images et SBOM avec des signatures cryptographiques.

Auditer avec Lynis Scanne tes serveurs Linux pour détecter les faiblesses de configuration.

Registre et workflow complet

• Registre sécurisé : Intègre Trivy dans Harbor pour scanner automatiquement toutes les images poussées
• Conformité ANSSI : Applique les recommandations ANSSI-BP-028 sur tes systèmes

Ressources

Ressource	Description
Site Officiel	Page produit Aqua Security
Documentation	Documentation officielle
GitHub	Code source et issues
Trivy Action	Action GitHub officielle
Trivy Operator	Scan continu Kubernetes

Glissez pour voir

Questions fréquentes

Qu'est-ce que Trivy et à quoi sert-il ?

Quelle est la différence entre Trivy et d'autres scanners comme Grype ou Clair ?

Comment installer Trivy sur Linux, macOS ou Windows ?

Comment scanner une image Docker avec Trivy ?

Comment scanner du code source et détecter les vulnérabilités dans les dépendances ?

Comment scanner l'Infrastructure as Code (Terraform, Kubernetes) ?

Qu'est-ce qu'un SBOM et comment le générer avec Trivy ?

Comment intégrer Trivy dans un pipeline CI/CD GitLab ou GitHub Actions ?

Comment ignorer des vulnérabilités avec .trivyignore ?

Comment scanner un cluster Kubernetes avec Trivy Operator ?

Comment accélérer les scans Trivy en CI/CD ?

Quels formats de sortie Trivy supporte-t-il ?

Trivy peut-il détecter des secrets dans le code ?

Quelles sont les limites de Trivy ?

Comment scanner une machine virtuelle ou un système Linux avec Trivy ?

×

📖 Voir la documentation →