TechAtelier
CONFIGCHECK

Analyser un Dockerfile avant de construire l’image

Repérez rapidement les instructions risquées, les secrets potentiels et les choix qui rendent une image plus difficile à maintenir.

Un Dockerfile court n’est pas forcément sûr. L’image de base, l’ordre des couches et l’utilisateur final influencent directement la surface d’attaque et la reproductibilité.

Risques recherchés

  • image de base non figée ou tag latest ;
  • exécution finale avec l’utilisateur root ;
  • secret transmis avec ARG ou ENV ;
  • téléchargement distant sans vérification d’intégrité ;
  • usage fragile de ADD, permissions trop larges ou commande shell ambiguë ;
  • cache de gestionnaire de paquets conservé dans l’image ;
  • absence de HEALTHCHECK quand le service le nécessite.

Exemple de correction

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER 10001
CMD ["python", "-m", "app"]

Cette base reste à adapter : figer l’image par digest améliore encore la reproductibilité, et les secrets doivent être fournis au moment de l’exécution ou par les mécanismes dédiés du constructeur.

Contrôler sans construire

ConfigCheck lit les instructions du Dockerfile mais ne télécharge ni ne lance l’image.

Analyser mon Dockerfile

Après l’analyse

Corrigez d’abord les secrets et privilèges, puis améliorez la reproductibilité et la taille. Complétez ensuite avec un scan de vulnérabilités de l’image construite et un test réel dans un environnement isolé.

Si le projet utilise Compose, vérifiez également la configuration des services.

Mis à jour le 19 juillet 2026.