Analyse de sécurité et correction des images Docker : tutoriel Trivy et intégration CI/CD

Le 10 décembre 2021, la courbe d’alerte sur le tableau de bord a soudainement grimpé. Quelqu’un a posté un numéro CVE dans le chat ops : CVE-2021-44228, la vulnérabilité Log4Shell qui a secoué toute la tech. Une douzaine de microservices utilisaient des images de base vulnérables. Toute l’équipe a passé la nuit à mettre à jour les images et redéployer.

Lors du post-mortem, le patron a posé une question : « Comment se fait-il qu’on ne sache pas quelles vulnérabilités contiennent nos images ? »

Une étude NSFOCUS indique que 76 % des images sur Docker Hub présentent des vulnérabilités connues. Votre python:3.9 ? Votre nginx:latest ? Ils cachent probablement des dizaines de CVE.

Vous vous demandez sûrement : comment savoir quelles vulnérabilités contient une image ? Comment les corriger ? Comment détecter automatiquement en CI/CD pour ne pas déployer d’images vulnérables en production ?

J’ai mis deux ans en production à trouver les réponses. Cet article vous guide pas à pas :

• Scanner rapidement les vulnérabilités avec Trivy et d’autres outils
• Corriger de façon systématique (bien plus que « mettre à jour l’image »)
• Intégrer le scan automatisé dans GitHub Actions, GitLab CI, etc.

Toutes les commandes et configurations sont prêtes à copier-coller. Croyez-moi, vous éviterez beaucoup d’écueils.

"Le rapport NSFOCUS de mars 2018 indique que plus des trois quarts (76 %) des images échantillonnées sur Docker Hub présentaient des vulnérabilités connues."

Panorama des menaces de sécurité des images Docker

Quels problèmes de sécurité peut présenter une image Docker ?

Franchement, au début avec les conteneurs, je pensais qu’une image Docker n’était qu’un « programme empaqueté » qui tourne. Jusqu’à ce qu’un scan en ligne révèle trois jours plus tard qu’il existe plusieurs catégories de vulnérabilités, chacune suffisante à vous causer des ennuis.

Vulnérabilités des paquets OS — la plus courante. Dans vos images Alpine ou Ubuntu, OpenSSL, glibc, curl et autres bibliothèques système révèlent régulièrement de nouvelles failles. La vulnérabilité critique OpenSSL 3.0.x en 2022 en a touché un grand nombre.

Vulnérabilités des dépendances applicatives — plus insidieuses. Votre projet Python dépend de Flask, Flask de Werkzeug, et une version de Werkzeug a une faille d’exécution de code. Vous avez mis à jour Python et vous croyez en sécurité ? Pas forcément : l’arbre de dépendances peut cacher des vulnérabilités ignorées. Log4j en est l’exemple emblématique — combien de projets Java ne savaient même pas utiliser Log4j.

Mauvaises configurations et fuites de secrets — certains développeurs écrivent le mot de passe BDD directement dans le Dockerfile, ou oublient de supprimer .git avant le build. D’autres exécutent le conteneur en root, avec des permissions plus larges que nécessaire.

Risques supply chain — le plus difficile à prévenir. Vous tirez une image normale sur Docker Hub, et un jour on découvre qu’elle contient un miner ou une backdoor. Une étude de 2018 a révélé des « images malveillantes » sur Docker Hub, ciblant ceux qui pullent sans réfléchir.

Pourquoi ne pas faire aveuglément confiance aux images Docker Hub ?

Ce chiffre de 76 % m’a vraiment secoué la première fois.

Vous vous dites peut-être que ces données sont anciennes. Mais ces vieilles images sont encore utilisées. Et beaucoup d’« images officielles » ne sont pas mises à jour en temps réel. Le tag python:3.9 peut dater de six mois, avec des paquets système obsolètes.

Pire encore, la qualité sur Docker Hub est très hétérogène. Certaines images sont maintenues par des particuliers, parfois sans mise à jour depuis six mois. D’autres portent le label « officiel » mais ne sont qu’un upload d’entreprise. Pas de standard d’audit unifié — on joue à la loterie.

Un collègue a tiré une image Node.js sur Docker Hub par commodité. Le scan a révélé plus de 30 vulnérabilités HIGH. L’auteur a répondu : « L’image n’a pas été maintenue depuis deux ans, débrouillez-vous. »

Ma règle aujourd’hui : toute image tirée de Docker Hub doit être scannée avant usage, même avec un tag « officiel ».

Comparaison des outils de scan et choix

Trivy : mon outil open source préféré

Pour le scan de sécurité des images Docker, les choix ne manquent pas, mais j’utilise presque exclusivement Trivy. Pas que les autres soient mauvais — Trivy équilibre vraiment bien simplicité et fonctionnalités.

