Images Docker Durcies : Faut-il franchir le pas de la sécurité maximale ?

“0 vulnérabilités”. C’est la promesse de nouveaux acteurs comme Chainguard ou de projets comme IronBank. Pendant des années, nous avons utilisé des images Docker basées sur Debian ou Alpine sans trop nous soucier de ce qu’elles transportaient.

Aujourd’hui, avec l’explosion des attaques sur la Supply Chain logicielle, l’image Docker “standard” est-elle devenue une passoire irresponsable ? Doit-on systématiquement migrer vers des images renforcées ?

Le problème : L’obésité logicielle et les CVE

Une image python:3.11 standard pèse environ 300 Mo et contient souvent plus de 100 vulnérabilités connues (CVE) dès sa sortie. Pourquoi ? Parce qu’elle embarque une distribution complète avec des outils dont votre application n’a pas besoin : sed, grep, apt, voire un serveur SSH.

Réduire la surface d’attaque consiste à supprimer tout ce qui n’est pas strictement nécessaire à l’exécution du code. Moins de binaire, c’est moins de portes d’entrée pour un attaquant.

🚨 Supply Chain : Les attaques récentes qui doivent vous alerter

En 2025, les attaques sur la supply chain logicielle ont doublé par rapport à 2024. Les pertes globales sont estimées à 60 milliards de dollars. Voici des exemples concrets qui illustrent pourquoi les images conteneur sécurisées sont devenues critiques :

Incident	Date	Impact	Leçon
tj-actions/changed-files (GitHub Actions)	Mars 2025	70 000 clients Coinbase impactés, vol de tokens GitHub/npm	Les dépendances CI/CD sont des vecteurs d’attaque majeurs
PhantomRaven (npm)	Août 2025	126 packages malveillants, 86 000 installations	Les packages populaires peuvent être compromis
Shai-Hulud (npm auto-réplicant)	Sept 2025	Malware qui infecte automatiquement d’autres packages	Les worms supply chain se propagent sans intervention
Jaguar Land Rover	Août 2025	1,9 milliard £ de pertes, 5 000+ entreprises touchées	Une compromission supply chain peut paralyser toute une filière

Statistique clé : En 2025, 20% des attaques supply chain ont exploité des images conteneur empoisonnées ou non vérifiées. Une fois un composant malveillant dans une image de base, il se propage à 100% des services qui en dépendent. (Source: Secureframe)

---

Le match des solutions : Panorama du marché

Solution	Philosophie	Points Forts	Points Faibles
Distroless	Pas d’OS, juste l’app.	Sécurité maximale.	Pas de shell (debug complexe).
Alpine Linux	Minimalisme via musl.	Très légère (~5 Mo).	Problèmes de compatibilité glibc.
Chainguard Images	Images “Zero-CVE” + SBOM.	1800+ images, rebuild quotidien.	Pro payant, ~50 images gratuites (latest uniquement).
Echo	Images Zero-CVE reconstruites depuis les sources.	SLA 24h CVE critiques, FIPS 140-3.	Nouvel acteur (2025), prix sur devis.
Red Hat UBI	Base Enterprise stable.	Support 10 ans, FIPS, STIG.	Plus lourde (200-400 Mo).
Bitnami	Optimisé & Prêt à l’emploi.	Excellent compromis.	Dépendance écosystème VMware.
Docker Hardened Images	Images officielles renforcées, GRATUITES (Apache 2.0).	1000+ images, réduction 95% surface d’attaque.	Pas de SLA (version gratuite).

---

Comment choisir une image sécurisée ? Critères concrets

Avant de sélectionner une image, évaluez ces critères mesurables :

🔍 Checklist de sélection d’une image sécurisée

