Trivy pour scanner une image Docker WordPress avant de la mettre en ligne

trivy image mon-registre/wordpress-agence:latest a suffi, la première fois qu’elle a été exécutée sur une image construite six mois plus tôt sans reconstruction régulière, à faire remonter quarante-sept vulnérabilités connues, dont plusieurs classées critiques, logées dans les paquets système hérités de l’image de base.

Une image Docker WordPress ne se limite pas au code applicatif qu’elle contient : elle embarque aussi un système d’exploitation minimal, des bibliothèques système, l’interpréteur PHP et ses extensions. Chacun de ces composants peut faire l’objet de vulnérabilités documentées après la construction de l’image, sans qu’aucune modification du code applicatif ne soit nécessaire pour que le risque existe. Sans reconstruction régulière ni scan explicite, ces vulnérabilités s’accumulent silencieusement.

Ce que Trivy scanne réellement

Trivy est un outil open source qui analyse une image Docker construite et compare la version de chaque paquet système et bibliothèque qu’elle contient à des bases de données publiques de vulnérabilités connues, telles que celles maintenues par les distributions Linux elles-mêmes. Contrairement à un audit de dépendances applicatives comme composer audit ou npm audit, qui portent sur le code de l’application, Trivy porte sur l’ensemble de l’image, y compris les couches héritées de l’image de base choisie dans le Dockerfile.

Installer et lancer un premier scan

Trivy s’installe comme binaire autonome ou via un conteneur, ce qui évite toute installation permanente sur la machine qui l’exécute :

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image mon-registre/wordpress-agence:latest

Le résultat liste chaque vulnérabilité détectée avec son identifiant, sa gravité, le paquet concerné, la version installée et la version corrigée disponible. Une première lecture de ce rapport, sur une image jamais scannée auparavant, révèle presque toujours un nombre de résultats plus élevé qu’attendu — non pas parce que l’image est particulièrement mal construite, mais parce qu’aucune image de base n’est jamais exempte de vulnérabilités connues à un instant donné.

Intégrer le scan dans un pipeline de construction

L’intérêt de Trivy se révèle pleinement une fois intégré à la chaîne de construction de l’image, avant sa publication sur un registre utilisé en production :

- name: Scanner l'image avec Trivy
  run: |
    docker build -t mon-registre/wordpress-agence:${{ github.sha }} .
    docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
      aquasec/trivy image --exit-code 1 --severity CRITICAL \
      mon-registre/wordpress-agence:${{ github.sha }}

Le paramètre --exit-code 1 associé à --severity CRITICAL fait échouer l’étape de construction si une vulnérabilité critique est détectée, empêchant la publication d’une image concernée sans intervention explicite.

Régler le seuil de gravité progressivement

Bloquer immédiatement sur toute vulnérabilité, y compris les moins graves, produit rapidement une pipeline qui échoue en permanence sur des résultats que l’équipe n’a pas la capacité de traiter au même rythme qu’ils apparaissent. La mise en place progressive retenue a suivi cet ordre :

• Premier mois : scan informatif uniquement, aucun blocage, pour établir une base de référence
• Deuxième mois : blocage sur les vulnérabilités critiques uniquement
• À partir du troisième mois : extension du blocage aux vulnérabilités de gravité élevée, une fois le stock initial résorbé

Ce qui reste à faire une fois une vulnérabilité détectée

Trivy signale une vulnérabilité, il ne la corrige pas. La correction passe le plus souvent par la mise à jour de l’image de base référencée dans le Dockerfile vers une version plus récente, suivie d’une reconstruction complète de l’image. Certaines vulnérabilités concernent des paquets système qui ne peuvent pas être mis à jour indépendamment de l’image de base elle-même, ce qui justifie une politique de reconstruction régulière de toutes les images du parc, même en l’absence de changement applicatif.

Ce que ce scan ne couvre pas

Trivy scanne les paquets système et les dépendances connues de l’image ; il ne détecte ni une mauvaise configuration applicative de WordPress, ni une vulnérabilité propre au code métier développé sur mesure. La sécurisation applicative de WordPress reste un sujet distinct, qui relève de pratiques de développement sécurisé plutôt que d’un scan d’image.

En résumé

Intégrer Trivy à une chaîne de construction d’image Docker WordPress transforme une source de risque invisible — l’accumulation silencieuse de vulnérabilités système connues — en un contrôle explicite et automatisé. Le coût d’installation initial se limite à une commande, et la principale difficulté réside dans le réglage progressif du seuil de blocage pour que la pipeline reste utilisable sans devenir un obstacle permanent.