Trivy : scanner vulnérabilités containers et IaC — guide 2026

Introduction

Imaginez qu’un développeur de votre équipe pousse une image Docker en production un vendredi soir à Dakar. L’image se base sur python:3.11-slim, construite il y a six mois. Dans ce délai, dix-sept CVE critiques ont été publiées sur les bibliothèques système embarquées. Personne ne le sait. C’est exactement le scénario que Trivy a été conçu pour éliminer.

Trivy est le scanner de vulnérabilités open-source le plus adopté dans l’écosystème cloud-native en 2026. Maintenu par Aqua Security et soutenu par une communauté de plusieurs milliers de contributeurs sur GitHub, il couvre un périmètre que peu de ses concurrents atteignent en mode gratuit : images de containers OCI, systèmes de fichiers locaux, dépôts Git, fichiers de configuration Infrastructure-as-Code (Terraform, Kubernetes, Helm, Dockerfile), secrets dans le code source, et génération de Software Bill of Materials (SBOM) aux formats CycloneDX et SPDX. Tout cela depuis un seul binaire, sans agent permanent, sans envoi de données vers un SaaS tiers.

Ce guide vous accompagne de l’installation jusqu’à l’intégration en pipeline CI/CD, avec une attention particulière aux contraintes réelles des équipes IT en Afrique de l’Ouest : bande passante limitée, préférence pour les solutions auto-hébergées, absence de budget pour les licences SaaS onéreuses. À la fin de ce tutoriel, vous serez en mesure de détecter, rapporter et bloquer les vulnérabilités critiques avant qu’elles n’atteignent la production.

Prérequis

• Système : Linux (Ubuntu 22.04/24.04 ou Debian 12 recommandés) ou macOS. Windows via WSL2.
• RAM : 1 Go minimum disponible (la base de données de vulnérabilités Trivy pèse ~200 Mo une fois téléchargée).
• Disque : 500 Mo libres pour la base de données locale et le cache.
• Docker : installé et opérationnel si vous souhaitez scanner des images locales (facultatif pour scanner des dépôts).
• Git : version 2.x pour les scans de dépôts.
• Niveau : intermédiaire — vous savez ce qu’est un container Docker et avez déjà lu un Dockerfile.
• Temps estimé : environ 25 minutes pour parcourir l’intégralité du guide.

Étape 1 — Trivy vs Snyk vs Grype : choisir le bon outil

Avant d’installer quoi que ce soit, il est utile de comprendre pourquoi Trivy s’est imposé comme référence. Le marché des scanners de vulnérabilités pour containers compte plusieurs acteurs sérieux, et le bon choix dépend de votre contexte — notamment si vous opérez dans une PME en Afrique de l’Ouest avec des contraintes budgétaires et de connectivité.

Snyk est un outil SaaS très populaire dans les environnements startups européens et nord-américains. Son point fort est l’intégration IDE et la remédiation guidée. Son point faible majeur pour notre contexte : le plan gratuit est limité à 200 tests par mois, et la plupart des fonctionnalités avancées (IaC scanning, SBOM) nécessitent un abonnement payant. De plus, Snyk envoie vos données de scan vers ses serveurs — ce qui pose des questions de confidentialité pour les entreprises traitant des données sensibles.

Grype, maintenu par Anchore, est un concurrent direct de Trivy en mode open-source. Il est excellent pour le scan d’images containers et de systèmes de fichiers. Là où Grype montre ses limites : il ne couvre pas nativement l’IaC scanning (Terraform, Kubernetes manifests), ne génère pas de SBOM sans outil complémentaire (Syft), et la détection de secrets n’est pas intégrée. Trivy fait tout cela en un seul binaire.

Trivy se distingue sur quatre axes décisifs. Premièrement, il est entièrement gratuit et open-source (licence Apache 2.0), sans limite de scans ni de fonctionnalités. Deuxièmement, il fonctionne hors ligne une fois la base de données téléchargée — idéal quand votre serveur GitLab CI tourne sur un VPS OVH à Dakar sans accès fiable aux APIs externes. Troisièmement, son périmètre est le plus large : CVE sur OS packages et dépendances applicatives, mauvaises configurations IaC, secrets hardcodés, et génération SBOM. Quatrièmement, l’intégration Kubernetes via le Trivy Operator permet un scan continu de tous les workloads du cluster, pas seulement au moment du build.

La conclusion pratique : si vous avez un budget illimité et une équipe qui travaille dans GitHub.com, Snyk est confortable. Si vous voulez le maximum de fonctionnalités gratuitement, en auto-hébergé, avec une communauté active, Trivy est le choix rationnel en 2026.

