Sécuriser les images Docker avec Dockle

Mise à jour : 30/12/2025

La sécurité des conteneurs Docker est devenue un enjeu majeur pour les administrateurs systèmes et les équipes DevOps. Les images non sécurisées peuvent introduire des vulnérabilités critiques dans vos environnements de production. C’est là qu’intervient Dockle, un outil open-source qui m’aide à auditer facilement mes images Docker. Il vérifie leur conformité avec les bonnes pratiques de sécurité, comme celles définies dans les benchmarks CIS Docker. À mon avis, c’est un allié indispensable pour toute démarche DevSecOps.

Qu’est-ce que Dockle ?

Dockle est un outil en ligne de commande spécialement conçu pour analyser la sécurité des images Docker. À la différence des scanners de vulnérabilités classiques comme Trivy, Dockle ne s’intéresse pas uniquement aux paquets logiciels vulnérables. Il se concentre surtout sur des points de configuration souvent négligés, mais critiques. Par exemple : est-ce que l’image utilise un compte utilisateur non privilégié ? Est-ce qu’elle a une instruction HEALTHCHECK ? Y a-t-il des fichiers sensibles laissés dans l’image finale ?

Voici quelques exemples de contrôles que Dockle peut effectuer :

Présence d’un utilisateur root par défaut
Absence d’un fichier .dockerignore
Utilisation de la commande latest dans les FROM
Manque d’un HEALTHCHECK
Permissions trop larges sur certains fichiers

Dockle se base principalement sur les recommandations du CIS Docker Benchmark ↗, ce qui me permet de rester aligné avec des standards reconnus. Son gros avantage ? Il est simple à utiliser, rapide et idéal pour une intégration dans un pipeline CI/CD.

Installation de Dockle

Installer Dockle est simple, quelle que soit votre plateforme. Je vais vous montrer comment je procède selon le système d’exploitation utilisé. L’outil est disponible sous forme de binaire, ce qui facilite son intégration dans un environnement automatisé.

Sur macOS

Sur mon Mac, j’utilise Homebrew, c’est le plus rapide :

brew install goodwithtech/r/dockle

Homebrew va automatiquement récupérer et installer la dernière version stable de Dockle.

Sur Linux

Pour les distributions Debian ou Ubuntu :

VERSION=$(
  curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | \
  grep '"tag_name":' | \
  sed -E 's/.*"v([^"]+)".*/\1/'
)
curl -L -o dockle.deb https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.deb
sudo dpkg -i dockle.deb && rm dockle.deb

Et pour CentOS, RHEL ou autres distributions RPM-based :

VERSION=$(
  curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | \
  grep '"tag_name":' | \
  sed -E 's/.*"v([^"]+)".*/\1/'
)
sudo rpm -ivh https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.rpm

Pour toutes les distributions, vous pouvez suivre les dernières versions ici : github.com/goodwithtech/dockle/releases ↗

Controle de la version

Une fois installé, je vérifie la version de Dockle pour m’assurer que tout est fonctionnel :

dockle --version
dockle version 0.4.15

Utilisation de base de Dockle

Une fois Dockle installé, je peux immédiatement commencer à analyser mes images Docker. L’utilisation est très simple : une seule commande suffit pour lancer un audit.

Lancer une analyse

Pour analyser une image, j’utilise cette commande :

dockle NOM_DE_L_IMAGE@sha256:DIGEST

Exemple réel : analyse de l’image devops-status-api :

dockle devops-status-api:test

Dockle va alors inspecter l’image et produire un rapport directement dans le terminal. Ce rapport est structuré par types de bonnes pratiques et classé par niveau de gravité :

FATAL : erreurs critiques qui nécessitent une action immédiate
WARN : configurations risquées ou non recommandées
INFO : informations utiles mais non bloquantes
PASS : contrôles réussis

Résultats du scan

Sortie de Dockle sur devops-status-api :