Critère	Comment vérifier	Seuil acceptable
Nombre de CVE	trivy image <image> ou grype <image>	< 10 CVE (0 critiques/élevées)
Taille de l’image	docker images <image>	< 200 Mo (idéal < 100 Mo)
Âge de la dernière mise à jour	Docker Hub / Registry	< 30 jours
SBOM disponible	Vérifier attestations Cosign/Syft	✅ Obligatoire pour production
Provenance signée	cosign verify <image>	SLSA Level 2+ recommandé
Utilisateur non-root	docker inspect --format '{{.Config.User}}'	UID != 0 ou vide
Pas de shell (si sécurité max)	docker run --rm <image> sh doit échouer	❌ Shell absent
Source du mainteneur	Vérifier l’éditeur officiel	Docker Official, Verified Publisher

🎯 Matrice de décision rapide

Besoin principal	Solution recommandée
Sécurité maximale (pas de shell)	Distroless, Chainguard
Zero-CVE garanti avec SLA	Chainguard Pro, Echo
Compatibilité glibc + sécurité	Docker Hardened Images
Légèreté maximale (< 50 Mo)	Alpine, Chainguard
Environnement régulé (FIPS, STIG)	Red Hat UBI, DHI Enterprise, Echo
Budget limité / POC	Docker Hardened Images (gratuit)
Legacy / compatibilité maximale	Debian-slim, Red Hat UBI

---

Pourquoi le faire (et pourquoi hésiter) ?

✅ Les arguments “POUR”

• Réduction radicale des CVE : Moins de composants = moins de failles. Vos scans Trivy ou Grype deviennent enfin lisibles.
• Auditabilité via le SBOM : Les images modernes comme Wolfi incluent un Software Bill of Materials. C’est la liste des ingrédients précise de votre conteneur, indispensable pour la conformité (SOC2, ISO27001).
• Performance : Des images plus légères signifient des pull plus rapides et une occupation disque réduite.

❌ Les arguments “CONTRE”

• Difficulté de débogage : Sans sh ou ls, impossible de faire un kubectl exec. Il faut apprendre à utiliser des outils de diagnostic externes ou kubectl debug.
• Le piège de la compatibilité : Alpine utilise musl libc. Si votre application (Python, Java ou Go avec CGO) s’attend à glibc, vous risquez des bugs de performance ou des plantages silencieux.
• Coût de maintenance : Maintenir une image durcie demande une reconstruction fréquente pour rester à “Zero-CVE”.

---

Analyse critique : Les points de vigilance

Les limites du “Zero-CVE”

Le marketing des images “Zero-CVE” peut être trompeur. Une image sans CVE connue n’est pas une image sans faille. Elle reflète simplement l’état des bases de vulnérabilités à un instant T. De plus :

• Les CVE non publiques : Les failles zero-day ne sont pas listées dans les CVE, mais existent.
• Le risque de dépendance : S’appuyer sur un fournisseur unique (Chainguard, etc.) crée un SPOF (Single Point of Failure) dans votre supply chain.
• La réactivité variable : Toutes les équipes ne patchent pas à la même vitesse. Une CVE critique sur une dépendance transitive peut prendre des jours à être corrigée.

Le débat Alpine vs glibc

Alpine est souvent présentée comme “LA” solution minimaliste, mais :

• Les incompatibilités musl avec glibc peuvent provoquer des bugs subtils (performances DNS, comportements de threads).
• Certaines bibliothèques natives (notamment en Python/Java) ne sont pas compilées pour musl, forçant à recompiler manuellement.

Le coût caché du hardening

• Temps d’apprentissage : Les équipes doivent maîtriser de nouveaux patterns de debug (sidecar containers, ephemeral containers).
• CI/CD plus complexe : Les builds multi-stage deviennent obligatoires pour construire des images Distroless.
• Monétisation progressive : Les solutions gratuites comme Chainguard deviennent payantes dès qu’on veut du support ou des images spécifiques.

---

Avantages et inconvénients détaillés

✅ Avantages majeurs

1. Sécurité renforcée

