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

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

Trivy est le scanner de sécurité open source d'Aqua Security. Il cherche les vulnérabilités connues des dépendances et des images, les secrets dans le code et les mauvaises configurations de l'infrastructure as code, avec les commandes trivy fs, trivy image, trivy config et trivy sbom.

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

Trivy et Grype cherchent des vulnérabilités connues mais ne lisent pas les mêmes bases : sur l'image node:14, Grype a trouvé 2032 correspondances et Trivy 1455. Trivy couvre aussi les secrets et l'IaC, Grype affiche l'EPSS et le KEV. Croiser les deux réduit les angles morts.

Q: Comment installer Trivy sur Linux, macOS ou Windows ?

Installez une version précise, au moins la 0.72.0, jamais latest : l'image officielle épinglée par digest est la forme la plus sûre, ou asdf avec une version fixée. Proscrivez la 0.69.4, les images 0.69.5 et 0.69.6 et les releases 0.27.0 à 0.69.1.

Q: Comment scanner une image Docker avec Trivy ?

Lancez trivy image --scanners vuln sur l'image désignée par son digest. Ajoutez --ignore-unfixed pour ne garder que les vulnérabilités corrigeables, et --severity CRITICAL --exit-code 1 pour bloquer. Mesuré : 54 vulnérabilités sur nginx:1.31.3-alpine, 1411 sur node:14.

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

Lancez trivy fs . à la racine du projet : il lit les fichiers de dépendances et lance par défaut les scanners vuln et secret. Mesuré, requests 2.25.1 donne 4 vulnérabilités MEDIUM. L'analyse des configurations demande --scanners misconfig.

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

Lancez trivy config . ou trivy fs avec --scanners misconfig : Trivy compare Dockerfile, Terraform, Kubernetes, Helm et CloudFormation à des règles intégrées, comme DS-0002 pour un Dockerfile sans USER ou AWS-0086 pour un bucket S3 ouvert.

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

Un SBOM est l'inventaire des composants d'un logiciel. Trivy le génère avec trivy fs --format cyclonedx --output sbom.json, au format CycloneDX 1.7, puis le rescanne plus tard avec trivy sbom sbom.json, sans le code ni l'image.

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

Lancez l'image officielle Trivy épinglée par digest plutôt qu'une action tierce, avec --severity et --exit-code pour bloquer, après avoir supprimé tout trivy.yaml apporté par la pull request. Sur GitLab, utilisez la même image comme image du job.

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

Déclarez les constats acceptés dans .trivyignore, avec une justification et une date d'expiration (exp:AAAA-MM-JJ), passé laquelle le constat réapparaît. Le fichier .trivyignore est lu par défaut, la variante .trivyignore.yaml seulement avec --ignorefile.

Q: Comment scanner un cluster Kubernetes avec Trivy Operator ?

Installez Trivy Operator avec le chart Helm aqua/trivy-operator en version 0.36.0, puis consultez les vulnerabilityreports et configauditreports. Le chart lance Trivy 0.74.0 par tag seulement : fixez les références d'images vous-même sur un cluster sensible.

30 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 1 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Trivy est le scanner de sécurité open source d'Aqua Security, publié en 2019 et suivi par plus de 38 000 étoiles sur GitHub. En une commande, il cherche les vulnérabilités connues des dépendances et des images, les secrets oubliés dans le code et les mauvaises configurations de l'infrastructure as code. Cette leçon s'adresse à un DevOps qui veut un seul outil pour ces trois contrôles, et le faire bloquer en CI.

Trivy est aussi devenu, en 2026, un cas d'école de ce qu'il est censé détecter : en mars, des identifiants volés ont permis de publier une version piégée et de déplacer 76 des 77 tags de son action GitHub vers un voleur de secrets. On l'installe donc comme n'importe quelle dépendance, épinglé. Tout le reste est mesuré sur Trivy 0.74.0 : 4 vulnérabilités, un jeton GitHub et 10 erreurs de configuration sur un projet de test, 1411 vulnérabilités sur l'image node:14, et un trivy.yaml de deux lignes qui vide le rapport sans un mot.

Ce que vous allez apprendre

