Module 2 — Trivy : scanner les vulnérabilités d'une image Docker

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes

---

Ce que Trivy scanne

Trivy (Aqua Security) analyse une image Docker et liste ses vulnérabilités connues (CVE) — dans les paquets système de l’image de base, mais aussi dans les dépendances applicatives (paquets Python, Node.js, Java…) qu’elle contient. C’est le contrôle qui répond à la question : « cette image que je m’apprête à déployer contient-elle des failles connues et déjà corrigées ailleurs ? »

Scanner les deux images du cours Docker avancé

Le module Docker avancé a construit deux versions de la même application : une image naïve (python:3.12 complet, 1,63 Go) et une image multi-étapes non-root (python:3.12-slim, 202 Mo). Les deux ont été scannées réellement avec Trivy :

$ trivy image --severity HIGH,CRITICAL docker-avance-app:latest

Total: 56 vulnérabilités  |  HIGH: 53  |  CRITICAL: 3

$ trivy image --severity HIGH,CRITICAL docker-avance-app-naive:latest

Total: 656 vulnérabilités  |  HIGH: 600  |  CRITICAL: 56

Un facteur supérieur à 11 entre les deux images, pour exactement le même code applicatif. Ce n’est pas une coïncidence : l’image naïve embarque python:3.12 complet (compilateurs, outils de build, bibliothèques de développement) — chacun de ces composants est une source potentielle de CVE. L’image multi-étapes, en ne conservant que le strict résultat de l’installation des dépendances (COPY --from=builder /install /usr/local), réduit mécaniquement la surface d’attaque. La taille de l’image (vue au module précédent) et son nombre de vulnérabilités ne sont pas deux métriques indépendantes — la seconde découle largement de la première.

Un extrait réel du rapport

┌───────────────┬────────────────┬──────────┬──────────────┬───────────────────┬───────────────────┬────────────────────────────────┐
│    Library    │ Vulnerability  │ Severity │    Status    │ Installed Version │   Fixed Version    │             Title              │
├───────────────┼────────────────┼──────────┼──────────────┼───────────────────┼───────────────────┼────────────────────────────────┤
│ perl-base     │ CVE-2026-13221 │ CRITICAL │ fixed        │ 5.40.1-6           │ 5.40.1-6+deb13u1  │ Perl: Incorrect regular        │
│               │                │          │              │                    │                    │ expression processing via      │
│               │                │          │              │                    │                    │ large regular expressions      │
├───────────────┼────────────────┼──────────┼──────────────┼───────────────────┼───────────────────┼────────────────────────────────┤
│ util-linux    │ CVE-2026-78410 │ HIGH     │ affected     │ 2.41.5-0+deb13u1   │                    │ util-linux: restricted bind    │
│               │                │          │              │                    │                    │ mounts do not pin the source   │
└───────────────┴────────────────┴──────────┴──────────────┴───────────────────┴───────────────────┴────────────────────────────────┘

Deux colonnes méritent l’attention avant toute autre : Status et Fixed Version.

• fixed (la ligne perl-base) : un correctif existe déjà (5.40.1-6+deb13u1) — c’est une vulnérabilité actionnable immédiatement : reconstruire l’image avec un apt-get upgrade ou une image de base plus récente suffit à la corriger.
• affected, sans Fixed Version (la ligne util-linux) : aucun correctif n’existe encore en amont — la vulnérabilité est réelle mais rien d’immédiat à appliquer ; à surveiller (un futur scan la marquera fixed dès qu’un correctif sortira), pas à ignorer.

La priorité d’un vrai triage de sécurité découle directement de cette distinction : trier d’abord par Severity (CRITICAL avant HIGH) et par Status (fixed avant affected) — corriger en premier ce qui est à la fois grave et déjà réparable ailleurs, avant de se pencher sur ce qui nécessite une veille.

Intégrer Trivy dans un pipeline CI/CD

Ce scan a été lancé manuellement dans ce cours, mais sa vraie place est dans le pipeline lui-même — exactement le type d’étape déjà vu dans le cours CI/CD :

.github/workflows/security-scan.yml (extrait)

- name: Scanner l'image avec Trivy
  uses: aquasecurity/[email protected]
  with:
    image-ref: 'mon-app:latest'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'   # fait échouer le pipeline si des vulnérabilités sont trouvées

exit-code: '1' est le réglage qui transforme un simple rapport en véritable porte de qualité (quality gate) : le déploiement est bloqué tant que les vulnérabilités bloquantes n’ont pas été corrigées — cohérent avec le principe déjà vu dans le cours CI/CD qu’un pipeline doit empêcher un problème connu d’atteindre la production, pas seulement le documenter après coup.

Prochaine étape

Réseaux & Load Balancing : Nginx et répartition de charge