Chainguard a conçu son produit en se basant sur la réduction d'une image de conteneur à ce que votre application nécessite réellement et sa reconstruction à partir d'une base minimale. L'idée est que moins de paquets signifie moins de vulnérabilités. Pour ce faire, il maintient sa propre distribution Linux, Wolfi, ce qui est le point où le modèle commence à montrer ses limites.
Pour utiliser Chainguard, vous devez adopter ses images et vous engager à utiliser sa distribution. Si votre application dépend d’un élément que Chainguard a supprimé, elle cessera de fonctionner. Chainguard ne couvre également de manière significative que la couche des conteneurs. Son produit « Libraries » couvre trois écosystèmes au total. Il recompile les paquets Java et Python à partir du code source et corrige les vulnérabilités CVE qu’ils contiennent, tandis que JavaScript ne bénéficie que d’une protection contre les logiciels malveillants issue de cette recompilation. Le même engagement envers la distribution propriétaire s’applique.
Pour les équipes qui utilisent des logiciels qu'elles déploient depuis un certain temps, changer d'images de base est un projet de migration. Cela peut être coûteux, et se détacher d'une distribution propriétaire est plus difficile qu'il n'y paraît. C'est probablement pourquoi vous êtes sur cette page à la recherche d'alternatives.
Cet article détaille ce qu'il faut rechercher dans une alternative à Chainguard et les fournisseurs à évaluer.
TL;DR
Aikido Security est l'alternative la plus robuste à Chainguard pour les équipes qui souhaitent que les CVE soient corrigées dans la version de l'image de base qu'elles utilisent déjà, sans migrer vers une distribution propriétaire. Aikido corrige les vulnérabilités open source directement pour les dépendances d'applications et les images de base de conteneurs, en conservant votre distribution existante plutôt qu'en la remplaçant. Il bloque également les packages malveillants au moment de l'installation avant qu'ils n'atteignent l'ordinateur d'un développeur, et résout les CVE qui peuvent être mises à niveau proprement via des PR automatisées. Le résultat est une boucle de protection continue qui détecte les vulnérabilités, les corrige là où elles se trouvent et bloque les nouvelles menaces avant qu'elles n'entrent dans le pipeline. Aucune autre plateforme ne le ferme de bout en bout de cette manière.
Si vous recherchez spécifiquement des images renforcées et rien d'autre, Docker Hardened Images, Minimus, RapidFort et Echo sont les alternatives directes.
Ce que Chainguard fait bien
Les images elles-mêmes sont robustes. Chainguard les livre avec des SBOMs et des signatures Sigstore générées au moment de la construction, les reconstruit quotidiennement à partir de sources amont afin que les correctifs soient intégrés aux images de base en moins d'une journée, et publie un SLA de remédiation des CVE de 7 jours pour les critiques et de 14 jours pour toutes les autres.
L'autre domaine où Chainguard est robuste est la conformité fédérale. Ils maintiennent plus de 700 variantes d'images validées FIPS avec des modules cryptographiques validés par le NIST, une conception indépendante du noyau qui élimine le besoin traditionnel d'un hôte en mode FIPS, et un renforcement DISA STIG appliqué par défaut. Pour les équipes ciblant FedRAMP, les niveaux d'impact du DoD, ou des environnements réglementés similaires, le catalogue d'images Chainguard est un chemin rapide vers des conteneurs prêts pour la conformité.
Pourquoi les équipes recherchent des alternatives à Chainguard
Nécessite une migration complète vers le catalogue et la distribution Chainguard
Pour bénéficier du SLA de remédiation des CVE de Chainguard, vous vous engagez à utiliser leur catalogue sélectionné, leur distribution basée sur Wolfi et leurs versions de packages. L'assemblage personnalisé vous permet d'ajouter des packages, mais tout ce qui est extrait du référentiel général Wolfi OSS ne relève pas du SLA, et l'engagement FIPS ne s'étend pas aux builds personnalisés. Si vous utilisez quelque chose qui n'a pas d'équivalent Chainguard, ou si vous maintenez des packages internes personnalisés, le coût de la migration augmente et les garanties de sécurité se fragmentent.
Le cycle de mise à niveau de Chainguard ne s'arrête jamais
L'approche de Chainguard pour maintenir un faible nombre de CVE consiste à reconstruire les images à partir des sources amont chaque nuit et à livrer de nouveaux digests. Lorsqu'un correctif est intégré, vous passez à la version suivante. Cela échange une charge opérationnelle (patcher les CVE manuellement) contre une autre (gestion constante des changements sur vos images de base). Chaque nouveau digest est une image différente qui nécessite de nouveaux tests, et si votre politique de conformité exige un contrôle des changements, vous approuvez des mises à jour quotidiennement. Chainguard recommande même d'épingler un digest pour la reproductibilité, mais l'épinglage empêche les correctifs de vous parvenir, ce qui est la raison pour laquelle vous utilisiez Chainguard au départ.
Ils vous disent de scanner avec les outils d'autres fournisseurs
Chainguard construit des images renforcées, sans CVE, mais il ne vous dit pas ce qu'elles contiennent réellement au niveau des CVE, ni ce qui a changé entre les digests. Leur propre documentation guide les utilisateurs pour scanner les images Chainguard avec Trivy, Grype, Snyk ou Docker Scout, car c'est de là que proviennent les découvertes de vulnérabilités.
La correction des vulnérabilités de Library est encore plus restreinte. Le flux VEX de Chainguardpermet aux scanners de savoir quelles vulnérabilités CVE ont été corrigées, et il ne s’intègre qu’avec Grype de Anchoreet Trivy, ainsi qu’avec AWS Inspector, qui constitue la seule autre option. La prise en charge de VEX ne couvre qu’une partie de cette liste ; par conséquent, une équipe utilisant n’importe quel autre scanner continue de voir apparaître des résultats que Chainguard indique comme étant corrigés.
Fragmenté, pas une plateforme
Chainguard ne couvre qu’une petite partie de la pile de sécurité. Vous bénéficiez d’ images de base renforcées, de variantes FIPS, d’un SLA sur les paquets qu’ils sélectionnent et de SBOM pour ce qu’ils fournissent. La FAQ de Chainguardindique que la section « Libraries » couvre trois écosystèmes, Go et d’autres langages n’étant à l’étude que pour l’avenir. La correction des vulnérabilités CVE s’applique à Java et Python, tandis que JavaScript est recompilé à partir du code source pour la protection contre les logiciels malveillants et ne bénéficie d’aucune correction de vulnérabilité. Même en Java, le catalogue est restreint, avec 135 bibliothèques corrigées, contre les 1 145 qu’ Aikido a corrigées dans l’ensemble de ses écosystèmes. Tout le reste, de SAST et DAST à détection de secrets, analyse IaC, la surveillance du runtime des conteneurs et la gestion de la posture cloud , reste à votre charge et doit être résolu ailleurs.
Ce qu'il faut rechercher dans une alternative à Chainguard
Rétroportages pour les versions épinglées
Chaque correctif de CVE de Chainguard vous oblige à passer à une nouvelle image. Cela signifie de nouveaux tests, une nouvelle approbation de conformité et un nouveau déploiement pour chaque correctif. La bonne alternative devrait vous permettre d'appliquer les correctifs de sécurité à la version que vous utilisez déjà, afin qu'un correctif de sécurité ne nécessite pas un cycle de publication complet. C'est le modèle qui permet d'échapper au piège des mises à niveau. Vous maintenez la version épinglée, rétroportez le correctif de sécurité dedans, et vous vous retrouvez sans CVE connue, sans mise à niveau forcée, et sans aucun des risques de logiciels malveillants liés à la "dernière version" qui accompagnent le téléchargement du package le plus récent disponible.
Les rétroportages sont également effectués à la demande. Le programme « Chainguard » cible les vulnérabilités CVE critiques et à haut risque sur les anciennes versions, classées par ordre de priorité en fonction de la demande des clients, sans matrice de prise en charge fixe ; il vous suffit de vous adresser à votre équipe de compte pour obtenir des bibliothèques spécifiques. Les correctifs sont fournis à partir d'un dépôt distinct avec un -0.cgr.N suffixe de version ; vous pouvez ainsi remplacer les versions dans votre build et refaire des tests.
Une approche compatible avec vos images existantes
Adopter Chainguard signifie passer au catalogue de Chainguard et à la distribution Wolfi. La bonne alternative devrait fonctionner avec les images de base que vous utilisez déjà, comme celles officielles de Docker Hub, les images de fournisseurs comme Elastic ou Bitnami, et vos propres builds internes. Aikido scanne toutes ces images et applique automatiquement des attestations VEX provenant de sources comme Docker Hardened Images, de sorte que l'adoption ne nécessite pas de reconstruire votre stratégie d'images.
Couverture au-delà de l'image de base
images de base renforcées Réduisez le nombre de CVE dans la couche sous-jacente à votre application. Tout ce à quoi les attaquants ont accès se trouve au-dessus de celle-ci, à commencer par les bibliothèques open source dont votre code dépend directement. Chainguard s’est étendu aux bibliothèques, mais uniquement pour trois écosystèmes, et la correction des CVE ne couvre que Java et Python. JavaScript bénéficie d’une protection contre les logiciels malveillants grâce à une recompilation, mais rien n’est prévu pour les vulnérabilités connues ; le catalogue Java compte quant à lui 135 bibliothèques corrigées. Aikido corrige les vulnérabilités sur place dans sept écosystèmes (npm, PyPI, Maven, Go, NuGet, RubyGems et PHP), avec 1 145 bibliothèques corrigées, sur les versions exactes des paquets que votre application utilise déjà et sans nécessiter de migration vers une distribution propriétaire.
Le reste du cycle de vie du développement logiciel se situe au-dessus : SAST, IaC, détection de secrets et les signaux d'exécution. Aikido couvre ces éléments sur la même plateforme ; ainsi, une anomalie détectée dans une dépendance est enrichie par le contexte IaC et d'exécution qui l'entoure.
Meilleures alternatives à Chainguard
Aikido Security
Aikido va au-delà de Chainguard en matière de sécurité des conteneurs, en associant plus de 2 000 images de base sécurisées à l'analyse d’images de conteneurs, au triage tenant compte du VEX et à l'analyse d’accessibilité qui retrace une CVE d'un point d'entrée exposé jusqu'au chemin de code exact qu'elle affecte.
Aikido Images fournit des images de base de conteneurs sécurisées et prêtes à l'emploi qui restent sur la même distribution et version majeure que votre base existante, avec des correctifs déjà rétroportés. AutoFix ouvre une pull request qui met à jour le FROM ligne, de sorte que le correctif arrive en code review plutôt que comme un échange forcé de digest. Aikido fournit des correctifs CVE avec un SLA défini en utilisant des rétroportages et des mises à niveau sélectives, de sorte que les correctifs s'appliquent à la version que vous utilisez plutôt que de vous forcer à passer à une nouvelle version majeure. Vous maintenez la version épinglée, lui appliquez le correctif de sécurité et vous vous retrouvez sans CVE connue et sans migration forcée.
Aikido Libraries effectue la même opération pour les dépendances des applications dans sept écosystèmes (npm, PyPI, Maven, Go, NuGet, RubyGems et PHP). Une dépendance vulnérable en Go, .NET ou PHP ne bénéficie d’aucune correction de la part d’ Chainguard , et en Java, l’écart est de 135 bibliothèques contre 1 145. Lorsqu’un CVE touche une version de paquet que vous avez verrouillée, Aikido rétroporte le correctif vers cette version et le fournit sous forme de pull request, ce qui vous permet d’obtenir le correctif sans subir les changements incompatibles liés à une mise à niveau majeure.
Pour les images et les dépendances que vous préférez renforcer plutôt que de remplacer, Aikido fonctionne avec tout ce que vous utilisez déjà, y compris les images officielles de Docker Hub, les images de fournisseurs comme Elastic ou Bitnami, les images durcies de Docker et les builds internes. Toutes passent par le même workflow d'analyse d’images de conteneurs sans migration vers un catalogue spécifique à Aikido. Lorsqu'une image est livrée avec des attestations VEX, Aikido les lit et supprime automatiquement les CVEs résolues de la file d'attente active. Pour les images qui n'ont pas encore été sécurisées, Aikido associe la détection de CVE à l'analyse d’accessibilité, traçant le chemin réseau d'un point d'entrée exposé au conteneur en cours d'exécution et confirmant si le chemin de code vulnérable s'exécute réellement.
Aikido Intel détecte les packages malveillants et les vulnérabilités non divulguées avant qu'ils n'atteignent les bases de données publiques. Safe Chain utilise ce flux pour bloquer les packages malveillants au moment de l'installation, avant qu'ils n'arrivent sur l'ordinateur portable d'un développeur. Et AutoFix résout les CVEs qui peuvent être mises à niveau proprement, ouvrant des pull requests avec le correctif déjà rédigé. Avec Images et Libraries, c'est la boucle complète de la chaîne d'approvisionnement qui est fermée, de l'ordinateur portable du développeur au registre jusqu'au conteneur en cours d'exécution.
Et Aikido est une plate-forme complète de sécurité logicielle couvrant l'ensemble du SDLC, de sorte que la même plate-forme qui corrige vos images de base exécute également le SAST sur votre code d'application, le SCA sur vos dépendances, les contrôles IaC, la détection de secrets, la gestion de la posture cloud et la protection en temps d’exécution. Les résultats de ces domaines partagent un contexte, de sorte qu'une vulnérabilité dans une dépendance de conteneur est une priorité différente si l'IaC qui l'entoure expose le conteneur à internet ou si la télémétrie d'exécution montre que le chemin de code affecté s'exécute réellement.
Pour un aperçu plus détaillé de la comparaison d'Aikido, consultez notre comparaison directe avec Chainguard.
Idéal pour : les équipes d'ingénierie qui souhaitent que les CVEs soient corrigées dans l'image de base et les dépendances qu'elles utilisent déjà, sans migrer vers une distribution propriétaire.
{{cta}}
Rapidfort
RapidFort propose des images de conteneurs avec un nombre de CVEs quasi nul, sélectionnées, soutenues par la validation FIPS et le durcissement STIG et CIS. Leur approche consiste à supprimer les packages et composants qu'une application n'utilise pas réellement en temps d'exécution, en se basant sur le comportement observé en production. L'argument qui la distingue est que les images de RapidFort sont basées sur des distributions LTS standard comme Alpine, Debian, Ubuntu et Red Hat plutôt que sur une distribution de conteneurs propriétaire. Ainsi, les équipes qui préfèrent ne pas s'engager spécifiquement envers Wolfi n'ont pas à le faire. Le catalogue compte plus de 25 000 images et est fortement orienté vers les charges de travail fédérales et de défense, y compris FedRAMP, FISMA et CMMC.
Ce que RapidFort ajoute en plus des images elles-mêmes est le profilage en temps d'exécution. Son composant Profiler observe quels packages et binaires s'exécutent réellement en production, génère une nomenclature d'exécution (RBOM) et utilise ces données pour supprimer les composants inutilisés de l'image.
La limitation est que RapidFort, comme Chainguard, est un produit axé sur les conteneurs. Il n'y a pas de SAST pour le code d'application, pas d'analyse des dépendances du code source avant la création des images, pas d'analyse IaC, pas de détection de secrets et pas de gestion de la posture cloud. Vous achetez toujours des outils distincts pour le reste du cycle de vie du développement logiciel. Le profilage en temps d'exécution est également une intégration plus lourde que les approches basées uniquement sur les images, car vous devez exécuter des charges de travail sous le Profiler pour générer les données d'exécution dont dépend le durcissement.
Idéal pour : les contractants fédéraux, les fournisseurs de défense et les équipes réglementées déjà engagées dans la conformité FIPS et STIG qui souhaitent un résultat de type Chainguard sans adopter une distribution propriétaire.
Echo
Echo est un nouvel entrant, dont l'argument est une usine d'images basée sur l'IA qui compile des images de conteneurs à partir du code source, 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 à mesure que de nouvelles CVEs arrivent en amont. Les images résultantes visent zéro CVE et sont livrées comme des remplacements directs pour les images de base Docker standard.
Les images sont validées FIPS et alignées 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 le bilan opérationnel du pipeline de reconstruction et de correction basé sur l'IA sous des charges de travail réglementées et à l'échelle de la production.
Idéal pour : les équipes qui souhaitent une stratégie d'images de base reconstruites et sont à l'aise avec l'évaluation d'un fournisseur de série A avec un catalogue plus petit et un historique opérationnel plus court.
Minimus
Minimus a été fondée en octobre 2022 par des co-fondateurs qui avaient précédemment créé Twistlock (acquise par Palo Alto Networks en 2019). Le produit lui-même a été lancé publiquement à la RSAC en avril 2025, donc son historique est encore assez récent. Les images Minimus sont construites à partir de la source amont avec seulement le logiciel minimal nécessaire pour exécuter une application. Leur pipeline surveille en permanence les projets open source, reconstruit les packages lorsque les mainteneurs publient de nouvelles versions, et pousse de nouvelles images quotidiennement après des tests automatisés et la signature. Leur catalogue publié compte plus de 1 200 images durcies, et ils prennent en charge les bases de conformité FIPS, CIS, NIST et STIG.
Le mouvement de positionnement notable est qu'en juin 2026, Minimus a ouvert l'intégralité de son catalogue gratuitement et sans inscription. L'entreprise l'a présenté comme une réponse à la découverte de CVEs basée sur l'IA qui dépasse la remédiation. La réduction de la friction est réelle pour les acheteurs, et l'évaluation ne coûte rien. Comme Chainguard et les autres dans cette catégorie, Minimus est un produit d'images de base et ne couvre pas le reste de la pile de sécurité. Les remplacements directs via des modifications de Dockerfile d'une seule ligne sont le chemin de migration, ce qui est à peu près comparable à ce que propose Chainguard.
Idéal pour : les équipes qui souhaitent un catalogue d'images minimales gratuites, construites à partir de la source, et sont à l'aise avec un fournisseur dont le bilan de production se mesure encore en mois.
Docker Hardened Images
Le propre catalogue d'images durcies de Docker a été lancé en mai 2025 et est devenu gratuit et open source sous Apache 2.0 en décembre 2025. DHI est l'alternative à Chainguard la plus naturelle pour les équipes utilisant déjà Docker Hub. Il fournit des images de base avec un nombre de CVEs quasi nul, construites sur des bases Alpine et Debian standard, livrées avec des SBOMs signées, une provenance SLSA Build Level 3 et des attestations VEX, et est disponible dans un niveau communautaire gratuit couvrant l'intégralité du catalogue. DHI Select ajoute un SLA de 7 jours pour les CVEs critiques et les variantes FIPS et STIG. DHI Enterprise ajoute une personnalisation illimitée en plus de cela, avec un support de cycle de vie étendu disponible en tant qu'add-on payant jusqu'à cinq ans après la fin de vie en amont.
L'argument en faveur de DHI par rapport à Chainguard est la friction. Le catalogue compte plus de 1 000 images, les bases Alpine et Debian, et le workflow se trouve là où la plupart des équipes sont déjà. Les attestations VEX sont conçues pour fonctionner avec les scanners que vous utilisez déjà, avec des intégrations documentées avec les principaux scanners de conteneurs, y compris Aikido. L'argument contre est que le catalogue de Chainguard est plus mature, puisqu'il existe depuis 2021, et que Custom Assembly de Chainguard offre un contrôle plus granulaire au niveau des packages que le modèle de personnalisation de DHI. DHI est également plus récent, donc son historique sous des charges de travail fortement réglementées est plus court.
Idéal pour : les équipes qui préfèrent adopter des images durcies au sein de leur workflow Docker existant plutôt que de migrer vers un nouveau catalogue d'images et une nouvelle distribution.
Autres outils à connaître
Quelques options adjacentes ne correspondent pas au cadre des images durcies mais pourraient être sur votre radar. Seal Security corrige les vulnérabilités sur place à travers les dépendances d'application, les packages OS et les images de base de conteneurs, avec un accent sur les équipes qui ne peuvent pas se permettre des mises à niveau forcées. Ils sont principalement connus pour la correction des dépendances d'application et des packages OS, et leur catalogue d'images de base est plus récent et plus restreint que celui de Chainguard. Wiz est une plate-forme de protection des applications cloud natives qui a récemment ajouté WizOS, sa propre offre d'images durcies, bien que la valeur d'achat de Wiz réside davantage dans le graphique de sécurité cloud plus large que dans les images elles-mêmes. HeroDevs vend du support illimité (Never-Ending Support) pour les logiciels open source en fin de vie, comblant le vide lorsqu'un framework dont vous dépendez est devenu obsolète et qu'aucune image durcie ne corrigera la dépendance sous-jacente. Depthfirst est une plate-forme de sécurité native de l'IA axée sur le triage plutôt que sur les images durcies, utilisant des agents IA pour déterminer quelles vulnérabilités sont réellement exploitables dans votre codebase.
