Meilleurs outils de durcissement d'images en 2026

Les modèles d'images de conteneurs standard sont surchargés de logiciels superflus, ce qui élargit la surface d'attaque et introduit potentiellement des CVE et des vulnérabilités. Des chercheurs ayant examiné 7 380 images Docker basées sur Debian ont découvert qu'aucune d'entre elles n'était exempte de vulnérabilités connues. Le durcissement des images est le processus qui consiste à alléger les images de conteneurs pour en faire des versions plus petites et sécurisées, réduisant ainsi les points d'entrée pour les attaquants et respectant les normes réglementaires.

Mais le durcissement des images a évolué et peut signifier différentes choses en 2026. Certains outils recréent des images sans CVE sur leurs propres distributions. Cela implique toutefois de migrer chaque service vers leur image de base, de tester à nouveau pour détecter d'éventuelles régressions, et de rester dépendant de la distribution et du rythme de publication de cet éditeur. Une autre approche consiste à patcher l'image que vous utilisez déjà, ce qui vous permet de conserver la même distribution et la même version majeure tout en évitant la migration.

Cet article compare les meilleurs outils de durcissement d'images en 2026 selon leur méthode de durcissement, le risque de migration et de rupture de compatibilité, la vitesse de remédiation, et leur intégration dans votre workflow de sécurité. Nous comparons :

• Aikido Security
• Chainguard
• Docker Hardened Images
• Rapidfort
• Echo
• Minimus
• Wiz

TL;DR

Aikido Security est notre premier choix. Plutôt que de vous obliger à migrer vers une nouvelle distribution, l'outil patche l'image de base que vous utilisez déjà, éliminant ainsi toute migration et tout changement bloquant. Les correctifs sont appliqués via une PR d'autofix que vous examinez et merge en un seul clic. Ensuite, Aikido continue de reconstruire l'image au fur et à mesure que de nouvelles vulnérabilités sont corrigées et vous alerte lorsqu'une version plus récente est disponible. Aikido continue également de patcher les versions après leur fin de vie (EOL), vous permettant de conserver une base plus ancienne sans subir ses CVE critiques et élevées connues. Aikido Intel étend la couverture au-delà des bases de données publiques, en signalant les vulnérabilités qui ont été patchées discrètement en amont sans jamais recevoir de CVE. Chaque image constitue un remplacement direct et inclut un SBOM, un VEX et une provenance SLSA, couvrant les CVE au niveau de l'OS dans le cadre d'un SLA de création de correctifs défini, le tout au sein d'une plateforme qui couvre également le SAST, le DAST, le SCA, la détection de secrets et la posture cloud.

{{cta}}

Qu'est-ce que le durcissement des images de conteneurs ?

Une image de base de conteneur constitue la couche de départ fondamentale d'un conteneur. Une image publique standard intègre généralement des gestionnaires de paquets, des shells, des compilateurs et des outils de débogage pour convenir à tout le monde, mais votre application n'a probablement pas besoin de la plupart de ces éléments. 

Le durcissement consiste à supprimer les logiciels que la charge de travail n'utilise jamais (ce qui élimine des catégories entières de vulnérabilités ainsi que les paquets associés) et à sécuriser ce qui reste grâce à des versions corrigées, des paramètres par défaut sécurisés, une exécution sans privilèges root et une configuration alignée sur les normes CIS/STIG.

Il en résulte une image plus petite et plus propre, qui démarre de manière sécurisée et le reste à mesure que les vulnérabilités en amont sont découvertes et corrigées. Les images durcies génèrent également des preuves d'audit telles que des SBOM signés, la provenance des builds, des déclarations VEX et des signatures de conformité.

Limites courantes des outils de durcissement d'images