La première fois, j’ai été surpris par la vitesse. Scanner une image de plusieurs centaines de Mo : environ 10 secondes la première fois, quelques secondes ensuite. Pas de base locale à maintenir, pas de service supplémentaire — installez et scannez.

Que détecte Trivy ? Plus que prévu :

• Détection de vulnérabilités : paquets OS (Alpine, Ubuntu, Debian, CentOS, etc.) et dépendances applicatives (npm, pip, Maven, Go Modules, etc.)
• Scan de mauvaises configurations : Dockerfile, manifests Kubernetes
• Détection de secrets : clés, mots de passe embarqués par erreur
• Conformité licences : licences open source des dépendances

Trivy est déjà intégré à GitHub Actions et Harbor. Pas besoin de bricoler — le chemin est tracé.

Les autres outils en bref

Snyk — produit commercial complet. Intégration IDE en temps réel, PR de correction automatiques. Version gratuite limitée ; usage approfondi payant. Adapté aux grandes entreprises.

Clair — moteur de scan de Quay, open source et personnalisable. Configuration complexe. Récupère les CVE des équipes sécurité des distributions Linux. Bon choix si vous avez des ingénieurs sécurité dédiés ; courbe d’apprentissage plus élevée pour les équipes dev classiques.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Anchore — solution entreprise avec gestion de politiques. Règles du type « bloquer le déploiement si CRITICAL ». Secteurs réglementés (finance, santé). Configuration et maintenance lourdes.

Docker Scout / Hardened Images (DHI) — lancé par Docker en mai 2025, CVE quasi nulles, volume réduit de 95 %. Runtime distroless prometteur ; écosystème encore jeune, à suivre.

Mes recommandations

PME ou développeur solo : Trivy directement — gratuit, simple, suffisant. Une commande pour installer, une pour scanner, opérationnel en 10 minutes.

Grande entreprise, exigences de conformité et budget : Snyk. Base de vulnérabilités à jour, support professionnel, intégrations profondes.

Équipe avec ingénieurs sécurité, solution open source personnalisable : Clair, en prévoyant du temps de configuration.

Sécurité maximale et images minimales : suivre Docker Hardened Images, peut-être le standard de demain.

Ma pratique : Trivy au quotidien et en CI/CD pour un retour rapide ; rescan avec Clair intégré à Harbor avant la production, double filet de sécurité.

Tutoriel pratique Trivy

Installation et usage de base

L’installation de Trivy est si simple qu’on en doute. Sur macOS :

brew install trivy

Sous Linux, binaire ou gestionnaire de paquets — voir https://github.com/aquasecurity/trivy/releases

Une fois installé, testez sur une image :

# Scanner une image Docker Hub
trivy image python:3.9

# Scanner une image locale
trivy image myapp:latest

# Scanner un fichier tar
trivy image --input ruby-3.1.tar

Au premier lancement, Trivy télécharge la base de vulnérabilités (trivy-db), quelques dizaines de Mo. Ensuite, le scan devient très rapide.

Les résultats sont classés par gravité :

• CRITICAL : correction immédiate, contrôle total possible
• HIGH : correction rapide, exploitable
• MEDIUM : correction recommandée
• LOW : priorité basse, planifiable

Chaque vulnérabilité affiche le numéro CVE, le paquet affecté, la version actuelle et la version corrigée (si disponible).

Options avancées : tirer le meilleur de Trivy

En pratique, vous ne voulez pas voir toutes les vulnérabilités, surtout les LOW non corrigeables. Options utiles :

Afficher uniquement HIGH et CRITICAL :

trivy image --severity HIGH,CRITICAL nginx:latest

J’utilise ça en CI/CD. Exiger la correction de tout est irréaliste — commencer par le critique.

Ignorer les vulnérabilités sans correctif :

trivy image --ignore-unfixed redis:latest

Pas de patch officiel ? Inutile de s’énerver. Ce paramètre n’affiche que les vulnérabilités corrigeables.

Code de sortie non nul si vulnérabilités critiques :

trivy image --exit-code 1 --severity CRITICAL myapp:latest

Indispensable en CI/CD : si des vulnérabilités CRITICAL sont détectées, le build échoue. Barrière de sécurité — les images vulnérables n’atteignent pas la production.

Sortie JSON pour intégration :

trivy image -f json -o results.json myapp:latest

Pour importer dans une plateforme de sécurité ou automatiser le traitement.

Scan en environnement offline :

trivy image --skip-db-update myapp:latest

En intranet sans accès externe : téléchargez la base sur une machine connectée, copiez-la, puis --skip-db-update évite les tentatives de mise à jour.

Lire les résultats : sur quoi se concentrer

