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

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, devenu rapidement populaire dans la communauté DevOps pour sa fiabilité, sa rapidité et sa facilité d’intégration dans les pipelines CI/CD.

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

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 complet : vulnérabilités + secrets + licences
trivy image --scanners vuln,secret,license alpine:latest

# Scan rapide : vulnérabilités uniquement (recommandé en CI/CD)
trivy image --scanners vuln alpine:latest

# Scan IaC complet : misconfigurations + secrets
trivy fs --scanners misconfig,secret ./mon-projet/

Exemple de sortie d’un scan complet :

$ trivy image --scanners vuln,secret,license alpine:latest
2025-12-10T07:17:27Z    INFO    [vuln] Vulnerability scanning is enabled
2025-12-10T07:17:27Z    INFO    [secret] Secret scanning is enabled
2025-12-10T07:17:27Z    INFO    [license] License scanning is enabled
2025-12-10T07:17:28Z    INFO    Detected OS     family="alpine" version="3.23.0"
2025-12-10T07:17:28Z    INFO    [alpine] Detecting vulnerabilities...

Report Summary

┌───────────────────────────────┬────────┬─────────────────┬─────────┬──────────┐
│            Target             │  Type  │ Vulnerabilities │ Secrets │ Licenses │
├───────────────────────────────┼────────┼─────────────────┼─────────┼──────────┤
│ alpine:latest (alpine 3.23.0) │ alpine │        0        │    -    │    -     │
├───────────────────────────────┼────────┼─────────────────┼─────────┼──────────┤
│ OS Packages                   │   -    │        -        │    -    │    19    │
└───────────────────────────────┴────────┴─────────────────┴─────────┴──────────┘

OS Packages (license)
Total: 19 (UNKNOWN: 0, LOW: 9, MEDIUM: 1, HIGH: 9, CRITICAL: 0)

┌────────────────────────┬──────────────────┬────────────────┬──────────┐
│        Package         │     License      │ Classification │ Severity │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ alpine-baselayout      │ GPL-2.0-only     │ restricted     │ HIGH     │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ alpine-keys            │ MIT              │ notice         │ LOW      │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ apk-tools              │ GPL-2.0-only     │ restricted     │ HIGH     │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ ca-certificates-bundle │ MPL-2.0          │ reciprocal     │ MEDIUM   │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ libcrypto3             │ Apache-2.0       │ notice         │ LOW      │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ musl                   │ MIT              │ notice         │ LOW      │
├────────────────────────┼──────────────────┼────────────────┼──────────┤
│ zlib                   │ Zlib             │ notice         │ LOW      │
└────────────────────────┴──────────────────┴────────────────┴──────────┘

Pour voir un exemple avec des vulnérabilités détectées, scannons une image nginx :

$ trivy image --scanners vuln nginx:latest
2025-12-10T07:17:38Z    INFO    [vuln] Vulnerability scanning is enabled
2025-12-10T07:17:38Z    INFO    Detected OS     family="debian" version="13.2"
2025-12-10T07:17:38Z    INFO    [debian] Detecting vulnerabilities...

Report Summary

┌────────────────────────────┬────────┬─────────────────┐
│           Target           │  Type  │ Vulnerabilities │
├────────────────────────────┼────────┼─────────────────┤
│ nginx:latest (debian 13.2) │ debian │       106       │
└────────────────────────────┴────────┴─────────────────┘

nginx:latest (debian 13.2)
Total: 106 (UNKNOWN: 1, LOW: 85, MEDIUM: 16, HIGH: 4, CRITICAL: 0)

┌──────────────────┬─────────────────────┬──────────┬──────────────┬───────────────────┬───────────────┐
│     Library      │    Vulnerability    │ Severity │    Status    │ Installed Version │ Fixed Version │
├──────────────────┼─────────────────────┼──────────┼──────────────┼───────────────────┼───────────────┤
│ bsdutils         │ CVE-2025-14104      │ MEDIUM   │ affected     │ 1:2.41-5          │               │
├──────────────────┼─────────────────────┼──────────┼──────────────┼───────────────────┼───────────────┤
│ curl             │ CVE-2025-10966      │ LOW      │ affected     │ 8.14.1-2+deb13u2  │               │
├──────────────────┼─────────────────────┼──────────┼──────────────┼───────────────────┼───────────────┤
│ libc-bin         │ CVE-2019-1010022    │ LOW      │ affected     │ 2.41-12           │               │
└──────────────────┴─────────────────────┴──────────┴──────────────┴───────────────────┴───────────────┘

Scan de code Infrastructure as Code (IaC)

Trivy peut analyser vos fichiers Terraform, Kubernetes YAML, Dockerfile, CloudFormation, Helm et Ansible pour détecter les mauvaises configurations :

# Scanner un dossier Terraform
trivy config ./infra/terraform

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

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

# Scanner un chart Helm
trivy config ./charts/mon-app/

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

Exemple de sortie d’un scan Terraform avec des misconfigurations :