• Réduction de la surface d’attaque : Moins de packages = moins de vecteurs d’exploitation potentiels.
• Conformité réglementaire : Facilite l’obtention des certifications (ISO 27001, SOC2, RGPD).
• Audit facilité : Le SBOM permet de tracer chaque composant et sa provenance.

2. Performance optimisée

• Temps de déploiement réduit : Images plus légères (50-100 Mo vs 300+ Mo) = pull et démarrage plus rapides.
• Coût d’infrastructure : Moins d’espace disque utilisé sur les registries et les nœuds Kubernetes.
• Scaling plus efficace : Le démarrage rapide améliore l’auto-scaling horizontal.

3. Maintenabilité

• Moins de faux positifs : Les scans de sécurité deviennent exploitables (10 CVE vs 150).
• Dépendances explicites : Le principe “only what you need” force à documenter les vraies dépendances.
• Mises à jour ciblées : Patcher uniquement ce qui est utilisé réduit le risque de régression.

❌ Inconvénients et défis

1. Complexité opérationnelle

• Debugging difficile : Pas de shell = pas de docker exec classique. Nécessite des outils comme :
  • kubectl debug avec des images éphémères
  • docker cp pour extraire des fichiers
  • Outils de debugging distant (Telepresence, Squash)
• Courbe d’apprentissage : Les équipes doivent changer leurs habitudes et apprendre de nouveaux workflows.

2. Compatibilité et portabilité

• Problèmes de libc : Alpine (musl) vs images standard (glibc) créent des incompatibilités subtiles.
• Dépendances natives : Les wheels Python pré-compilés ou les JARs Java peuvent ne pas fonctionner.
• Legacy code : Les applications anciennes attendant un environnement complet sont difficiles à migrer.

3. Coût et dépendance

• Coût des solutions commerciales : Chainguard Pro, Red Hat UBI avec support = budget licensing.
• Lock-in potentiel : Dépendre d’un registry propriétaire peut poser problème en cas de changement de stratégie tarifaire.
• Overhead de maintenance : Maintenir ses propres images durcies nécessite une équipe dédiée.

---

Focus : Docker Hardened Images - Le tournant de décembre 2025

🎯 Annonce majeure : Docker Hardened Images devient gratuit et open source

En décembre 2025, Docker a révolutionné le marché des images durcies en rendant Docker Hardened Images (DHI) totalement gratuit et open source sous licence Apache 2.0. Cette décision stratégique change la donne pour l’ensemble de l’écosystème conteneur.

“Security shouldn’t be a premium feature. By making hardened images free, Docker is letting every developer, not just big enterprises, start with a safer foundation.” - Ryan J. Salva, Senior Director of Product at Google

Depuis mai 2025, Docker avait lancé DHI en version commerciale. Six mois plus tard, fort de 1000+ images et Helm charts durcis, Docker ouvre l’accès à tous les 26 millions de développeurs de l’écosystème conteneur.

Qu’est-ce que Docker Hardened Images ?

Docker Hardened Images sont des conteneurs construits avec des pratiques de sécurité strictes et une philosophie de transparence totale :

Caractéristiques techniques :

• Scan automatisé et continu : Chaque image est scannée quotidiennement avec Docker Scout
• Runtime distroless : Surface d’attaque réduite tout en préservant les outils essentiels
• SBOM complet et vérifiable : Traçabilité totale des composants (pas de CVE cachées)
• SLSA Build Level 3 provenance : Preuve d’authenticité pour chaque build
• Signatures cryptographiques : Validation de l’intégrité avec Cosign
• Fondations familières : Basé sur Alpine et Debian, compatibilité maximale

Catalogue disponible :

• 1000+ images durcies : Nginx, Redis, PostgreSQL, MongoDB, Elasticsearch, et bien d’autres
• Helm Charts durcis : Prêts pour Kubernetes
• MCP Servers durcis : Pour les applications agentiques et LLM (MongoDB, Grafana, GitHub, Context7…)
• Réduction de 95% de la surface d’attaque par rapport aux images traditionnelles (source)