Étape 2 — Installer Trivy

Trivy propose plusieurs méthodes d’installation. La méthode via le dépôt APT officiel d’Aqua Security est la plus propre sur Ubuntu/Debian car elle gère automatiquement les mises à jour. Sur macOS, Homebrew est la voie recommandée.

Sur Ubuntu / Debian (via APT)

Aqua Security maintient un dépôt APT signé. On commence par ajouter la clé GPG du dépôt pour vérifier l’authenticité des paquets, puis on ajoute la source et on installe. Ces trois opérations ne nécessitent qu’une connexion Internet ponctuelle — par la suite, Trivy peut fonctionner en mode hors ligne avec sa base de données locale.

# Téléchargement et ajout de la clé GPG officielle
sudo apt-get install -y wget gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key \
  | sudo apt-key add -

# Ajout du dépôt APT Aqua Security
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/trivy.list

# Installation
sudo apt-get update && sudo apt-get install -y trivy

# Vérification de la version installée
trivy --version

La commande trivy --version doit retourner quelque chose comme Version: 0.51.x. Si vous voyez ce résultat, Trivy est opérationnel. Au premier scan, il téléchargera automatiquement sa base de données de vulnérabilités dans ~/.cache/trivy/ — prévoyez environ 200 Mo de données à récupérer lors de cette première initialisation. Sur une connexion 4G africaine, cela prend entre 2 et 8 minutes selon la qualité du signal.

Sur macOS (via Homebrew)

# Installation via Homebrew
brew install trivy

# Vérification
trivy --version

Via binaire précompilé (pour environnements sans APT)

Pour les environnements Alpine Linux (fréquents dans les conteneurs CI), ou pour une installation manuelle sur un serveur sans accès au dépôt APT, vous pouvez télécharger le binaire directement depuis les releases GitHub :

# Remplacer 0.51.0 par la dernière version stable disponible sur
# https://github.com/aquasecurity/trivy/releases
VERSION="0.51.0"
wget https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz
tar -zxvf trivy_${VERSION}_Linux-64bit.tar.gz
sudo mv trivy /usr/local/bin/trivy

Étape 3 — Scanner une image Docker

Le cas d’usage le plus immédiat de Trivy est le scan d’une image container. La commande trivy image analyse l’ensemble des couches de l’image : packages système (apt, apk, rpm), dépendances applicatives (pip, npm, gem, maven, cargo), et fichiers de lock. Elle interroge plusieurs bases de données de vulnérabilités — NVD, GitHub Advisory Database, distributions Linux officicielles — pour identifier les CVE connues.

# Scanner une image publique depuis Docker Hub
trivy image python:3.11-slim

# Scanner une image locale construite avec docker build
trivy image mon-app:latest

# Filtrer uniquement les vulnérabilités CRITICAL et HIGH
trivy image --severity CRITICAL,HIGH python:3.11-slim

# Générer un rapport au format JSON (utile pour le CI)
trivy image --format json --output rapport-python.json python:3.11-slim

# Faire échouer le processus si au moins une CVE CRITICAL est trouvée
# (utile pour bloquer un pipeline CI)
trivy image --exit-code 1 --severity CRITICAL python:3.11-slim

L’output par défaut de Trivy est une table lisible directement dans le terminal. Pour chaque vulnérabilité, vous obtenez : l’identifiant CVE, le package concerné, la version installée, la version corrigée (si disponible), le score CVSS et un lien vers la fiche NVD. L’option --exit-code 1 est particulièrement précieuse en CI/CD : elle transforme Trivy en gate de qualité qui bloque le pipeline si une CVE critique est détectée, forçant l’équipe à décider consciemment de passer outre plutôt que d’ignorer silencieusement le problème.

Lors de votre premier scan, Trivy télécharge et met en cache la base de vulnérabilités. Les scans suivants utilisent le cache local et sont donc bien plus rapides. Pour forcer une mise à jour de la base :

trivy image --download-db-only

Étape 4 — Scanner Dockerfile et fichiers IaC Kubernetes

Au-delà des CVE dans les packages, une grande partie des incidents de sécurité en production provient de mauvaises configurations : un container qui tourne en root, un Pod Kubernetes sans limites de ressources, une règle de sécurité trop permissive dans un Security Group Terraform. La commande trivy config adresse exactement ces problèmes en analysant les fichiers de configuration avant qu’ils ne soient déployés.