La plupart des outils de durcissement d'images vous obligent à abandonner votre image de base actuelle pour adopter leur catalogue, puis à suivre leur rythme de reconstruction tant que vous l'utilisez. Cette approche a un coût. L'adoption implique une migration, et tout élément supprimé par le fournisseur sur lequel votre application comptait discrètement peut provoquer des pannes. Rester à jour en matière de correctifs signifie avancer vers chaque nouveau condensé (digest), ce qui fait de chaque correction une nouvelle image à tester et, dans le cadre de la gestion des changements, à faire revalider. Si vous épinglez un condensé (digest) pour des raisons de stabilité, vous vous privez précisément des correctifs pour lesquels vous aviez adopté l'outil. 

Quelques limites s'appliquent également de manière générale aux images durcies. La suppression des paquets qu'une charge de travail n'utilise jamais élimine les vulnérabilités, mais une CVE dans un paquet dont vous avez réellement besoin nécessite toujours un vrai correctif. De plus, toute reconstruction peut modifier le comportement sur lequel votre build comptait, ce qui explique pourquoi le changement d'images s'accompagne toujours d'une série de tests.

L'alternative consiste à corriger l'image de base que vous utilisez déjà, en conservant votre distribution et votre version majeure en l'état, ainsi que les composants open source sous-jacents de votre application. Il n'y a pas de catalogue de fournisseur vers lequel migrer et aucun changement de plateforme à opérer. 

Que rechercher dans un outil de durcissement d'images

Tous les outils proposant le « durcissement d'images » ne se valent pas. Vous devriez examiner ces critères avant de prendre une décision.