Accès immédiat : Toutes les DHI sont disponibles gratuitement sur Docker Hub - Hardened Images Catalog sous licence Apache 2.0. Aucun abonnement requis pour l’usage de base.

Avantages par rapport aux autres solutions

✅ Points forts spécifiques

1. Gratuité et Open Source (nouveau !)

• Gratuit pour tous : Licence Apache 2.0, aucun coût pour l’usage standard
• Aucune restriction : 26 millions de développeurs peuvent l’utiliser sans limite
• Transparent à 100% : Pas de CVE cachées ou de “CVE scoring propriétaire”
• Écosystème ouvert : Partenariats avec Google Cloud, MongoDB, CNCF, Anaconda, Socket

2. Écosystème et compatibilité

• Fondations éprouvées : Basé sur Alpine et Debian - familier et compatible glibc
• Migration facilitée : Assistant AI de migration qui scanne et recommande automatiquement les images équivalentes
• 1000+ images : Couverture massive (vs 10-15 au lancement) - Infrastructure, bases de données, outils
• Support long terme : Alignement avec les cycles de vie upstream des éditeurs

3. Intégration Docker Desktop & Tooling

• Docker Scout intégré : Analyse en continu directement dans Docker Desktop et CLI
• Recommandations automatiques : Suggestions de mise à jour vers des versions patchées
• Supply Chain attestation : SLSA Level 3 provenance + signatures Cosign vérifiables
• Intégration scanners : Support natif Snyk, JFrog Xray, Trivy

4. Équilibre sécurité / Usabilité

• Runtime distroless avec outils : Surface d’attaque minimale MAIS shell disponible pour debug
• Outils essentiels préservés : curl, wget disponibles (contrairement à Google Distroless strict)
• Migration progressive : Drop-in replacement - remplacez nginx:latest par l’équivalent DHI
• Adoption sans friction : Aucune refactoring nécessaire pour démarrer

5. Gouvernance et compliance

• Transparence totale : Toutes les CVE sont exposées publiquement (pas de masquage)
• SBOM complet : Software Bill of Materials intégré et vérifiable
• Audit trail complet : Historique des modifications et patches traçables
• Certifications disponibles : FIPS 140-2, Common Criteria (dans DHI Enterprise)

Inconvénients et limites

❌ Points faibles à considérer

1. Modèle de monétisation à deux vitesses

• Version gratuite puissante MAIS : Pas de SLA sur les patchs, pas de FIPS, pas de customisation
• DHI Enterprise payant pour :
  • SLA < 7 jours sur CVE critiques (roadmap vers < 1 jour)
  • Images conformes FIPS 140-2 / STIG pour environnements régulés
  • Customisation illimitée (certificats, packages système, scripts)
  • Service de build géré par Docker avec provenance maintenue
• DHI Extended Lifecycle Support (ELS) : Payant - 5 ans de support post-EOL upstream
• Coût non public : Tarification Enterprise sur devis (vs tarifs transparents Chainguard)

2. Catalogue et disponibilité

• 1000+ images disponibles : Large couverture mais pas exhaustive
• Pas tous les runtimes : Images Python/Node.js/Java en cours d’ajout au catalogue
• Dépendance a la roadmap Docker : Vous ne contrôlez pas les priorités de Docker Inc.
• Nouveauté relative : Écosystème moins mature que Debian/Alpine (lancé en 2024)

3. Lock-in écosystème Docker

• Dépendance à Docker Inc. : Même sous Apache 2.0, l’écosystème est contrôlé par Docker
• Registry centralisé : Les images DHI officielles sont hébergées sur Docker Hub
• Fork possible mais complexe : Open source MAIS reproduire l’infrastructure de build est difficile
• Risque de changement de modèle : L’histoire de Docker (Docker Swarm, Docker Hub rate limiting) crée une méfiance