$ trivy config ./infra/terraform/
2025-12-10T07:19:05Z    INFO    [misconfig] Misconfiguration scanning is enabled
2025-12-10T07:19:06Z    INFO    [terraform scanner] Scanning root module

Report Summary

┌─────────┬───────────┬───────────────────┐
│ Target  │   Type    │ Misconfigurations │
├─────────┼───────────┼───────────────────┤
│ main.tf │ terraform │         8         │
└─────────┴───────────┴───────────────────┘

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é de plusieurs manières, par ordre de priorité décroissante :

1. Les flags de la CLI (priorité maximale)
2. Les variables d’environnement
3. Le fichier de configuration trivy.yaml

Les flags de la CLI

Vous pouvez afficher la liste des options disponibles avec --help :

$ trivy --help
Scanner for vulnerabilities in container images, file systems,
and Git repositories, as well as for configuration issues and hard-coded secrets

Usage:
  trivy [global flags] command [flags] target

Scanning Commands
  config      Scan config files for misconfigurations
  filesystem  Scan local filesystem
  image       Scan a container image
  kubernetes  [EXPERIMENTAL] Scan kubernetes cluster
  repository  Scan a repository
  rootfs      Scan rootfs
  sbom        Scan SBOM for vulnerabilities and licenses
  vm          [EXPERIMENTAL] Scan a virtual machine image

Flags:
      --cache-dir string   cache directory (default "~/.cache/trivy")
  -c, --config string      config path (default "trivy.yaml")
  -d, --debug              debug mode
      --insecure           allow insecure server connections
  -q, --quiet              suppress progress bar and log output
      --timeout duration   timeout (default 5m0s)
  -v, --version            show version

Les variables d’environnement

Trivy peut être configuré via des variables d’environnement. Le format est TRIVY_ suivi du nom du flag en majuscules :

# Exemples de variables d'environnement
export TRIVY_DEBUG=true
export TRIVY_CACHE_DIR=/path/to/cache
export TRIVY_TIMEOUT=10m

Le fichier de configuration

Il est possible d’utiliser un fichier nommé trivy.yaml pour définir les options de Trivy. Voici un exemple de fichier :

# Options globales
cache:
  dir: "/tmp/trivy-cache"
debug: false
timeout: 10m

# Options de rapport
format: "table"
exit-code: 1
severity:
  - HIGH
  - CRITICAL
list-all-pkgs: false
dependency-tree: false

# Options de scan
scan:
  scanners:
    - vuln
    - secret
  skip-dirs:
    - /lib64
    - /lib
    - /usr/lib
    - /usr/include
  offline: false

# Options de vulnérabilités
vulnerability:
  ignore-unfixed: true
  ignore-status: []

# Options de packages
pkg:
  types:
    - os
    - library

La documentation 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 d’une application. Trivy peut générer un SBOM puis le scanner ultérieurement, ce qui est idéal pour les pipelines CI/CD et les environnements air-gapped :

SBOM et vulnérabilités

L’option --format cyclonedx (ou spdx-json) génère un SBOM et désactive automatiquement la détection de vulnérabilités. Pour analyser les failles, scannez ensuite le SBOM généré avec trivy sbom.

# Étape 1 : Générer le SBOM lors du build (format CycloneDX)
$ trivy image --format cyclonedx --output sbom.json alpine:latest
2025-12-10T07:19:32Z    INFO    "--format cyclonedx" disables security scanning
2025-12-10T07:19:34Z    INFO    Detected OS     family="alpine" version="3.23.0"

# Le SBOM généré contient l'inventaire complet des composants
$ head -20 sbom.json
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "tools": {
      "components": [{
        "name": "trivy",
        "version": "0.68.1"
      }]
    }
  }
}

# Étape 2 : Scanner le SBOM (sans accès à l'image)
$ trivy sbom sbom.json
2025-12-10T07:19:44Z    INFO    [vuln] Vulnerability scanning is enabled
2025-12-10T07:19:44Z    INFO    Detected SBOM format    format="cyclonedx-json"
2025-12-10T07:19:44Z    INFO    Detected OS     family="alpine" version="3.23.0"

Report Summary
┌────────────────────────────────┬────────┬─────────────────┐
│             Target             │  Type  │ Vulnerabilities │
├────────────────────────────────┼────────┼─────────────────┤
│ /tmp/sbom.json (alpine 3.23.0) │ alpine │        0        │
└────────────────────────────────┴────────┴─────────────────┘

Cette approche découple la génération de l’analyse et s’intègre dans les stratégies de supply-chain security (SLSA, ANSSI). Le SBOM permet de tracer tous les composants et de réagir rapidement lors de la publication d’une nouvelle 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:latest
    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-latest
    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.31.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.31.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

Après avoir maîtrisé Trivy, complétez votre expertise DevSecOps :

• Registre sécurisé : Intégrez Trivy dans Harbor pour scanner automatiquement vos images.
• Scan alternatif : Comparez avec Grype pour croiser les résultats
• Supply Chain : Signez vos images avec Cosign
• Durcissement : Auditez vos systèmes avec Lynis
• Conformité : Appliquez les recommandations ANSSI-BP-028

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