La première fois que j’ai scanné une image de production, plus de 100 vulnérabilités ont rempli l’écran. J’ai cru que ce serait interminable.

Avec l’expérience, voici les bonnes pratiques :

Prioriser les vulnérabilités avec version corrigée. Si « Fixed Version » affiche « none » ou est vide, pas de patch disponible — concentrez-vous sur le corrigeable.

Se concentrer sur CRITICAL et HIGH. Les LOW et MEDIUM peuvent attendre si le service n’est pas exposé publiquement. CRITICAL exige une action immédiate — exploits publics souvent disponibles.

Consulter les CVE. Sur https://cve.mitre.org/, vérifiez la nature, la portée et la difficulté d’exploitation. Certaines vulnérabilités alarmantes exigent des conditions très restrictives.

Comprendre le fonctionnement de Trivy. Il télécharge une base JSON de vulnérabilités connues, analyse les paquets de l’image (via les bases des gestionnaires de paquets) et signale les correspondances paquet/version.

Des faux positifs arrivent : un paquet vulnérable est présent, mais votre code n’appelle pas la fonction concernée. Évaluez le risque réel selon votre code.

Méthodes systématiques de correction des vulnérabilités

Commencer par la bonne image de base

Corriger, c’est souvent « remplacer » plutôt que « patcher ». Des dizaines de vulnérabilités de paquets système ? Changer d’image de base est plus efficace que de tout mettre à jour un par un.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Mon équipe utilisait Alpine (5,87 Mo, très compact). Mais Alpine a ses limites : musl au lieu de glibc, parfois des problèmes de compatibilité. Petit, mais pas exempt de vulnérabilités.

Je préfère maintenant Distroless : 3,06 Mo, plus petit qu’Alpine, avec une réduction extrême — pas de shell, pas de gestionnaire de paquets, aucun outil superflu.

Pourquoi plus sûr ? Même si un attaquant exploite une faille applicative, il ne peut pas exécuter de commandes shell — il n’y en a pas. Surface d’attaque minimale.

Images Distroless de Google :

# Application Python
FROM gcr.io/distroless/python3

# Application Node.js
FROM gcr.io/distroless/nodejs

# Application Go (static pour binaire statique)
FROM gcr.io/distroless/static

Inconvénient : débogage difficile — pas de ls, cat, etc. En dev, image classique pour déboguer ; en prod, Distroless pour la sécurité.

Hardened Images (DHI) de Docker en 2025 va plus loin : CVE quasi nulles, volume réduit de 95 %. Écosystème encore jeune, mais à surveiller.

Corriger les vulnérabilités en mettant à jour les dépendances

Changer l’image de base ne suffit pas — les dépendances applicatives aussi.

Méthode 1 : mettre à jour la version de l’image de base

# Éviter latest, trop vague
FROM python:3.9

# Version précise, mise à jour régulière
FROM python:3.11.7

latest peut rester des mois sans mise à jour. Version précise + vérification mensuelle des minor releases.

Méthode 2 : mettre à jour les paquets système dans le Dockerfile

FROM ubuntu:22.04

# Mettre à jour tous les paquets à la build
RUN apt-get update && \
    apt-get upgrade -y && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

Regrouper update, upgrade et clean dans un seul RUN réduit les layers. Supprimer le cache apt économise des dizaines de Mo.

Méthode 3 : mettre à jour les dépendances applicatives

Cas fréquent : Trivy signale Flask vulnérable, vous modifiez requirements.txt :

# Avant
Flask==2.0.1

# Après (2.3.0 corrige la faille)
Flask==2.3.0

Attention : upgrade majeur = risque de régression. Testez d’abord. Plus prudent : ne monter que la version patch — Flask 2.0.1 vulnérable ? Essayez la dernière 2.0.x avant 2.3.0.

Bonnes pratiques à ne pas négliger

Au-delà des corrections ponctuelles, des habitudes maintiennent la sécurité :

Build multi-stage :

# Phase build
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Phase runtime (binaire uniquement)
FROM gcr.io/distroless/static
COPY --from=builder /app/myapp /
CMD ["/myapp"]

L’image finale ne contient ni compilateur, ni sources, ni fichiers intermédiaires — surface d’attaque réduite.

Ne pas exécuter en root :

RUN useradd -m myuser
USER myuser

Beaucoup d’images tournent en root par défaut — dangereux. Un attaquant obtient root directement. Créez un utilisateur dédié.

Rebuild régulier :

Facile à oublier. Votre code est stable, mais les paquets système reçoivent des patches. Rebuild au moins mensuellement.

Notre équipe rebuild automatiquement tous les dimanches, scanne, et traite les problèmes le lundi.

Utiliser .dockerignore :

.git
.env
*.log
secrets/