4. Approche de sécurité pragmatique (pas “Zero-CVE”)

• Pas de promesse “Zero-CVE” : Docker privilégie la transparence au marketing agressif
• Vulnérabilités transitoires : Version gratuite = pas de SLA, des CVE peuvent exister temporairement
• Moins agressif que Chainguard : Chainguard rebuild quotidien vs patching Docker “best effort” en version gratuite
• Transparence totale = plus de CVE affichées : Docker ne cache aucune CVE, même en cours de correction (bien, mais peut affoler les scanners)

Comparaison détaillée avec les alternatives

Docker Hardened vs Chainguard Images

Critère	Docker Hardened (Gratuit)	Chainguard (Public)	Chainguard (Pro)
Objectif “Zero-CVE”	Non (transparence)	Oui (rebuild quotidien)	Oui + SLA
Taille des images	Moyenne (100-200 MB)	Très petite (10-50 MB)	Très petite
Compatibilité base	✅ Alpine/Debian (glibc)	⚠️ Wolfi (musl)	⚠️ Wolfi (musl)
Shell disponible	✅ Oui (distroless avec outils)	❌ Non strict	❌ Non strict
Prix	✅ Gratuit (Apache 2.0)	✅ Gratuit (~50 images, latest uniquement)	$$$ (tarif catalogue ou par image)
Catalogue d’images	1000+ images	~50 publiques (réduit en août 2025)	1800+ complètes
SLA patching	❌ Non (best effort)	❌ Non	✅ Oui (< 24h)
Support entreprise	Payant (DHI Enterprise)	❌ Non	✅ Inclus
Transparence CVE	✅ Totale	✅ Totale	✅ Totale

Note : En août 2025, Chainguard a réduit son offre gratuite, passant de 100+ à ~50 images gratuites (tag :latest uniquement). Docker a qualifié ce changement de “rug-pull”.

Verdict : Docker DHI gratuit est idéal pour démarrer sans coût. Chainguard offre des images plus petites et “Zero-CVE” garanti (Pro). Si budget limité et besoin de compatibilité Alpine/Debian : Docker DHI. Si sécurité maximale et budget : Chainguard Pro.

Docker Hardened vs Echo

Critère	Docker Hardened (Gratuit)	Echo
Objectif “Zero-CVE”	Non (transparence)	✅ Oui (rebuild depuis sources)
Taille des images	Moyenne (100-200 MB)	Moyenne à petite
SLA CVE critiques	❌ Non (best effort)	✅ 24h CVE critiques, 7j résolution complète
FIPS	Payant (DHI Enterprise)	✅ FIPS 140-3 disponible
Prix	✅ Gratuit (Apache 2.0)	$$$ (sur devis)
Maturité	Établi (Docker Inc.)	Nouveau (fondé 2025, $15M levés)
Approche	Patching d’images existantes	Reconstruction IA depuis les sources
Distroless	Oui (avec shell minimal)	✅ Variantes distroless disponibles

Verdict : Echo est le challenger sérieux pour les entreprises exigeant du “Zero-CVE” avec SLA strict. Fondé par les créateurs d’Argon (acquis par Aqua), Echo utilise l’IA pour reconstruire les images depuis les sources. Si vous avez besoin d’un SLA garanti et d’un budget : Echo. Pour démarrer gratuitement : Docker DHI.

Docker Hardened vs Alpine Linux

Critère	Docker Hardened (Gratuit)	Alpine Linux
Taille	Moyenne (100-200 MB)	✅ Très petite (5-50 MB)
Compatibilité	✅ Alpine/Debian base (glibc)	❌ musl (problèmes fréquents)
Maintenance	✅ Docker Inc. (officiel)	Communauté Alpine
Coût	✅ Gratuit (Apache 2.0)	✅ Gratuit (MIT)
Patching CVE	✅ Automatique (best effort)	⚠️ Variable selon package
SBOM & Provenance	✅ Intégré (SLSA L3)	❌ Non inclus par défaut
Debugging	✅ Shell distroless + outils	✅ Shell complet BusyBox
Écosystème	Docker Hub officiel	✅ Indépendant

