Sécurité Docker et conteneurs en 2026 : Trivy, Falco et CIS Docker Benchmark

Les conteneurs représentent aujourd'hui plus de 90 % des nouveaux déploiements applicatifs en entreprise. Pourtant, selon le rapport Sysdig 2025, 87 % des images Docker contiennent des vulnérabilités à risque élevé ou critique, et seulement 15 % des organisations ont mis en place une détection runtime. Voici comment sécuriser vos conteneurs de bout en bout.

1. Les risques spécifiques aux environnements conteneurisés

• Images vulnérables : dépendances OS et applicatives non à jour dans les layers Docker.
• Exécution en root : 75 % des conteneurs tournent avec les privilèges root (Sysdig 2025).
• Secrets hardcodés : mots de passe, tokens API ou clés privées dans les Dockerfiles ou variables d'environnement.
• Escape de conteneur : exploitation de CVE dans le runtime (runc, containerd) pour accéder à l'hôte.
• Registres non sécurisés : images publiques non vérifiées téléchargées depuis Docker Hub.
• Configurations réseau permissives : absence de Network Policies dans Kubernetes.

2. Sécuriser les images Docker : CIS Benchmark et images minimales

Adopter des images de base minimales

• distroless (Google) : images sans shell, sans gestionnaire de paquets — réduisent la surface d'attaque de 90 %.
• Alpine Linux : image minimaliste <10 Mo, musl libc, audit de sécurité régulier.
• Chainguard Images : images hardened par défaut, mises à jour quotidiennes, CVE proches de zéro.

CIS Docker Benchmark v1.6

Le CIS Docker Benchmark définit les bonnes pratiques de configuration pour l'hôte Docker, le daemon, les images et les conteneurs. Points clés :

• Exécuter les conteneurs avec un utilisateur non-root (USER 1001 dans le Dockerfile).
• Utiliser un système de fichiers en lecture seule (--read-only).
• Limiter les capabilities Linux (--cap-drop ALL --cap-add NET_BIND_SERVICE).
• Activer les profils Seccomp et AppArmor/SELinux.
• Ne jamais utiliser --privileged en production.
• Isoler les conteneurs sur des réseaux dédiés, pas sur le réseau bridge par défaut.

3. Scan de vulnérabilités avec Trivy

Trivy (Aqua Security, open source) est le scanner de vulnérabilités de référence pour les conteneurs. Il détecte les CVE dans les packages OS, les dépendances applicatives (npm, pip, Maven, Go modules), les fichiers de configuration et les secrets.

Intégration CI/CD GitHub Actions :

• Scanner chaque image avant push vers le registre.
• Bloquer le pipeline si une CVE critique est détectée (--exit-code 1 --severity CRITICAL).
• Générer des rapports SARIF intégrés dans GitHub Security tab.
• Utiliser trivy repo pour scanner les dépendances du code source.

Compléments : Grype (Anchore), Snyk Container,Docker Scout (intégré à Docker Desktop depuis 2024).

4. Signature et intégrité des images : Cosign et Notation

Suite à l'attaque de la supply chain SolarWinds et à XZ Utils (2024), la signature des images est devenue incontournable. L'écosystème Sigstore propose :

• Cosign : signe les images OCI avec des clés ou des certificats éphémères (keyless signing).
• Rekor : journalisation transparente des signatures (append-only log public).
• Notation (CNCF) : standard de signature pour les registres compatibles OCI.

En production, configurez votre cluster Kubernetes pour n'accepter que des images signées via un Admission Webhook (Kyverno, OPA Gatekeeper).

5. Détection runtime avec Falco

Falco (CNCF) monitore en temps réel les appels système des conteneurs et déclenche des alertes sur les comportements anormaux :

• Exécution de shell dans un conteneur en production (container.id != host AND proc.name = bash).
• Lecture de fichiers sensibles (/etc/shadow, clés privées).
• Connexion réseau vers une IP externe depuis un conteneur de base de données.
• Escalade de privilèges ou modification des capabilities.
• Accès au socket Docker depuis un conteneur (risque d'escape).

Les alertes Falco peuvent être envoyées vers Slack, un SIEM (Splunk, Elastic), ou un SOAR pour réponse automatisée (isolation du conteneur compromis).

6. Gestion des secrets dans les conteneurs

Les variables d'environnement en clair sont accessibles à tous les processusdu conteneur et peuvent apparaître dans les logs. Les bonnes pratiques :

• HashiCorp Vault : injection dynamique de secrets au démarrage via l'agent Vault sidecar.
• AWS Secrets Manager / Azure Key Vault : récupération des secrets via SDK, avec rotation automatique.
• Kubernetes Secrets : chiffrer les secrets etcd au repos (EncryptionConfiguration) ; utiliser External Secrets Operator pour synchroniser depuis Vault.
• Scanner les Dockerfiles avec detect-secrets ou truffleHog dans la CI pour éviter les commits accidentels.

7. Sécurité Kubernetes : RBAC, Network Policies et PSA

• RBAC : principe de moindre privilège pour tous les ServiceAccounts ; auditer les ClusterRoleBindings régulièrement.
• Network Policies : bloquer tout le trafic par défaut et n'autoriser que les flux nécessaires (deny-all ingress/egress).
• Pod Security Admission (PSA) : remplace PodSecurityPolicies depuis K8s 1.25 ; utiliser le profil restricted en production.
• Admission controllers : Kyverno pour imposer les règles de conformité (no latest tag, no root, resource limits obligatoires).
• Audit logs API server : activer et centraliser vers un SIEM.

Conclusion

Sécuriser les conteneurs est un travail continu qui s'intègre à chaque étape du cycle DevSecOps : build (Trivy, signature Cosign), deploy (RBAC, PSA, Kyverno), runtime (Falco, Network Policies). En appliquant le CIS Docker Benchmark et en automatisant les contrôles en CI/CD, vous réduisez drastiquement votre surface d'attaque sans ralentir la vélocité de vos équipes de développement.