Un .env embarqué = fuite de mot de passe BDD. .dockerignore, comme .gitignore, exclut les fichiers sensibles.

Ne jamais utiliser latest :

FROM python:latest est une bombe à retardement — version inconnue, vulnérabilités inconnues. FROM python:3.11.7-slim : prévisible et traçable.

Construire un flux CI/CD de scan automatisé

Intégration GitHub Actions : cinq minutes

Le scan manuel est fastidieux et oubliable. Intégrez-le au CI/CD — chaque commit ou build déclenche un contrôle.

L’intégration Trivy dans GitHub Actions est remarquablement simple. Créez .github/workflows/docker-scan.yml :

name: Docker Security Scan

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

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

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

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'table'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # Échec du build si vulnérabilités critiques

      - name: Upload scan results
        if: always()
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: 'trivy-results.sarif'

Ce workflow :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Se déclenche à chaque push sur main/develop ou PR
• Build l’image (tag SHA pour unicité)
• Scan Trivy CRITICAL et HIGH uniquement
• exit-code: '1' bloque le merge si vulnérabilités critiques
• Upload vers l’onglet Security de GitHub

Après configuration, poussez une fois — résultats dans Actions. Vulnérabilités = build rouge, merge bloqué. Porte de sécurité automatique.

Intégration GitLab CI/CD : tout aussi simple

Sur GitLab, créez ou modifiez .gitlab-ci.yml :

stages:
  - build
  - test
  - security

build_image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

security_scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false
  dependencies:
    - build_image

allow_failure: false : échec du scan = échec du pipeline. Pour moins de rigueur, allow_failure: true — avertissement sans blocage.

En production, gardez false. Dev peut être plus souple ; prod, pas de compromis.

Double filet avec Harbor

Avec Harbor comme registry privé (courant en entreprise), c’est encore plus simple. Harbor intègre Trivy et Clair depuis v1.2, scan automatique au push.

Dans les paramètres du projet Harbor :

• Scan automatique au push
• Scan planifié quotidien (nouvelles CVE)
• Seuils : interdiction de pull si CRITICAL

Notre stratégie :

1. Push dev vers Harbor → scan Trivy automatique
2. HIGH+ → tag « vulnérable »
3. Cluster K8s prod : admission webhook refuse le déploiement d’images taguées

Même en contournant le CI/CD, Harbor bloque en dernière ligne.

Flux complet recommandé

En synthèse :

Développement :

• Plugin IDE Snyk ou Trivy
• Scan manuel trivy image après build local

Build :

• Scan automatique GitHub Actions / GitLab CI
• Échec immédiat sur CRITICAL
• Résultats vers Security Dashboard

Registry :

• Rescan Harbor (failles CI/CD ou nouvelles CVE)
• Politique bloquant le pull d’images à haut risque

Runtime :

• Scan hebdomadaire des images en production
• Alerte et planification de correction

Revue périodique :

• Revue mensuelle des corrections
• Mise à jour des stratégies et seuils

Ça paraît complexe, mais une fois configuré, c’est automatique. Un sprint (deux semaines) chez nous, pour une sécurité durable.

Depuis cette mise en place, je dors mieux. Plus de peur d’un gros CVE découvert trop tard dans nos images.

Conclusion

Revenons à Log4Shell. Avec ce flux de scan, la vulnérabilité aurait été détectée en CI/CD, jamais en production. Pas de nuit blanche, pas de question du patron.

La sécurité des images Docker n’est pas de la haute technologie. Trois piliers :

• Scanner avec Trivy (simple, rapide, suffisant)
• Corriger systématiquement (image de base sûre, dépendances, bonnes pratiques)
• Automatiser en CI/CD (GitHub Actions / GitLab CI en cinq minutes)

76 % d’images vulnérables sur Docker Hub — effrayant au début. Mais la majorité des équipes n’ont pas encore agi. Commencez maintenant, vous serez devant 76 % des autres.

Ne visez pas la correction totale d’un coup — irréaliste. Commencez simple :

1. Aujourd’hui : installez Trivy, scannez l’image de votre projet
2. Cette semaine : corrigez les CRITICAL — souvent une mise à jour d’image de base
3. Prochain sprint : intégrez Trivy en CI/CD, bloquez le déploiement si CRITICAL
4. Ce mois-ci : définissez une baseline de sécurité, revue régulière

La sécurité des conteneurs est un processus continu. Avec un flux en place, la maintenance est légère. Chez nous, scan hebdomadaire automatique, revue en réunion — une demi-heure suffit.

Rappel final : scannez les images de production ! Scannez les images tirées de Docker Hub ! N’attendez pas l’incident — ce sera trop tard.

Partagez vos expériences et anecdotes Docker en commentaire. Progressons ensemble vers des applications conteneurisées plus sûres.