Verdict : Alpine reste plus légère et totalement indépendante, mais Docker Hardened élimine les problèmes de compatibilité musl et ajoute SBOM/provenance par défaut. Si compatibilité maximale recherchée : Docker DHI. Si taille minimale prioritaire : Alpine.

Docker Hardened vs Google Distroless

Critère	Docker Hardened (Gratuit)	Google Distroless
Sécurité maximale	✅ Excellente (distroless runtime)	✅ Excellente (strict)
Shell & Debugging	✅ Shell minimal disponible	❌ Pas de shell du tout
Facilité d’adoption	✅ Drop-in replacement	⚠️ Nécessite refactoring apps
Coût	✅ Gratuit (Apache 2.0)	✅ Gratuit (Apache 2.0)
Support	✅ Commercial (DHI Enterprise)	Communauté Google
SBOM & Provenance	✅ SLSA L3 intégré	⚠️ À construire soi-même
Flexibilité	Moyenne (Alpine/Debian base)	✅ Totale (Open Source)
Migration AI	✅ Assistant AI intégré	❌ Non

Verdict : Distroless offre la sécurité la plus stricte (zéro shell), Docker Hardened offre un meilleur équilibre opérationnel avec shell minimal et migration facilitée. Si sécurité absolue : Distroless. Si équilibre sécurité/opérabilité : Docker DHI.

Docker Hardened vs Red Hat UBI

Critère	Docker Hardened (Gratuit)	Red Hat UBI
Support entreprise	✅ Payant (DHI Enterprise)	✅ Red Hat (leader mondial)
Certifications	FIPS, CC (DHI Enterprise)	✅ FIPS, CC, DISA STIG
Taille	Moyenne (100-200 MB)	⚠️ Plus lourde (200-400 MB)
Coût	✅ Gratuit (avec option Enterprise)	✅ Gratuit (support avec RHEL sub)
Écosystème	Docker Hub	✅ OpenShift, Kubernetes
Long Term Support	ELS payant (5 ans post-EOL)	✅ 10 ans (avec subscription)
Transparence	✅ CVE publiques, SBOM	✅ CVE publiques

Verdict : UBI est le standard des grandes entreprises Red Hat/OpenShift. Docker Hardened convient aux équipes sans infrastructure Red Hat et offre plus de légèreté. Si déjà écosystème Red Hat : UBI. Si Docker-first : Docker DHI.

Quand choisir Docker Hardened Images ?

✅ Utilisez Docker Hardened Images (version gratuite) si :

• Vous débutez avec les images durcies et voulez tester sans coût
• Vous voulez un “quick win” de sécurité sans refactoring massif (drop-in replacement)
• Vous valorisez la compatibilité Alpine/Debian (glibc) et la facilité de debug (shell disponible)
• Vous utilisez l’infrastructure concernée par le catalogue : Nginx, Redis, PostgreSQL, MongoDB, Elasticsearch, etc.
• Vous voulez SBOM et provenance SLSA L3 par défaut sans configuration
• Vous cherchez une solution open source (Apache 2.0) sans lock-in de licence

💵 Passez à Docker Hardened Images Enterprise si :

• Vous avez besoin de SLA < 7 jours sur les CVE critiques (roadmap < 1 jour)
• Votre secteur exige FIPS 140-2, STIG, ou autres certifications de conformité
• Vous voulez customiser les images (certificats, packages, scripts) avec build géré
• Vous avez besoin de support officiel contractuel de Docker Inc.
• Vous voulez Extended Lifecycle Support (ELS) pour images post-EOL (5 ans)

❌ Évitez Docker Hardened Images si :