FATAL   - DKL-DI-0004: Use "apk add" with --no-cache
        * Use --no-cache option if use 'apk add': RUN apk add --no-cache --virtual .build-deps ...
          (détecté dans l'image de base Python officielle)

INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build

PASS    - 14 checks succeeded

Résumé JSON :

{
  "summary": {
    "fatal": 1,
    "warn": 0,
    "info": 1,
    "skip": 0,
    "pass": 14
  }
}

Ce qu’on observe :

1 FATAL : Vient de l’image de base Python officielle (pas notre Dockerfile)
1 INFO : Recommandation d’activer Docker Content Trust
14 PASS : Notre Dockerfile respecte les bonnes pratiques CIS Docker :
- ✅ Utilisateur non-root configuré
- ✅ Pas de secrets hardcodés
- ✅ Multi-stage build optimisé
- ✅ Pas de tag latest utilisé

Les options utiles de Dockle

Lorsque j’utilise Dockle au quotidien, certaines options me permettent d’adapter l’analyse à mes besoins, surtout en environnement CI/CD. Ces options sont précieuses pour personnaliser le comportement de l’outil et affiner les rapports de sécurité.

Voici celles que j’utilise le plus souvent :

`--exit-code`

Cette option permet de définir le code de sortie de Dockle si des problèmes sont détectés. Par défaut, Dockle retourne toujours 0, ce qui n’est pas idéal en automatisation.

Par exemple :

dockle --exit-code 1 devops-status-api:test
# Retourne 1 si WARN ou FATAL détecté

`--format`

Elle me permet de changer le format de sortie, ce qui est utile si je veux exploiter les résultats dans un outil externe (parsing, alerting, etc.).

raw (par défaut)
json

dockle --format json devops-status-api:test | jq '.summary'
# {"fatal": 1, "warn": 0, "info": 1, "skip": 0, "pass": 14}

`--ignore`

Il arrive parfois que certaines règles ne soient pas pertinentes pour mon contexte. Grâce à cette option, je peux ignorer des règles spécifiques :

dockle --ignore CIS-DI-0005 devops-status-api:test
# Ignore l'INFO Docker Content Trust

`--input-type`

Par défaut, Dockle analyse les images locales. Mais je peux aussi lui dire d’utiliser une image à distance, par exemple depuis un registre :

dockle --input-type=registry mon-registre.io/mon-image:tag

`--no-color`

dockle --no-color devops-status-api:test > dockle-report.txt

`--timeout`

dockle --timeout 60 devops-status-api:test

Intégration de Dockle dans un pipeline CI/CD

À mon avis, l’un des plus grands avantages de Dockle, c’est sa facilité d’intégration dans un pipeline CI/CD. C’est ce que je recommande toujours : automatiser les vérifications de sécurité dès la construction de l’image, pour éviter les mauvaises surprises plus tard.

Pourquoi intégrer Dockle dans un pipeline ?

L’objectif est simple : empêcher la mise en production d’images non conformes. Grâce à Dockle, je peux valider automatiquement qu’une image respecte les bonnes pratiques avant son déploiement.

Les bénéfices sont clairs :

Détection précoce des failles de configuration
Automatisation du contrôle qualité
Blocage conditionnel si des règles critiques échouent

Exemple avec GitLab CI

Voici un exemple de job dans un fichier .gitlab-ci.yml :

dockle_scan:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - apk add --no-cache curl
    - VERSION=$(curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
    - curl -L -o dockle https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit
    - chmod +x dockle
  script:
    - docker build -t devops-status-api:test .
    - ./dockle --exit-code 1 devops-status-api:test

Si vous ne maitrisez pas le gestionnaire de paquets apk, je vous recommande de lire mon guide sur apk pour mieux comprendre son fonctionnement.

Avec l’option --exit-code 1, le job échoue si une alerte de type WARN ou FATAL est détectée. Cela me permet de forcer les correctifs avant de passer à l’étape suivante.

Le mieux est de construire sa propre image contenant Dockle, pour éviter de télécharger le binaire à chaque fois.

Exemple avec GitHub Actions

Et voici un exemple équivalent pour GitHub Actions :

name: CI Dockle

on: [push]

jobs:
  dockle:
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Build Docker image
        run: docker build -t devops-status-api:test .

      - name: Install Dockle
        run: |
          VERSION=$(curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
          curl -L -o dockle https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit
          chmod +x dockle

      - name: Run Dockle
        run: ./dockle --exit-code 1 devops-status-api:test

Bonnes pratiques

Je préfère toujours :

Exécuter Dockle juste après le build
Échouer le job sur les erreurs critiques
Personnaliser la politique de sécurité avec --ignore si nécessaire

Intégré dans mon CI/CD, Dockle devient un gardien automatique de mes standards de sécurité. Je peux livrer plus sereinement, tout en respectant les exigences de conformité.

Conclusion

Dockle est, à mon avis, un outil à adopter sans hésitation pour toute personne soucieuse de la sécurité de ses images Docker. Simple à installer, facile à intégrer dans un pipeline CI/CD, il m’offre une analyse fine des configurations souvent négligées. C’est un excellent moyen d’automatiser la détection des erreurs courantes et de garantir un niveau de sécurité minimum avant mise en production.

Mais pour aller encore plus loin, je recommande vivement de le combiner à deux autres outils :

Hadolint pour analyser la qualité et les bonnes pratiques de vos Dockerfile.
Trivy pour détecter les vulnérabilités dans les paquets logiciels et dépendances embarquées dans les images.

À eux trois, Dockle, Hadolint et Trivy me permettent de construire des images à la fois propres, optimisées et sécurisées. Ce trio est, selon moi, le meilleur combo pour un workflow Docker robuste et conforme aux exigences modernes de la sécurité DevOps.

Plus d’infos

Le site officiel ↗
Le dépôt GitHub ↗

Sécuriser les images Docker avec Dockle​