# Scanner le Dockerfile du répertoire courant
trivy config ./Dockerfile

# Scanner tous les fichiers Kubernetes (YAML) d'un dossier
trivy config ./k8s/

# Scanner des fichiers Terraform
trivy config ./infra/terraform/

# Scanner un chart Helm (dossier ou archive .tgz)
trivy config ./helm/mon-chart/

# Scan récursif de tout le répertoire du projet
trivy config .

Pour un Dockerfile, Trivy vérifie par exemple : l’utilisation de USER root sans nécessité, l’absence d’instruction HEALTHCHECK, l’utilisation de latest comme tag (qui rend les builds non reproductibles), ou des instructions ADD là où COPY suffirait. Pour les manifests Kubernetes, il contrôle notamment l’absence de securityContext, les containers sans readOnlyRootFilesystem, les Pods sans contraintes de ressources (requests/limits), et l’utilisation de hostNetwork: true ou hostPID: true. Ces contrôles s’appuient sur les benchmarks CIS Kubernetes et les politiques OPA Rego intégrées à Trivy, maintenues à jour par la communauté Aqua Security.

Étape 5 — Scanner le code source pour les secrets

Les secrets hardcodés dans le code source — clés API, tokens JWT, mots de passe de base de données, clés SSH privées — constituent l’une des causes les plus fréquentes de compromission de systèmes. Un développeur qui commit accidentellement une clé AWS dans un dépôt public sur GitHub peut provoquer une facture de plusieurs milliers de dollars en quelques heures. Trivy intègre un moteur de détection de secrets basé sur des expressions régulières et des patterns de haute précision.

# Scanner le répertoire courant pour les secrets uniquement
trivy fs --scanners secret .

# Scanner un répertoire spécifique
trivy fs --scanners secret /chemin/vers/mon-projet/

# Combiner scan de vulnérabilités ET secrets en une seule commande
trivy fs --scanners vuln,secret .

# Générer un rapport JSON des secrets détectés
trivy fs --scanners secret --format json --output secrets-report.json .

# Scanner un dépôt Git distant (sans cloner localement)
trivy repo --scanners secret https://github.com/mon-org/mon-repo

Trivy détecte une large variété de patterns : clés AWS (AKIA...), tokens GitHub, clés API Stripe, chaînes de connexion de base de données, clés privées RSA et ED25519, tokens JWT, et bien d’autres. Il est important de comprendre que le scan de secrets est complémentaire à un outil dédié comme git-secrets ou un pre-commit hook — il ne scanne pas l’historique Git complet par défaut. Si vous souhaitez auditer l’historique complet d’un dépôt (pour chercher des secrets commités puis supprimés), utilisez trivy repo avec l’option --include-dev-deps ou, mieux, combinez avec gitleaks pour une couverture exhaustive de l’historique.

Étape 6 — Génération de SBOM CycloneDX et SPDX

Un Software Bill of Materials (SBOM) est un inventaire structuré de tous les composants d’un logiciel : packages, bibliothèques, versions, licences, dépendances transitives. En 2026, la génération de SBOM est devenue une exigence réglementaire dans de nombreux secteurs (directive NIS2 en Europe, Executive Order sur la cybersécurité aux États-Unis), et une bonne pratique indispensable pour toute organisation qui veut répondre rapidement lors d’une alerte de sécurité majeure — du type Log4Shell en 2021, où les équipes ont mis des semaines à identifier quels systèmes étaient affectés faute d’inventaire précis.

# Générer un SBOM au format CycloneDX JSON pour une image Docker
trivy image --format cyclonedx --output sbom-monapp.cdx.json mon-app:latest

# Générer un SBOM au format SPDX JSON
trivy image --format spdx-json --output sbom-monapp.spdx.json mon-app:latest

# Générer un SBOM pour un système de fichiers local
trivy fs --format cyclonedx --output sbom-projet.cdx.json .

# Scanner un SBOM existant pour trouver des CVE
# (utile si le SBOM a été généré par un autre outil)
trivy sbom sbom-monapp.cdx.json

Le format CycloneDX (porté par l’OWASP) et le format SPDX (standard Linux Foundation) sont les deux standards reconnus en 2026. CycloneDX est généralement préféré dans les workflows DevSecOps car son schéma JSON est plus compact et mieux supporté par les outils d’analyse downstream. Une fois votre SBOM généré, vous pouvez le stocker en artefact de build dans votre CI/CD, le signer avec Cosign pour prouver son intégrité, et le partager avec vos clients ou régulateurs comme preuve de traçabilité des composants. La dernière commande montre une fonctionnalité avancée : Trivy peut scanner un fichier SBOM existant pour détecter de nouvelles CVE apparues après sa génération — ce qui permet un monitoring continu sans avoir à réaccéder à l’image ou au code source.

