Tutoriel : sécuriser ses conteneurs Docker avec Trivy pour les PME

Introduction : pourquoi les images Docker sont une porte d’entrée pour les attaquants

Les PME adoptent Docker massivement — souvent via des outils comme Coolify pour auto-héberger leurs applications. C’est une excellente décision sur le plan opérationnel. Mais il y a un angle mort fréquent : les images publiques tirées depuis Docker Hub embarquent des centaines de paquets système, et certains contiennent des vulnérabilités connues.

C’est ce qu’on appelle une attaque supply-chain appliquée aux conteneurs. Vous ne téléchargez pas du code malveillant intentionnellement — vous tirez node:18 ou nginx:latest, et cette image contient une bibliothèque OpenSSL avec une faille critique que vous n’avez pas vue. Un attaquant qui exploite cette faille peut potentiellement compromettre tout votre serveur.

Trivy est la réponse pratique à ce problème. C’est un scanner open-source gratuit, maintenu par Aqua Security, qui analyse vos images Docker, vos fichiers de configuration et vos dépendances applicatives en quelques secondes. Pas besoin d’être expert en cybersécurité pour l’utiliser.

Ce tutoriel s’adresse aux développeurs, aux DevOps et aux dirigeants de PME qui gèrent leur infrastructure sans équipe sécurité dédiée.

Prérequis : ce dont vous avez besoin avant de commencer

• Docker installé et fonctionnel sur votre machine ou serveur (Linux, macOS, ou Windows avec WSL2)
• Un terminal avec les droits suffisants pour exécuter des commandes Docker
• Aucune connaissance préalable en cybersécurité — Trivy s’installe en une commande

Étape 1 : installer Trivy sur votre machine

La façon la plus simple de démarrer est d’utiliser le script d’installation officiel d’Aqua Security.

Sur Linux ou macOS :

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.59.1

Cette commande télécharge et installe Trivy directement dans /usr/local/bin. On précise la version pour éviter les surprises lors d’une réinstallation future.

Alternative sans installation locale — via Docker :

Si on préfère ne rien installer sur la machine hôte, Trivy tourne parfaitement en tant que conteneur :

docker run --rm aquasec/trivy:0.59.1 image nginx:latest

On utilise cette approche quand on veut tester rapidement sur un serveur de production sans modifier l’environnement.

Vérifier l’installation :

trivy --version
# Trivy version: 0.59.1

Au premier lancement d’un scan, Trivy télécharge automatiquement sa base de données de vulnérabilités CVE depuis le dépôt officiel. Ce téléchargement prend 30 à 60 secondes selon la connexion. Les lancements suivants réutilisent le cache local.

Étape 2 : scanner votre première image Docker

On commence avec une image courante pour comprendre le format de sortie. Lançons un scan sur nginx:latest :

trivy image nginx:latest

Le rapport s’affiche dans le terminal. Voici ce que signifient les colonnes :

Trivy distingue deux catégories de vulnérabilités dans ses rapports :

• OS packages : failles dans les paquets système (libc, openssl, curl…) fournis par la distribution de base de l’image
• Application dependencies : failles dans les dépendances de votre code (npm, pip, composer…)

Les vulnérabilités OS sont souvent les plus nombreuses mais pas toujours les plus exploitables. Celles dans vos dépendances applicatives méritent une attention prioritaire car elles touchent directement votre code.

Exemple concret avec node:18 :

trivy image node:18 --severity CRITICAL,HIGH

On filtre immédiatement avec --severity pour ne voir que l’essentiel. Sur une image node:18 non mise à jour, on trouve typiquement des CVE CRITICAL sur des paquets comme libssl ou zlib. Le rapport indique la Fixed Version — c’est la version cible pour corriger.

Étape 3 : scanner vos images locales et celles déployées avec Coolify

Trivy fonctionne aussi bien sur les images tirées depuis un registry que sur celles buildées localement. Avant de pousser une image en production :

trivy image mon-app:latest --severity CRITICAL,HIGH

Scanner toutes les images présentes sur votre serveur Coolify :

On commence par lister les images en cours d’utilisation :

docker images --format "{{.Repository}}:{{.Tag}}" | grep -v "<none>"

Ensuite, on automatise le scan avec un script Bash simple :

#!/bin/bash
# Scanner toutes les images Docker et exporter les résultats en JSON

OUTPUT_DIR="./trivy-reports/$(date +%Y-%m-%d)"
mkdir -p "$OUTPUT_DIR"

docker images --format "{{.Repository}}:{{.Tag}}" | grep -v "<none>" | while read image; do
  safe_name=$(echo "$image" | tr '/:' '--')
  echo "Scanning $image..."
  trivy image \
    --severity CRITICAL,HIGH \
    --format json \
    --output "$OUTPUT_DIR/${safe_name}.json" \
    "$image"
done

echo "Rapports exportés dans $OUTPUT_DIR"

chmod +x scan-all-images.sh
./scan-all-images.sh