• Un vaste catalogue prêt à l'emploi : Pour combien d'images de base que vous utilisez réellement propose-t-il des versions durcies ? Recherchez une réelle diversité parmi des distributions telles que Debian, Ubuntu et Alpine, la prise en charge des architectures amd64 et arm64, ainsi qu'un catalogue activement maintenu.
• Une provenance vérifiable : Cela comprend un SBOM signé (Software Bill of Materials, l'inventaire complet du contenu de l'image), un document VEX (Vulnerability Exploitability Exchange, qui répertorie les CVE qui ne vous affectent pas réellement) et une provenance SLSA (un standard attestant comment et où l'image a été construite) associés à chaque extraction (pull). 
• Sécurité après la fin de vie : recherchez un correctif qui continue après la transition de la distribution en amont, afin de pouvoir conserver une ancienne version de base sans accepter ses vulnérabilités critiques et élevées connues.
• Intelligence de remédiation : l'outil se limite-t-il à identifier les vulnérabilités dotées d'un CVE ? Avec la transition du NVD vers un modèle basé sur les risques menée par le NIST d'ici 2026, une part croissante de vulnérabilités réelles ne disposera pas d'un CVE en temps voulu, et certaines n'en auront jamais. Tout outil connecté uniquement aux flux CVE publics hérite de ces angles morts. 
• Conformité aux normes : celles-ci exigent des images minimisées et une traçabilité documentée. Vérifiez que l'outil produit cette preuve automatiquement.

Meilleurs outils de durcissement d'images pour 2026

Aikido Security

Aikido Images corrige l'image de base que vous utilisez déjà au lieu de vous forcer à migrer vers une nouvelle, ce qui évite toute rupture de compatibilité. Aikido Images est un catalogue de plus de 2 000 images de remplacement direct où les vulnérabilités CRITIQUES/ÉLEVÉES connues de la base ont déjà été corrigées. Ces images sont reconstruites, corrigées, minimisées et durclies lors du build, vous offrant ainsi une prise en charge complète, une surface d'attaque réduite et des configurations par défaut verrouillées, le tout sur la base que vous exécutez déjà.

Pour exemple, debian:bookworm fournit un correctif glib2.0 pour la vulnérabilité CVE-2025-4373, que Debian a corrigée dans Trixie/Sid mais pas dans Bookworm. La variante Aikido Images de debian:bookworm contient une version corrigée de glib2.0 qui résout cette vulnérabilité. 

Le remplacement étant direct et proposé par AutoFix sous forme de PR, le correctif s'applique dès le merge au lieu d'intervenir à la fin d'un cycle de test et de migration. De plus, chaque téléchargement depuis docker.aikido.io inclut un SBOM, un VEX et une traçabilité SLSA. Aikido continue de corriger les versions après l'abandon par l'amont, y compris celles qui ont atteint leur fin de vie, ce qui vous permet de conserver une ancienne version de base sans subir ses failles de sécurité connues, et sans être contraint de passer à une version plus récente pour rester couvert.

Aikido construit également ses images à partir de sources ouvertes standard, les mêmes paquets en amont fournis par la distribution, là où plusieurs de ces outils reconstruisent tout à partir de leur propre code source ou d'une distribution propriétaire.

Une part croissante de correctifs réels ne reçoit jamais de CVE. La surveillance continue d'Aikido est alimentée en partie par Aikido Intel, qui analyse les journaux de modifications (changelogs) et l'historique des commits en amont pour détecter les vulnérabilités corrigées silencieusement sans identifiant CVE. Là où la plupart de ces outils remédient à un CVE en mettant à niveau le paquet affecté vers une version plus récente, Aikido privilégie l'utilisation de correctifs rétroportés (backported patches), en extrayant le correctif d'une version récente pour l'appliquer à celle que vous utilisez déjà. Cela maintient la modification minime, garantissant que l'image se comporte comme votre application l'attend, tout en réduisant la dette de mise à niveau qui s'accumule lorsque vous êtes poussé vers de nouvelles versions. 

Lorsqu'un rétroportage propre n'est pas possible, Aikido met à niveau ou reconstruit le composant à la place. Aikido associe également chaque conteneur à sa base d'origine et vous oriente vers le remplacement qui minimise le risque au niveau de toute l'organisation, avec plus de 100 correctifs étudiés et testés quotidiennement, ainsi qu'une couverture au niveau du système d'exploitation encadrée par un SLA de création de correctifs défini.

Les vulnérabilités des paquets au niveau applicatif dans des écosystèmes tels que npm, PyPI, Maven et Go sont corrigées directement via Aikido Libraries. L'ensemble s'intègre au sein d'une plateforme de sécurité logicielle mature qui couvre également le SAST, le DAST, le SCA, la détection de secrets, la posture cloud et l'analyse d'images de conteneurs, garantissant qu'une détection d'image s'accompagne du contexte de code et cloud associé.

L'équipe à l'origine de ces images a rejoint l'entreprise suite à l'acquisition de Root, la société responsable de SlimToolkit (anciennement DockerSlim), l'un des outils de durcissement d'images open source les plus utilisés, comptant plus de 23 000 étoiles sur GitHub et une capacité démontrée à réduire la taille des images jusqu'à 30 fois. La création et le durcissement d'images de conteneurs sont les domaines fondateurs de cette équipe, et l'outil reste gratuit et ouvert à tous.

‍Idéal pour : les équipes d'entreprise qui souhaitent éliminer les vulnérabilités critiques et élevées de leurs images de base et dépendances actuelles, sans avoir à migrer vers une nouvelle distribution ou à enchaîner des mises à niveau successives.

{{walkthrough}}

Chainguard

Chainguard épure une image et la reconstruit à partir de Wolfi, sa propre distribution Linux. Les images durcies intègrent des SBOM et des signatures Sigstore, sont reconstruites à partir de l'amont et bénéficient d'un SLA de remédiation publié de 7 jours pour les CVE critiques et de 14 jours pour le reste. Chainguard propose des offres pour la conformité fédérale, incluant des variantes validées FIPS, des modules cryptographiques validés NIST et un durcissement conforme aux directives DISA STIG.

Le coût réside dans la migration et l'enfermement propriétaire (lock-in). Adopter Chainguard implique de basculer vos services vers son catalogue et sa distribution Wolfi, et si votre application dépend d'un élément supprimé par Chainguard, elle ne fonctionnera plus. Ce modèle vous impose également une mise à niveau continue, transformant chaque correctif en une nouvelle image à tester à nouveau. Fixer une image à un condensé (digest) pour assurer la reproductibilité empêche l'application des correctifs, ce qui va à l'encontre de la raison pour laquelle vous l'avez adopté. 

Chainguard fait également vieillir les versions antérieures assez rapidement. Les versions de paquets autres que la plus récente sont conservées environ 12 mois, et sa couverture de fin de vie est limitée à six mois, s'appliquant uniquement aux paquets de dépendances sous-jacents à une image plutôt qu'au composant principal. Il en résulte une pression constante pour passer aux versions plus récentes, ce qui génère une surcharge opérationnelle pour les équipes qui préfèrent stabiliser une version.

Idéal pour : les équipes capables de s'engager envers la distribution et le rythme de publication d'un seul fournisseur. Déconseillé aux équipes qui doivent conserver leurs images et versions de base ou figer une version sans subir de tests constants.

Docker Hardened Images

Le catalogue d'images durcies de Docker a été lancé en mai 2025 et est devenu open source sous licence Apache 2.0 en décembre 2025. DHI mérite d'être pris en compte par les équipes utilisant déjà Docker Hub. Son objectif est de fournir des images de base présentant un nombre quasi nul de CVE, construites sur des fondations standard Alpine et Debian, et livrées avec des SBOM signés, une traçabilité SLSA Build Level 3 et des attestations VEX. DHI Select ajoute un SLA de 7 jours pour les CVE critiques ainsi que des variantes FIPS et STIG. DHI Enterprise introduit des options de personnalisation, avec la disponibilité d'une assistance prolongée (ELS) en option payante jusqu'à cinq ans après la fin de vie en amont.

DHI étant une solution plus récente, son historique sur des charges de travail lourdement réglementées est plus restreint. Son catalogue est moins étendu que celui des autres options de cette liste et sa couverture ne s'étend pas au-delà des images de conteneurs.

Idéal pour : les équipes qui préfèrent adopter des images durcies au sein de leur flux de travail Docker existant, mais non adaptées à celles dont les bases se situent en dehors du catalogue de Docker, qui reste plus restreint que celui des autres outils présentés ici.

Rapidfort

RapidFort propose un catalogue d'images durcies construites sur des distributions LTS standard telles que Alpine, Debian, Ubuntu et Red Hat, plutôt que sur une distribution de conteneurs propriétaire. Cette offre est fortement orientée vers les charges de travail fédérales et de défense, incluant la conformité FedRAMP, FISMA et CMMC. 

Au-delà du catalogue, RapidFort propose un profilage à l'exécution (runtime) pour affiner encore les images. Son profileur observe quels paquets et binaires s'exécutent réellement en production, génère une nomenclature d'exécution (RBOM) et supprime tout ce qui n'a pas été observé. Cette méthode permet d'alléger une image, mais elle reste fragile car le profileur ne conserve que ce qu'il observe : tout ce qui n'a pas été sollicité pendant le profilage risque d'être supprimé. Chaque nouvelle fonctionnalité, dépendance ou modification de configuration implique un nouveau profilage et de nouveaux tests avant le déploiement.

Idéal pour : les prestataires fédéraux, les fournisseurs du secteur de la défense et les équipes réglementées déjà engagées dans la conformité FIPS et STIG. Toutefois, les équipes qui optent pour l'optimisation approfondie par profilage à l'exécution doivent savoir que cette approche est fragile et nécessite un nouveau profilage à chaque modification de l'application.

Echo

Echo est un nouvel arrivant sur le marché, qui propose une fabrique d'images pilotée par l'IA compilant des images de conteneurs à partir du code source, en n'incluant que les composants dont une application a réellement besoin. Ses agents surveillent les flux de vulnérabilités et régénèrent les images au fur et à mesure que de nouveaux CVE apparaissent en amont. Les images obtenues visent zéro CVE et constituent des substituts prêts à l'emploi (drop-in) pour les images de base Docker standard. Elles sont validées FIPS et alignées sur les normes STIG pour les équipes qui en ont besoin, et Echo se positionne comme une alternative directe à Chainguard et Docker Hardened Images dans le domaine des images de base reconstruites. 

Là où Echo est le moins éprouvé, c'est sur la fiabilité opérationnelle de son pipeline de reconstruction et de correction piloté par l'IA dans le cadre de charges de travail réglementées et à l'échelle de la production. 

Idéal pour : les équipes qui recherchent une stratégie d'images de base reconstruites. Cependant, les équipes doivent être prêtes à évaluer un fournisseur en série A disposant d'un catalogue plus restreint et d'un historique opérationnel plus court.

Minimus

Minimus a été fondée en octobre 2022 par des cofondateurs ayant créé auparavant Twistlock (acquis par Palo Alto Networks en 2019). Le produit a été lancé publiquement lors de la conférence RSAC en avril 2025, son historique est donc encore très récent. Les images Minimus sont construites à partir du code source en amont avec uniquement les logiciels nécessaires pour exécuter une application. Leur pipeline surveille les projets open source, reconstruit les paquets lorsque les mainteneurs publient de nouvelles versions et pousse de nouvelles images après des tests automatisés et une signature. Leur catalogue publié compte plus de 1 200 images renforcées, et ils prennent en charge les bases de référence de conformité FIPS, CIS, NIST et STIG.

Adopter Minimus implique de migrer vos services vers ses images. Comme le modèle reconstruit à partir de l'amont et livre de nouvelles versions au lieu d'rétro-porter (backporter) les correctifs sur la version que vous avez épinglée (pinned), rester à jour signifie passer d'un « digest » à l'autre. Chaque correctif représente une nouvelle image à tester et à approuver, et le fait d'épingler une version pour des raisons de stabilité retarde l'application des correctifs. L'historique est également court, le produit n'étant public que depuis avril 2025, et comme les autres acteurs ici, la solution s'arrête à l'image de base et ne couvre pas le reste de votre pile.

Idéal pour : les équipes qui souhaitent des images construites à partir du code source et qui peuvent exécuter un pipeline de reconstruction et de redéploiement au rythme des nouveaux « digests ». En revanche, cela ne convient pas aux équipes qui ont besoin de conserver une version fixe tout en recevant les correctifs de sécurité, sans avoir à effectuer de mise à jour incrémentielle ni de nouveau test à chaque correctif.

Wiz

Wiz assure le renforcement (hardening) via WizOS, son propre catalogue d'images de base minimales construites à partir du code source et affichant un nombre très faible de CVE connus, livrées avec des SBOM, une provenance vérifiable et un SLA de correction de 7 jours pour les failles critiques et de 14 jours pour les failles élevées et moyennes. Des variantes durcies FIPS et STIG sont disponibles pour les charges de travail réglementées. WizOS s'intègre au sein de la plateforme de sécurité cloud Wiz, ce qui permet d'afficher une image de base vulnérable aux côtés des signaux cloud, code et runtime associés, avec des recommandations de remplacement par un équivalent WizOS, l'application de contrôles d'admission (admission-controller) et des mises à niveau en un clic dans l'IDE.

Les contreparties résident dans le périmètre et le modèle. Tout comme Chainguard, WizOS vous oblige à migrer vos services vers les images de Wiz plutôt qu'à rétro-porter les correctifs dans la version que vous utilisez déjà ; chaque correctif constitue donc une nouvelle image à tester et à approuver. Le catalogue est également plus récent et plus restreint que celui des spécialistes, ayant débuté avec des images axées sur Go pour s'élargir ensuite. Par conséquent, un équivalent durci pour votre base exacte n'est pas garanti. 

Idéal pour : les équipes utilisant déjà Wiz qui souhaitent disposer d'images de base renforcées mises en avant et appliquées au sein de la même plateforme que celle qu'elles utilisent pour la sécurité du cloud et du runtime. Cette solution ne convient pas aux équipes dont les bases se situent en dehors du catalogue, encore en expansion, de WizOS.