Étape 7 — Intégration GitHub Actions et GitLab CI

L’intérêt maximal de Trivy se réalise quand il est intégré dans votre pipeline CI/CD. Plutôt que de scanner manuellement avant chaque déploiement, le scan devient automatique à chaque push ou merge request, et les résultats sont visibles directement dans l’interface de votre forge logicielle. Voici les configurations pour les deux plateformes les plus utilisées.

GitHub Actions

Aqua Security maintient une action officielle aquasecurity/trivy-action sur le GitHub Marketplace. Elle encapsule Trivy dans un step réutilisable, avec upload automatique des résultats vers le Security tab de GitHub via le format SARIF.

# .github/workflows/trivy-scan.yml
name: Trivy Security Scan

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

jobs:
  trivy-scan:
    name: Scan vulnerabilités
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build image Docker
        run: docker build -t mon-app:${{ github.sha }} .

      # Scan de l'image avec upload vers GitHub Security
      - name: Scan image avec Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: mon-app:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: 1

      - name: Upload résultats SARIF vers GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: trivy-results.sarif

      # Scan IaC séparé
      - name: Scan configuration IaC
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: config
          scan-ref: ./k8s/
          format: table
          exit-code: 0

Le paramètre exit-code: 1 sur le scan d’image fait échouer le job (et donc bloque le merge) si une CVE CRITICAL ou HIGH est trouvée. Le paramètre exit-code: 0 sur le scan IaC signifie que les erreurs de configuration sont rapportées sans bloquer — c’est une approche progressive qui évite de paralyser l’équipe dès le premier jour. Vous pouvez durcir en passant à exit-code: 1 une fois que votre base de code est propre.

GitLab CI

Pour un GitLab auto-hébergé (cas fréquent pour les équipes africaines qui privilégient la souveraineté des données), la configuration est légèrement différente — on utilise directement le binaire Trivy dans un job, ou l’image Docker officielle de Trivy.

# Ajout dans votre .gitlab-ci.yml existant

variables:
  TRIVY_VERSION: "0.51.0"

trivy-scan:
  stage: test
  image: aquasec/trivy:latest
  variables:
    # Cache la DB Trivy entre les pipelines pour éviter le re-téléchargement
    TRIVY_CACHE_DIR: .trivycache
  cache:
    paths:
      - .trivycache/
  script:
    # Scan de l'image construite dans le stage précédent
    - trivy image
        --exit-code 1
        --severity CRITICAL,HIGH
        --no-progress
        --format table
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    # Scan IaC
    - trivy config --exit-code 0 ./k8s/
  artifacts:
    reports:
      # Upload le rapport JSON comme artefact GitLab
      junit: trivy-report.xml
    paths:
      - trivy-report.xml
    expire_in: 30 days
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

La directive cache: sur .trivycache/ est essentielle dans un contexte de connectivité limitée : elle évite de re-télécharger la base de vulnérabilités (200 Mo) à chaque pipeline. GitLab conserve ce cache entre les runs sur le même runner, ce qui fait passer le temps de scan de 3-4 minutes à moins de 30 secondes après la première initialisation.

Étape 8 — Trivy Operator Kubernetes pour scan continu

Les étapes précédentes couvrent le scan au moment du build et du déploiement. Mais que se passe-t-il pour les workloads déjà en production quand une nouvelle CVE est publiée ? C’est le problème que résout le Trivy Operator : il s’installe dans votre cluster Kubernetes et surveille en continu tous les containers en cours d’exécution, déclenchant automatiquement des scans à intervalle régulier et exposant les résultats sous forme de Custom Resources Kubernetes.

# Installation via Helm (méthode recommandée)
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update

# Déploiement dans le namespace trivy-system
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set trivy.ignoreUnfixed=true

# Vérifier que l'Operator tourne
kubectl get pods -n trivy-system

# Lister les rapports de vulnérabilités générés (VulnerabilityReports)
kubectl get vulnerabilityreports -A

# Voir le rapport d'un container spécifique
kubectl get vulnerabilityreport -n default  -o yaml

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