Installer Trivy en version épinglée, après ses deux incidents de 2026
Scanner dépendances, secrets, images et infrastructure as code
Faire échouer un job CI sur un seuil décidé, et non sur le défaut
Neutraliser le piège du trivy.yaml chargé automatiquement
Produire un SBOM et le rescanner sans le code source
Situer ce que Trivy ne voit pas, et quand croiser avec Grype

Qu'est-ce que Trivy ?

Trivy combine une cible, ce qu'on scanne, et des scanners, ce qu'on y cherche. La même commande sert ainsi à vérifier un dépôt avant le merge, une image avant la publication ou un dossier Terraform avant le déploiement. Il s'appuie sur une base de vulnérabilités qu'il télécharge et met en cache, et sur des règles intégrées pour les erreurs de configuration.

Cible	Commande	Usage typique
Dossier ou dépôt	`trivy fs .`	Dépendances, secrets, IaC d'un projet
Image de conteneur	`trivy image <image>`	Paquets de l'OS et des langages dans l'image
Fichiers de configuration	`trivy config .`	Dockerfile, Terraform, manifestes Kubernetes
SBOM existant	`trivy sbom sbom.json`	Rescanner un inventaire sans le code
Système complet	`trivy rootfs /`	Paquets installés sur une machine
Cluster	`trivy k8s`	Workloads et configuration d'un cluster

Les scanners s'activent avec --scanners : vuln (vulnérabilités connues), secret (jetons et mots de passe), misconfig (erreurs de configuration) et license (licences). Mesuré : sur un dossier, trivy fs lance vuln et secret sans qu'on le demande, et n'analyse les configurations qu'avec misconfig explicitement demandé.

Installer une version épinglée

Après les incidents de 2026, la règle est simple : on n'installe pas « la dernière », on installe une version précise, au moins la 0.72.0, vérifiée. L'image officielle épinglée par digest est la forme la plus sûre, en CI comme sur le poste.

TRIVY="aquasec/trivy:0.74.0@sha256:62b1e65e8869bc4b4c6aa4fa2b21595256c7c2f6018a9d9ad61caf87187c1969"

# Le cache de la base de vulnérabilités vit dans un volume, réutilisé d'un scan à l'autre
docker run --rm -v "$PWD:/src" -w /src -v trivy-cache:/root/.cache "$TRIVY" fs .

Sur le poste, un gestionnaire de versions comme asdf fixe la version dans le dépôt : asdf install trivy 0.74.0 puis asdf set trivy 0.74.0, qui l'écrit dans .tool-versions. Évitez latest, qui installerait sans prévenir la prochaine release, saine ou non.

Scanner un projet : dépendances et secrets

Le banc de cette leçon est un petit projet volontairement fautif : un requirements.txt qui épingle requests==2.25.1, un fichier config.py qui contient un faux jeton GitHub, un Dockerfile et un Terraform mal configurés. Lancé sans option, Trivy trouve les deux premiers problèmes.

trivy fs .

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