• Vous cherchez “Zero-CVE” garanti avec SLA (préférez Chainguard Pro ou Echo)
• Vous voulez des images ultra-minimales < 50 MB (préférez Alpine ou Chainguard)
• Vous voulez la sécurité maximale absolue sans aucun shell (préférez Distroless)
• Vous êtes déjà écosystème Red Hat/OpenShift (préférez UBI)
• Vous avez besoin de FIPS 140-3 sans payer DHI Enterprise (préférez Echo)
• Vous voulez éviter toute dépendance à Docker Inc. (préférez Alpine ou Debian construites vous-même)

Recommandation : Docker Hardened Images ne doit pas être votre SEULE solution de sécurité. Considérez-les comme un composant d’une stratégie de défense en profondeur qui inclut aussi : scanning continu (Trivy, Grype), politique d’admission (OPA/Kyverno), runtime security (Falco), et supply chain security (Sigstore).

---

Zoom technique : L’importance du SBOM

Le SBOM est à l’image Docker ce que la liste des ingrédients est à un plat préparé. En utilisant des outils comme Grype, vous pouvez comparer le SBOM de votre image avec les bases de données de vulnérabilités en temps réel.

Note : Si vous n’utilisez pas d’images renforcées, vous passez souvent votre temps à trier des “faux positifs” dans vos rapports de sécurité. Les images durcies nettoient ce bruit.

---

Conclusion : Quelle stratégie adopter ?

Faut-il tout migrer ? La réponse est pragmatique : commencez par la périphérie, et profitez maintenant de la gratuité de Docker Hardened Images.

1. Priorité 1 : Vos applications exposées sur Internet (Front-end, APIs publiques). Docker Hardened Images (gratuit), Distroless ou Chainguard sont recommandés.
2. Priorité 2 : Votre infrastructure (Nginx, Redis, DBs). Docker Hardened Images est maintenant le choix évident : gratuit, 1000+ images, SBOM inclus.
3. Priorité 3 : Vos outils internes. Une image Bitnami ou Debian-Slim bien configurée (utilisateur non-root, système de fichier en lecture seule) reste un excellent compromis.
4. Approche progressive : Ne migrez pas tout en une fois. Utilisez l’assistant AI de migration Docker pour identifier les quick wins.
5. Investissement dans l’outillage : Intégrez Trivy, Syft et Cosign dans votre CI/CD dès le départ.
6. Formation des équipes : Prévoyez des sessions de formation sur les nouveaux workflows de debugging (ephemeral containers, kubectl debug) et de déploiement.

Recommandations par cas d’usage

Contexte	Solution recommandée	Justification
Découverte / POC	Docker Hardened Images (gratuit)	Zéro coût, SBOM inclus, 1000+ images, facile à tester
Startup/MVP	Alpine ou Debian-slim ou DHI gratuit	Flexibilité maximale, apprentissage progressif
Application cloud-native nouvelle	Distroless ou Chainguard	Sécurité maximale dès le départ
Legacy monolithique	Red Hat UBI ou Bitnami	Compatibilité avec l’existant
Microservices à haute exposition	Chainguard Pro, Echo ou DHI Enterprise	Conformité et auditabilité “Zero-CVE” garanti avec SLA
Services internes/admin	Debian-slim durci ou DHI gratuit	Équilibre debug/sécurité
Infrastructure (Nginx, Redis, DBs, K8s)	Docker Hardened Images (gratuit)	1er choix désormais : gratuit, support officiel, 1000+ images, compatibilité garantie, SBOM/provenance SLSA L3
Environnements régulés (Finance, Santé, Défense)	DHI Enterprise, Echo ou Red Hat UBI	FIPS 140-2/3, STIG, SLA contractuels
Applications agentiques / LLM	Docker Hardened Images (MCP Servers)	Images MCP durcies pour MongoDB, Grafana, GitHub, Context7

---