Docs

Analyse de sécurité avec Trivy

À quoi sert cet écran

Analyser une image construite à la recherche de vulnérabilités connues, et lire le résultat assez finement pour décider de la livrer ou non.

Avant de commencer

Pour faire ceci Il vous faut
Lancer et lire des analyses être connecté

Ouvrir l’écran

Tools › Security Scanner, sur /developer-tools/trivy-report.

Image Builder s’intègre avec Trivy pour analyser vos Dockerfiles et rechercher des vulnérabilités de sécurité avant le déploiement.

📸 Capture d’ecran : Un résultat d’analyse avec des constats. Repères : (1) la répartition par sévérité, (2) un constat élevé, (3) son origine dans l’image de base, (4) la vue de détail.

Fonctionnement de l’analyse

Quand vous cliquez sur “Validate Dockerfile”, un workflow GitHub Actions est déclenché qui :

  1. Récupère le code du projet et crée le Dockerfile dans le dépôt
  2. Construit une image Docker à partir du Dockerfile
  3. Pousse l’image vers Docker Hub
  4. Analyse l’image avec Trivy pour les vulnérabilités
  5. Génère un rapport JSON détaillé

Durée : 2 à 5 minutes selon la complexité de l’image.

Comprendre les résultats

Les vulnérabilités sont catégorisées par sévérité :

Sévérité Description
CRITICAL Vulnérabilités graves nécessitant une attention immédiate
HIGH Vulnérabilités significatives à traiter
MEDIUM Vulnérabilités de risque modéré
LOW Vulnérabilités mineures avec impact limité

Critères de validation :

  • Validated : Moins de 2 CRITICAL et moins de 10 HIGH vulnérabilités
  • Not Validated : Dépasse les seuils ci-dessus

Rapports détaillés

Cliquez sur “View Detailed Report” après une analyse pour ouvrir la page Trivy Report complète. Elle inclut :

  • Statistiques de résumé — Total des vulnérabilités, packages affectés, score CVSS moyen
  • Répartition par sévérité — Décompte par niveau de sévérité
  • Tableau des vulnérabilités — Liste consultable avec identifiants CVE, noms/versions des packages, versions corrigées, scores CVSS et liens de référence

Scénario

Une analyse revient avec une longue liste et une échéance proche.

  1. Triez par sévérité et arrêtez-vous après les élevées. Une liste de constats faibles ne justifie pas de retarder une livraison, et la traiter comme telle est la façon dont les équipes apprennent à ignorer les analyses.
  2. Pour chaque constat élevé, déterminez s’il concerne votre code ou l’image de base. Les correctifs sont totalement différents, et la plupart des constats viennent de l’image de base.
  3. Les constats liés à l’image de base disparaissent généralement en passant à un tag plus récent de la même image. Essayez cela d’abord : c’est une ligne.
  4. Les constats sur vos dépendances demandent une montée de version ; ceux sans correctif disponible demandent une décision, consignée, pas un laisser-passer silencieux.
  5. Relancez l’analyse après toute modification. Un correctif non vérifié est une croyance.
  6. Si vous livrez avec des constats connus, écrivez pourquoi. La prochaine personne à lire cette analyse ne devrait pas avoir à refaire votre raisonnement.

En cas de problème

Symptôme Cause Comment vérifier Solution
Toutes les images remontent des constats Les images de base portent des CVE connues ; c’est normal La répartition par sévérité Concentrez-vous sur les élevées ; ne visez pas zéro
Un constat n’a pas de correctif Toutes les CVE n’ont pas de version corrigée Le détail du constat Décidez et consignez ; n’ignorez pas en silence
La nouvelle analyse donne le même résultat L’image n’a pas été reconstruite après la modification Le tag de l’image Reconstruisez, puis relancez

Pour aller plus loin