config.py (secrets)
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 1)
CRITICAL: GitHub (github-pat)
GitHub Personal Access Token
   1 [ GITHUB_TOKEN = "****************************************"

Deux points se lisent dans cette sortie. Le secret est classé CRITICAL et sa valeur est masquée dans le rapport, ce qui évite de le recopier dans un journal de CI. Et le Dockerfile comme le Terraform n'apparaissent pas : sans --scanners misconfig, Trivy ne les analyse pas. Un « 0 problème » sur un dossier d'infrastructure peut donc simplement signifier que le scanner n'a pas regardé.

Analyser l'infrastructure as code

Le scanner misconfig compare les fichiers de configuration à des règles intégrées : un conteneur qui tourne en root, un bucket ouvert au public, un chiffrement absent. Il couvre Dockerfile, Terraform, Kubernetes, Helm et CloudFormation.

trivy fs --scanners vuln,secret,misconfig .
# ou, pour les seules configurations :
trivy config .

Mesuré sur les deux fichiers du banc, 3 constats pour le Dockerfile et 7 pour le Terraform, chacun avec son identifiant de règle :

FROM python:3.12
RUN apt-get update && apt-get install -y curl
COPY . /app
CMD ["python", "/app/main.py"]

Règle	Sévérité	Ce qu'elle signale
`DS-0002`	HIGH	Aucune instruction `USER` non-root
`DS-0029`	HIGH	`apt-get install` sans `--no-install-recommends`
`DS-0026`	LOW	Pas d'instruction `HEALTHCHECK`
`AWS-0086`, `AWS-0087`, `AWS-0091`, `AWS-0093`	HIGH	Le blocage d'accès public du bucket laisse passer ACL et politiques publiques
`AWS-0132`	HIGH	Pas de chiffrement par une clé gérée par le client
`AWS-0090`	MEDIUM	Versionnement désactivé
`AWS-0089`	LOW	Journalisation désactivée

resource "aws_s3_bucket" "donnees" {
  bucket = "mon-bucket-de-test"
}

resource "aws_s3_bucket_public_access_block" "donnees" {
  bucket              = aws_s3_bucket.donnees.id
  block_public_acls   = false
  block_public_policy = false
}

Une règle n'est pas une vérité absolue : un bucket de site statique est public par conception. La bonne réponse est une exception documentée, pas la désactivation du scanner. La leçon suivante, sur Checkov, approfondit l'analyse de l'IaC avec un second outil.

Scanner une image de conteneur

trivy image inventorie les paquets du système d'exploitation de l'image et ceux des langages qu'elle embarque, puis les confronte à sa base. Le résultat dépend surtout de l'âge de l'image de base. Mesuré le 1er octobre 2026 :

Image scannée	Vulnérabilités	Dont CRITICAL	Avec `--ignore-unfixed`
`nginx:1.31.3-alpine` (Alpine 3.24.1)	54	0	54
`node:14` (Debian 10, fin de vie)	1411	21	1086

trivy image --scanners vuln \
  nginx:1.31.3-alpine@sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752

L'option --ignore-unfixed masque les vulnérabilités sans correctif publié. Elle ne change rien sur l'image Alpine récente, où tout a déjà un correctif, et retire 325 constats sur node:14. Elle réduit le bruit de ce que l'équipe ne peut pas corriger, mais ne doit pas faire oublier qu'une image en fin de vie ne recevra plus de correctifs : la seule issue est de changer d'image de base. Les chiffres bougent chaque jour avec la base de vulnérabilités ; lisez-les comme un ordre de grandeur.

Faire échouer le pipeline

Mesuré : Trivy sort en code 0 quels que soient ses constats. Sans option, il informe et laisse passer. Le blocage se décide avec deux options : la sévérité retenue et le code de sortie voulu.

trivy image --scanners vuln --severity CRITICAL --exit-code 1 "$IMAGE"

Sur le requirements.txt du banc, qui ne contient que 4 vulnérabilités MEDIUM, --severity HIGH,CRITICAL --exit-code 1 sort en 0, ce qui est voulu, et --severity MEDIUM --exit-code 1 sort en 1. Testez toujours le seuil dans les deux sens. Le choix des sévérités qui bloquent, et la place de ce contrôle parmi les autres, sont l'objet de la leçon sur le pipeline sécurisé.

Le piège du trivy.yaml chargé automatiquement

Trivy charge tout seul un fichier trivy.yaml présent dans le dossier courant. C'est pratique sur un poste, et dangereux en CI : une pull request qui ajoute ce fichier modifie le comportement du scanner qui doit la juger.

severity:
  - CRITICAL

Mesuré sur le banc : le journal affiche Loaded file_path="trivy.yaml", et les 4 vulnérabilités MEDIUM disparaissent du rapport, sans avertissement. En ajoutant scan: { scanners: [vuln] }, c'est le jeton GitHub CRITICAL qui disparaît à son tour. Le schéma suit ce chemin, de la pull request au job vert, et montre la parade, décidée dans le job lui-même et non dans le dépôt que la PR peut modifier.

Source · SVG

Trois parades, à combiner :

passer les options en ligne de commande (--severity, --scanners, --exit-code), qui l'emportent sur le fichier ;
imposer un fichier de configuration contrôlé, hors du code de la PR, par --config ou la variable TRIVY_CONFIG ;
supprimer trivy.yaml, trivy.yml et .trivy.yaml avant le scan quand le dépôt est extrait, ou scanner l'image sans extraire le dépôt.

Documenter les exceptions

Un constat accepté se déclare dans un fichier .trivyignore, avec une date d'expiration : passé cette date, l'exception tombe et le constat réapparaît. La leçon sur la SCA l'a mesuré, ainsi que le piège de la variante .trivyignore.yaml, qui n'est lue qu'avec --ignorefile.

# Composant non exposé, corrigé dans la release 2.0 (ticket SEC-142)
CVE-2021-23337 exp:2027-01-01

Générer et rescanner un SBOM

Un SBOM (Software Bill of Materials) est l'inventaire des composants d'un logiciel. Trivy le produit au format CycloneDX ou SPDX, puis sait rescanner cet inventaire plus tard, sans le code ni l'image : c'est ce qui permet de savoir en quelques minutes si une nouvelle CVE touche une version déjà livrée.

# Produire le SBOM, sans recherche de vulnérabilités
trivy fs --format cyclonedx --output sbom.json .

# Le rescanner, aujourd'hui ou dans six mois
trivy sbom sbom.json

Mesuré sur le banc : le SBOM est au format CycloneDX 1.7 et contient 2 composants, requests et sa déclaration ; trivy sbom y retrouve les 4 vulnérabilités MEDIUM du scan direct. Produire un SBOM ne lance aucune recherche de vulnérabilités : ce sont deux étapes distinctes. Le module sur la supply chain consacre une leçon au SBOM.

Contrôler la conformité CIS d'une image

Trivy sait évaluer une image contre le CIS Docker Benchmark, pour la partie qui concerne les images (section 4). Les contrôles manuels, comme « utiliser des images de base de confiance », restent sans verdict.

trivy image --compliance docker-cis-1.6.0 \
  nginx:1.31.3-alpine@sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752

Mesuré sur nginx:1.31.3-alpine : 4.1 (créer un utilisateur pour le conteneur) et 4.6 (ajouter un HEALTHCHECK) sont en FAIL ; 4.4, 4.7, 4.9 et 4.10, dont « pas de secrets dans les Dockerfiles », passent. Le premier échec rejoint ce qu'a montré la leçon sur la sécurité de Docker : l'image nginx officielle démarre en root.

Intégrer Trivy en CI

En CI, le plus simple et le plus sûr est de lancer l'image officielle épinglée par digest, comme sur le poste : c'est l'action aquasecurity/trivy-action qui a été compromise en mars 2026, et un appel direct à l'image retire cet intermédiaire. Le workflow ci-dessous construit l'image, la scanne avec un seuil explicite et publie le rapport SARIF dans l'onglet Security.

name: Trivy

on:
  pull_request:
  push:
    branches: [main]

permissions: {}

jobs:
  scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Construire l'image
        run: docker build -t "mon-app:$GITHUB_SHA" .

      - name: Neutraliser une configuration Trivy venue de la PR
        run: rm -f trivy.yaml trivy.yml .trivy.yaml

      - name: Scanner, bloquant sur CRITICAL
        env:
          TRIVY: aquasec/trivy:0.74.0@sha256:62b1e65e8869bc4b4c6aa4fa2b21595256c7c2f6018a9d9ad61caf87187c1969
        run: |
          docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v "$PWD:/out" "$TRIVY" \
            image --scanners vuln --format sarif --output /out/trivy.sarif "mon-app:$GITHUB_SHA"
          docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$TRIVY" \
            image --scanners vuln --severity CRITICAL --exit-code 1 "mon-app:$GITHUB_SHA"

      - name: Publier le rapport
        if: always()
        uses: github/codeql-action/upload-sarif@e4fba868fa4b1b91e1fdab776edc8cfbe6e9fb81 # v4.37.3
        with:
          sarif_file: trivy.sarif

Le socket Docker n'est monté ici que dans le conteneur Trivy, le temps du scan, pour lui permettre de lire l'image construite sur le runner ; aucun conteneur applicatif n'y a accès. Sur GitLab, la même logique s'écrit avec l'image épinglée comme image: du job et GIT_STRATEGY: none quand on scanne une image du registre : sans dépôt extrait, aucun trivy.yaml ne peut s'inviter.

container_scanning:
  image:
    name: aquasec/trivy:0.74.0@sha256:62b1e65e8869bc4b4c6aa4fa2b21595256c7c2f6018a9d9ad61caf87187c1969
    entrypoint: [""]
  variables:
    GIT_STRATEGY: none
    TRIVY_USERNAME: "$CI_REGISTRY_USER"
    TRIVY_PASSWORD: "$CI_REGISTRY_PASSWORD"
    TRIVY_AUTH_URL: "$CI_REGISTRY"
    TRIVY_CACHE_DIR: ".trivycache/"
    FULL_IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  script:
    - trivy image --exit-code 0 --format template --template "@/contrib/gitlab.tpl"
        --output "$CI_PROJECT_DIR/gl-container-scanning-report.json" "$FULL_IMAGE_NAME"
    - trivy image --exit-code 1 --severity CRITICAL "$FULL_IMAGE_NAME"
  cache:
    paths:
      - .trivycache/
  artifacts:
    when: always
    reports:
      container_scanning: gl-container-scanning-report.json

La première commande produit le rapport affiché dans la merge request, sans bloquer ; la seconde porte le seuil. Le cache de la base de vulnérabilités (TRIVY_CACHE_DIR) évite de la retélécharger à chaque job.

Surveiller un cluster avec Trivy Operator

Pour un scan continu des workloads d'un cluster Kubernetes, Trivy Operator lance Trivy dans le cluster et range ses résultats dans des ressources Kubernetes. Le projet est maintenu : le chart 0.36.0 (opérateur 0.34.0) date du 24 août 2026, après trois versions en deux mois. Son values.yaml lance Trivy 0.74.0, mais par tag seulement : le chart ne prévoit aucun champ de digest, et le paquet de règles aquasec/trivy-checks y est référencé par le tag flottant 1. Sur un cluster sensible, fixez ces références vous-même dans les values. L'opérateur n'a pas été déployé dans cette leçon.

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system --create-namespace --version 0.36.0

kubectl get vulnerabilityreports -A
kubectl get configauditreports -A
kubectl get exposedsecretreports -A

Ce que Trivy ne voit pas

Trivy compare ce qu'il trouve à des bases et à des règles : il ne voit que ce qui y figure. Une vulnérabilité pas encore publiée (0-day), une faille propre à votre code, un binaire copié à la main sans métadonnées, ou une erreur de logique métier lui échappent. Il complète le SAST et le DAST, il ne les remplace pas.

Deux scanners ne voient pas non plus la même chose. Mesuré dans la leçon sur les CVE : sur la même image node:14, Grype a trouvé 2032 correspondances quand Trivy en rapportait 1455, parce qu'ils ne lisent ni les mêmes bases ni les composants de la même façon. Croiser deux outils réduit les angles morts sans les supprimer.

À retenir

Trivy scanne dépendances, secrets, images et IaC ; sur un dossier, misconfig n'est actif que si on le demande.
Après les incidents de 2026, on l'installe en version épinglée par digest, jamais latest ni la v0.69.4.
Il sort en code 0 par défaut : le blocage se décide avec --severity et --exit-code.
Un trivy.yaml posé dans le dépôt est chargé automatiquement et peut vider le rapport : options en ligne de commande, configuration imposée, fichier supprimé.
Un SBOM CycloneDX se rescanne plus tard avec trivy sbom, sans le code.
--ignore-unfixed réduit le bruit, mais une image en fin de vie se remplace.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

FAQ : questions fréquentes

Les questions ci-dessous reprennent les doutes les plus courants sur Trivy : installation, cibles, intégration en CI et limites, avec les mêmes versions épinglées que la leçon.

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

Trivy est le scanner de sécurité open source d'Aqua Security. En une commande, il cherche les vulnérabilités connues des dépendances et des images, les secrets oubliés dans le code et les mauvaises configurations de l'infrastructure as code.

Cible	Commande	Ce qu'il cherche
Dossier ou dépôt	`trivy fs .`	Dépendances, secrets, IaC
Image	`trivy image <image>`	Paquets de l'OS et des langages
Configuration	`trivy config .`	Dockerfile, Terraform, Kubernetes
SBOM	`trivy sbom sbom.json`	Composants d'un inventaire existant

Mesuré sur Trivy 0.74.0, un petit projet de test lui suffit pour relever 4 vulnérabilités, un jeton GitHub et 10 erreurs de configuration. Détail dans le guide Trivy.

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

Trivy et Grype cherchent tous deux des vulnérabilités connues, mais ne lisent ni les mêmes bases ni les composants de la même façon. Mesuré sur la même image node:14 : Grype a trouvé 2032 correspondances, Trivy 1455.

Critère	Trivy	Grype
Éditeur	Aqua Security	Anchore
Cibles	Images, dossiers, IaC, SBOM, Kubernetes	Images, dossiers, SBOM
Secrets et IaC	Oui	Non
EPSS et KEV dans le rapport	Non	Oui

Croiser les deux réduit les angles morts sans les supprimer. Voir les CVE et le guide Trivy.

Comment installer Trivy sur Linux, macOS ou Windows ?

Après les attaques de 2026, on installe une version précise, au moins la 0.72.0, jamais latest. La forme la plus sûre est l'image officielle épinglée par digest :

TRIVY="aquasec/trivy:0.74.0@sha256:62b1e65e8869bc4b4c6aa4fa2b21595256c7c2f6018a9d9ad61caf87187c1969"
docker run --rm -v "$PWD:/src" -w /src -v trivy-cache:/root/.cache "$TRIVY" fs .

Sur le poste, un gestionnaire de versions fixe la version dans le dépôt :

asdf install trivy 0.74.0
asdf set trivy 0.74.0

À proscrire : la 0.69.4, les images Docker Hub 0.69.5 et 0.69.6 (avis GHSA-69fq-xp46-6x23), et les releases 0.27.0 à 0.69.1, supprimées pendant l'incident de février.

Comment scanner une image Docker avec Trivy ?

trivy image --scanners vuln nginx:1.31.3-alpine@sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752

# Seules les vulnérabilités ayant un correctif
trivy image --scanners vuln --ignore-unfixed <image>

# Bloquer sur CRITICAL
trivy image --scanners vuln --severity CRITICAL --exit-code 1 <image>

Mesuré le 1er octobre 2026 : nginx:1.31.3-alpine porte 54 vulnérabilités, toutes corrigeables ; node:14, en fin de vie, en porte 1411, dont 1086 avec un correctif. Désignez toujours l'image par son digest, pas par latest.

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

trivy fs lit les fichiers de dépendances (requirements.txt, package-lock.json, go.mod, pom.xml...) et les confronte à sa base.

trivy fs .

Mesuré : sans option, trivy fs lance les scanners vuln et secret. Sur un requirements.txt qui épingle requests==2.25.1, il relève 4 vulnérabilités MEDIUM. Le scan des configurations (misconfig) n'est actif que si on le demande avec --scanners vuln,secret,misconfig.

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

Le scanner misconfig compare Dockerfile, Terraform, manifestes Kubernetes, Helm et CloudFormation à des règles intégrées.

trivy config .
# ou, avec le reste :
trivy fs --scanners vuln,secret,misconfig .

Mesuré : un Dockerfile sans USER lève DS-0002 (HIGH), un apt-get install sans --no-install-recommends lève DS-0029, et un bucket S3 au blocage d'accès public désactivé lève AWS-0086, AWS-0087, AWS-0091 et AWS-0093. Une règle qui ne s'applique pas à votre cas se documente comme exception, elle ne se désactive pas.

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

Un SBOM (Software Bill of Materials) est l'inventaire des composants d'un logiciel. Trivy le produit, puis sait le rescanner plus tard sans le code ni l'image.

trivy fs --format cyclonedx --output sbom.json .
trivy sbom sbom.json

Mesuré : le SBOM sort au format CycloneDX 1.7, et trivy sbom y retrouve les mêmes vulnérabilités que le scan direct. Produire le SBOM ne lance aucune recherche de vulnérabilités : ce sont deux étapes distinctes. Voir le guide SBOM.

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

Le plus sûr est de lancer l'image officielle épinglée plutôt qu'une action tierce : c'est aquasecurity/trivy-action qui a été compromise en mars 2026.

permissions: {}
jobs:
  scan:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - run: rm -f trivy.yaml trivy.yml .trivy.yaml
      - run: >
          docker run --rm -v "$PWD:/src" -w /src
          aquasec/trivy:0.74.0@sha256:62b1e65e8869bc4b4c6aa4fa2b21595256c7c2f6018a9d9ad61caf87187c1969
          fs --scanners vuln,secret --severity CRITICAL --exit-code 1 .

Le rm neutralise une configuration Trivy apportée par la pull request. Sur GitLab, utilisez la même image en image: du job. Exemples complets dans le guide Trivy.

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

Le fichier .trivyignore déclare les constats acceptés, idéalement avec une date d'expiration : passé cette date, l'exception tombe et le constat réapparaît.

# Composant non exposé, corrigé dans la release 2.0 (ticket SEC-142)
CVE-2021-23337 exp:2027-01-01

Mesuré dans la leçon sur la SCA : .trivyignore est lu par défaut, alors que la variante .trivyignore.yaml n'est lue qu'avec --ignorefile. Chaque ligne porte sa justification. Voir la SCA.

Comment scanner un cluster Kubernetes avec Trivy Operator ?

Trivy Operator lance Trivy dans le cluster et range ses résultats dans des ressources Kubernetes.

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system --create-namespace --version 0.36.0

kubectl get vulnerabilityreports -A
kubectl get configauditreports -A

Le chart 0.36.0 (opérateur 0.34.0, 24 août 2026) lance Trivy 0.74.0, mais par tag seulement, et référence le paquet de règles par le tag flottant 1 : fixez ces références vous-même sur un cluster sensible.

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

Trois leviers réduisent la durée d'un scan en CI :

cacher la base de vulnérabilités entre les jobs (TRIVY_CACHE_DIR, ou un volume en local) pour ne pas la retélécharger ;
limiter les scanners à ce que le job contrôle, par exemple --scanners vuln pour une image ;
limiter la sortie au seuil utile avec --severity.

trivy image --download-db-only
trivy image --skip-db-update --scanners vuln <image>

Un cache trop ancien fait manquer les vulnérabilités récentes : rafraîchissez la base au moins une fois par jour.

Quels formats de sortie Trivy supporte-t-il ?

Format	Usage	Option
table	Lecture humaine, par défaut	`--format table`
json	Traitement automatisé	`--format json`
sarif	Onglet Security de GitHub	`--format sarif`
cyclonedx	SBOM CycloneDX	`--format cyclonedx`
spdx-json	SBOM SPDX	`--format spdx-json`
template	Rapport GitLab	`--format template --template "@/contrib/gitlab.tpl"`

Les formats SBOM produisent l'inventaire sans rechercher de vulnérabilités : on le rescanne ensuite avec trivy sbom.

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

Oui : le scanner secret est actif par défaut avec trivy fs et trivy image.

trivy fs .

Mesuré : un faux jeton ghp_ dans un fichier Python est détecté comme GitHub Personal Access Token, classé CRITICAL, et sa valeur est masquée dans le rapport. Pour un contrôle des secrets dans tout l'historique Git, un outil dédié comme Gitleaks reste plus complet.

Quelles sont les limites de Trivy ?

Trivy compare ce qu'il trouve à des bases et à des règles : il ne voit que ce qui y figure.

Limite	Conséquence	Complément
Vulnérabilités non publiées (0-day)	Invisibles	Veille, défense en profondeur
Failles propres à votre code	Invisibles	SAST
Comportement à l'exécution	Invisible	DAST
Configuration dans le dépôt	Un `trivy.yaml` peut vider le rapport	Options en ligne de commande

Mesuré : un trivy.yaml de deux lignes posé dans le dossier est chargé automatiquement et fait disparaître les constats du rapport, sans avertissement. Voir le guide Trivy.

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

trivy rootfs scanne les paquets installés sur un système de fichiers, local ou monté ; trivy vm cible une image de machine virtuelle.

# Le système local, avec les droits nécessaires pour lire tous les paquets
sudo trivy rootfs --scanners vuln --severity HIGH,CRITICAL /

# Une image de VM
trivy vm --severity HIGH,CRITICAL ./disk.qcow2

Ces deux commandes n'ont pas été mesurées dans la leçon. Pour l'audit de configuration d'un serveur, au-delà des paquets, un outil comme Lynis est plus adapté.

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

Ce que vous allez apprendre

Qu'est-ce que Trivy ?

Installer une version épinglée

Scanner un projet : dépendances et secrets

Analyser l'infrastructure as code

Scanner une image de conteneur

Faire échouer le pipeline

Le piège du trivy.yaml chargé automatiquement

Documenter les exceptions

Générer et rescanner un SBOM

Contrôler la conformité CIS d'une image

Intégrer Trivy en CI

Surveiller un cluster avec Trivy Operator

Ce que Trivy ne voit pas

À retenir

Contrôle de connaissances

Contrôle de connaissances

Informations

Vérification

Score par domaine

Bilan

Points forts

Points faibles

À faire ensuite

FAQ : questions fréquentes