Une fois installé, l’Operator crée automatiquement un VulnerabilityReport et un ConfigAuditReport pour chaque workload (Deployment, StatefulSet, DaemonSet, CronJob) dans tous les namespaces. Ces ressources sont des objets Kubernetes standard : vous pouvez les requêter avec kubectl, les exposer dans Grafana via le Prometheus exporter fourni, ou les intégrer dans vos alertes PagerDuty / Telegram. Le paramètre ignoreUnfixed=true exclut les CVE pour lesquelles aucun correctif n’est encore disponible — ce qui réduit le bruit et permet aux équipes de se concentrer sur les vulnérabilités actionnables.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les équipes IT en Afrique de l’Ouest, Trivy présente des avantages concrets qui vont au-delà de sa gratuité. Le premier et le plus important : tout le traitement se fait localement. Contrairement à Snyk ou d’autres SaaS de scanning, Trivy n’envoie jamais votre image, votre code ou vos configurations vers des serveurs tiers. La base de vulnérabilités est téléchargée une fois et mise en cache. Sur une connexion mobile 4G à Abidjan ou Bamako qui coûte par mégaoctet, cela représente une économie réelle : après le premier téléchargement (~200 Mo), les scans suivants ne consomment quasiment pas de bande passante.

Le second avantage est la compatibilité avec GitLab auto-hébergé, qui est la forge préférée des entreprises et administrations qui veulent garder leur code sur site. La configuration GitLab CI présentée à l’Étape 7 fonctionne identiquement sur GitLab.com et sur un GitLab auto-hébergé installé sur un VPS OVH, Contabo, ou même sur un serveur dédié dans les locaux de l’entreprise. Le cache de la base Trivy est stocké localement sur le runner GitLab — un seul téléchargement pour tous les projets qui partagent le même runner.

Le troisième axe d’adaptation concerne les alertes pour les équipes IT. En Afrique de l’Ouest, l’outil de communication d’équipe le plus répandu n’est pas Slack mais Telegram — moins cher, disponible sur connexions lentes, multiplateforme. Vous pouvez connecter Trivy à Telegram via un simple bot : à la fin de chaque pipeline CI, un script envoie le résumé des CVE critiques dans un groupe Telegram dédié. Voici un exemple de script shell à ajouter en fin de job GitLab CI :

# Envoi d'un résumé Trivy vers un groupe Telegram
# Variables à définir dans GitLab CI/CD Variables : TELEGRAM_TOKEN, TELEGRAM_CHAT_ID

CRITICAL_COUNT=$(trivy image --severity CRITICAL --quiet --format json mon-app:latest \
  | python3 -c "import json,sys; data=json.load(sys.stdin); \
    print(sum(len(r.get('Vulnerabilities') or []) for r in data.get('Results', [])))")

MESSAGE="🔒 Trivy Scan — ${CI_PROJECT_NAME} (${CI_COMMIT_SHORT_SHA})%0A"
MESSAGE+="CVE CRITICAL : ${CRITICAL_COUNT}%0A"
MESSAGE+="Pipeline : ${CI_PIPELINE_URL}"

curl -s -X POST \
  "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
  -d "chat_id=${TELEGRAM_CHAT_ID}" \
  -d "text=${MESSAGE}" \
  -d "parse_mode=HTML"

Pour les PME qui n’ont pas encore de cluster Kubernetes mais qui utilisent Docker sur un VPS unique, le Trivy Operator n’est pas nécessaire. Un cron job hebdomadaire qui scanne toutes les images locales et envoie le rapport Telegram est une solution plus adaptée à leur maturité opérationnelle, et tout aussi efficace pour leur taille.

Tutoriels frères

• Cosign : signer et vérifier des images Docker sur Kubernetes — guide 2026 — pour aller plus loin après le scan : signer cryptographiquement vos images vérifiées.
• SBOM CycloneDX et SPDX : générer, stocker et exploiter votre inventaire logiciel — approfondir la génération et la gestion des SBOM au-delà de Trivy.
• GitLab CI pipeline DevSecOps complet : tests, scan, signature, déploiement — intégrer Trivy dans un pipeline CI/CD de bout en bout.

Pour aller plus loin

• Retour au pilier : Sécurité supply-chain logiciel : SBOM, signing, scanning (2026)
• Documentation officielle Trivy : aquasec.com/products/trivy
• Dépôt GitHub officiel avec exemples et intégrations : github.com/aquasecurity/trivy
• Tutoriel suivant recommandé dans le cluster : Cosign : signer vos images Docker après le scan Trivy

FAQ

# CVE-2023-XXXXX — libc: non exploitable car le vecteur d'attaque
# nécessite un accès local que notre architecture n'expose pas
CVE-2023-XXXXX