Les rapports JSON sont exportés dans un dossier horodaté. Pour prioriser les corrections, on se concentre sur les entrées JSON où FixedVersion n’est pas vide — ce sont les vulnérabilités corrigeables immédiatement.

Étape 4 : corriger les vulnérabilités identifiées

Trivy a trouvé des CVE CRITICAL. Voici les trois stratégies à appliquer dans l’ordre.

Stratégie 1 — Mettre à jour le tag de l’image de base

C’est la correction la plus rapide. Dans votre Dockerfile, remplacez l’image de base par une version plus récente :

# Avant
FROM node:18

# Après — image Alpine, plus légère et moins de surface d'attaque
FROM node:20-alpine

node:20-alpine embarque Alpine Linux 3.x, qui contient beaucoup moins de paquets système que Debian ou Ubuntu. Mécaniquement, moins de paquets = moins de vulnérabilités potentielles.

Stratégie 2 — Adopter des images Distroless

Pour les applications en production, les images Distroless de Google sont encore plus minimalistes qu’Alpine — elles ne contiennent que le runtime nécessaire, sans shell ni gestionnaire de paquets :

FROM gcr.io/distroless/nodejs20-debian12
COPY --from=build /app /app
CMD ["/app/server.js"]

Stratégie 3 — Mettre à jour les dépendances applicatives

Quand Trivy identifie des vulnérabilités dans vos node_modules, requirements.txt ou composer.json, la correction se fait au niveau de votre code :

# Node.js
npm audit fix

# Python
pip install --upgrade paquet-vulnerable

# PHP
composer update paquet/vulnerable

Rebuildez et rescannez :

docker build -t mon-app:latest .
trivy image mon-app:latest --severity CRITICAL,HIGH

Si les CVE CRITICAL ont disparu, la correction est validée.

Quand aucun fix n’est disponible (Fixed Version vide dans le rapport), on ne peut pas corriger immédiatement. La bonne pratique est de documenter la vulnérabilité dans un fichier SECURITY.md, d’évaluer si elle est exploitable dans votre contexte spécifique, et de surveiller les mises à jour de l’image de base.

Étape 5 : automatiser le scan avec une GitHub Action ou un cron Docker

Faire tourner Trivy manuellement, c’est un bon début. L’intégrer dans une pipeline CI/CD, c’est ce qui protège vraiment votre infrastructure dans la durée.

GitHub Actions — fichier complet :

name: Trivy Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # Chaque lundi à 6h UTC

jobs:
  trivy-scan:
    name: Scanner les vulnérabilités
    runs-on: ubuntu-latest

    steps:
      - name: Checkout du code
        uses: actions/checkout@v4

      - name: Builder l'image Docker
        run: docker build -t mon-app:${{ github.sha }} .

      - name: Scanner avec Trivy
        uses: aquasecurity/trivy-action@0.29.0
        with:
          image-ref: mon-app:${{ github.sha }}
          format: table
          exit-code: '1'          # Fait échouer le build si CRITICAL détecté
          severity: 'CRITICAL,HIGH'
          ignore-unfixed: true    # Ignore les CVE sans fix disponible

Le paramètre clé est exit-code: '1' : si Trivy détecte une vulnérabilité CRITICAL ou HIGH avec un fix disponible, le build échoue automatiquement. Le code ne part pas en production.

Alternative sans CI/CD — cron job sur le serveur :

Sur un serveur Coolify sans pipeline GitHub, on crée un cron job hebdomadaire :

# Ajouter dans crontab -e
0 7 * * 1 /home/coolify/scan-all-images.sh 2>&1 | mail -s "Rapport Trivy $(date +%Y-%m-%d)" admin@votre-domaine.com

Pour envoyer le rapport vers Slack plutôt que par email, on remplace la commande mail par un appel curl vers un webhook Slack entrant.

Stocker les rapports pour suivre l’évolution :

Le script de l’étape 3 exporte déjà les JSON dans des dossiers horodatés (./trivy-reports/2026-02-25/). On peut comparer les rapports semaine après semaine pour mesurer la réduction du nombre de CVE — un indicateur concret de l’amélioration de la posture sécurité.

Conclusion : une sécurité Docker accessible à toutes les PME

On a couvert les 5 étapes essentielles : installer Trivy, scanner une image, analyser le rapport, corriger les vulnérabilités, et automatiser le tout.

Le résultat concret : une infrastructure Docker plus résistante aux attaques supply-chain, sans budget sécurité dédié ni expertise avancée. Passer node:18 à node:20-alpine et brancher une GitHub Action, c’est une heure de travail qui réduit significativement votre surface d’exposition.

Trivy va bien au-delà du scan d’images. Dans un prochain article, on verra comment l’utiliser pour analyser les fichiers Dockerfile et les configurations Kubernetes, et comment le coupler avec Falco pour de la détection de menaces en temps réel sur vos conteneurs en cours d’exécution.

Besoin d’aide pour sécuriser votre infrastructure Docker ou mettre en place un pipeline CI/CD robuste ? Chez Kodixar, j’accompagne les PME dans la mise en place de pratiques DevSecOps adaptées à leur taille et leur budget.