Principales alternatives à Minimus en 2026

Mise à jour, 27 août 2026 : Echo a acquis les actifs de Minimus et se positionne comme la voie de migration pour les clients de Minimus. Le registre fermant toujours ses portes le 22 octobre, si vous utilisez des images Minimus, vous devez impérativement migrer. Passer à Echo signifie adopter les images et le rythme d'Echo, c'est-à-dire le même modèle de catalogue fournisseur que vous quittez. Il convient donc de peser le pour et le contre par rapport à une approche qui corrige la base que vous utilisez déjà. Plus de détails sur Echo ci-dessous.

‍

Minimus ferme ses portes et son registre (reg.mini.dev) sera mis hors ligne le 22 octobre 2026, à l'issue d'une période de maintenance de 60 jours débutée le 24 août. Les images déjà téléchargées continueront de fonctionner, mais il n'y aura plus de nouvelles mises à jour. Si vous utilisez des images Minimus, vous devez impérativement planifier votre migration.

Même avant cela, son modèle ne convenait pas à tout le monde. Adopter Minimus signifiait basculer vers ses propres images, conçues sur sa distribution (MinimOS), et dépendre de son calendrier de sortie. De plus, les images étant "distroless" (sans shell ni gestionnaire de paquets), tout élément indispensable à votre configuration que Minimus avait retiré devait être repensé. 

Il existe des alternatives qui évitent cela. Au lieu de vous imposer la distribution d'un éditeur, elles corrigent l'image de base que vous utilisez déjà et, lorsque vous avez épinglé une version, y rétroportent les correctifs ("backport") plutôt que de vous forcer à avancer. Cet article détaille les options qui s'offrent à vous.

Cet article détaille les options qui s'offrent à vous et les critères à prendre en compte pour éviter d'avoir à migrer à nouveau dans un an. Nous comparons :

• Aikido Security
• Chainguard
• Docker Hardened Images
• RapidFort
• Echo

TL;DR

Notre premier choix est Aikido Security. Plutôt que de vous faire migrer vers une nouvelle distribution, l'outil corrige l'image de base que vous utilisez déjà, ce qui évite toute rupture. Le correctif est appliqué sous forme de pull request que vous pouvez merge en un clic. Ensuite, Aikido continue de reconstruire l'image à mesure que de nouvelles vulnérabilités sont corrigées et vous avertit lorsqu'une version plus récente est disponible. Chaque image est un remplacement direct (drop-in) incluant un SBOM, un VEX et une traçabilité SLSA, couvrant les CVE au niveau de l'OS dans le cadre d'un SLA de création de correctifs défini. L'outil poursuit les correctifs de version même après la fin de vie (EOL), le tout au sein d'une plateforme qui intègre également SAST, DAST, SCA, la détection de secrets et la posture cloud. Ayant déjà migré les clients de Root, Aikido peut vous faire quitter Minimus de la même manière.

{{cta}}

Ce que Minimus faisait bien

Minimus construisait ses images sans OS (distroless) à partir du code source sur sa propre distribution, MinimOS, en n'emportant que le strict nécessaire au fonctionnement d'une application, sans les outils de shell et de gestion de paquets qui élargissent la surface d'attaque. Le catalogue comptait plus de 1 200 images avec des bases de référence FIPS, CIS, NIST et STIG. En juin 2026, l'ensemble est devenu gratuit et sans inscription. Pour les images compatibles telles quelles, l'adoption s'est résumée à une modification d'une seule ligne dans un Dockerfile ou un manifeste.

Pourquoi vous avez besoin d'une alternative à Minimus dès maintenant

Le catalogue Minimus ferme ses portes et aucune mise à jour ne sera apportée aux images Minimus après le 22 octobre. Tout ce que vous avez récupéré continuera de fonctionner, mais les CVE s'accumuleront sans correctif de remplacement.

Si vous souhaitez conserver des images sans vulnérabilité, vous êtes contraint d'effectuer une migration coûteuse hors de Minimus. Cela implique de remplacer chaque image Minimus hébergeant l'un de vos services par une autre source et de procéder à de nouveaux tests. Cette migration est désormais incontournable ; il est donc préférable de choisir une solution de remplacement qui ne vous enferme pas dans sa propre distribution et son propre rythme, sous peine de devoir répéter l'opération dès qu'un fournisseur changera de cap. 

Et même si la migration vers sa distribution ne vous posait pas de problème, le modèle restait fragile. Minimus reconstruisait les images à partir des sources amont et publiait de nouvelles versions : ainsi, même si le numéro de version restait inchangé, une image corrigée signifiait un nouveau condensé (digest). Rester à jour impliquait d'adopter chaque nouvelle version, et chaque mise à jour représentait une nouvelle image à tester et à valider.

La mise à jour fonctionnait bien, jusqu'à un certain point. Par exemple, une CVE touchait une bibliothèque de votre image et le correctif était livré dans la version 2.1, mais un autre paquet dont vous étiez dépendant n'acceptait que les versions antérieures à 2.0. La décision raisonnable consistait à épingler cette dépendance à une version exacte, mais il devenait alors impossible de la mettre à niveau, et l'image accumulait les vulnérabilités. 

Critères de choix pour une alternative à Minimus

• Un vaste catalogue prêt à l'emploi : Combien de images de base que vous utilisez réellement prend-il déjà en charge ? Recherchez une réelle diversité sur Debian, Ubuntu et Alpine, à la fois pour amd64 et arm64.
• Traçabilité vérifiable : Un SBOM signé, un document VEX et une traçabilité SLSA associés à chaque téléchargement, pour prouver le contenu d'une image et ses conditions de construction.
• Sécurité après la fin de vie (EOL) : Un support de correction qui se poursuit après l'arrêt de la distribution amont, vous permettant de conserver une image de base plus ancienne sans subir ses CVE critiques et élevées connues.
• Couverture au-delà de l'image de base : Optez pour un outil qui analyse également vos dépendances, votre code (SAST), l'IaC, les secrets et le runtime, afin qu'une anomalie soit restituée avec son contexte global.
• Conformité native : Des bases de référence FIPS, CIS, NIST et STIG avec des rapports d'audit générés automatiquement.
• Un fournisseur pérenne sur lequel vous pouvez compter : Évaluez le soutien financier, l'historique et l'impact potentiel en cas de changement de situation.

Principales alternatives à Minimus

Aikido Security

Là où Minimus vous imposait sa propre distro, Aikido corrige directement l'image de base que vous utilisez déjà. Aikido Images est un catalogue de plus de 2 000 images de substitution (« drop-in ») où les vulnérabilités critiques et élevées connues de la base sont déjà corrigées. Ces images sont reconstruites, patchées, optimisées et durcies lors de la compilation, ce qui vous permet de bénéficier d'une prise en charge complète, d'une surface d'attaque réduite et de configurations par défaut sécurisées, tout en conservant la base que vous utilisez déjà.

‍

Pour exemple, debian:bookworm fournit un correctif glib2.0 pour la CVE-2025-4373, que Debian a corrigée dans Trixie et Sid, mais pas dans Bookworm. La variante Aikido Images de debian:bookworm intègre le correctif glib2.0 qui résout le problème.

Puisque le remplacement est une image de substitution (« drop-in ») proposée par AutoFix sous forme de pull request, le correctif est appliqué dès que vous faites un merge, et chaque pull depuis docker.aikido.io s'accompagne d'un SBOM, d'un VEX et d'une provenance SLSA. Aikido continue de patcher les versions après leur abandon par l'amont (upstream), même celles qui sont arrivées en fin de vie (EOL), ce qui vous permet de rester sur une base plus ancienne sans traîner ses failles de sécurité connues et sans être forcé de migrer vers une version plus récente pour rester couvert.

L'équipe à l'origine de ces images a rejoint Aikido suite au rachat de Root, l'entreprise qui a créé SlimToolkit (anciennement DockerSlim), l'un des outils de durcissement d'images open source les plus populaires, comptant plus de 23 000 étoiles sur GitHub et affichant une capacité avérée à réduire la taille des images jusqu'à 30 fois. Les clients actuels de Root ont été migrés vers Aikido Images et Libraries, et Aikido peut vous faire quitter Minimus de la même manière. 

Aikido a levé 85 millions de dollars et la confiance de plus de 150 000 équipes, incluant des entreprises telles que Revolut, Belfius, la Premier League, Deel et SoundCloud, ainsi que Visma, qui utilise Aikido au sein de plus de 200 entreprises de son portefeuille et auprès de 6 000 développeurs. Une entreprise financièrement solide au point de racheter Root n'est pas sur le point de fermer son registre.

Une part croissante des correctifs réels ne se voit attribuer aucun identifiant CVE. La surveillance continue d'Aikido est en partie alimentée par Aikido Intel, qui analyse les journaux des modifications (changelogs) et l'historique des commits en amont pour détecter les vulnérabilités corrigées en toute discrétion, sans CVE associée. Et là où la plupart de ces outils remédient à une CVE en mettant à niveau le paquet affecté vers une version plus récente, Aikido fait un usage intensif des correctifs rétroportés (backports), en extrayant le correctif de la version récente pour l'appliquer à celle que vous utilisez déjà. Cela permet de limiter la portée des modifications, garantissant ainsi que l'image se comportera comme votre application l'attend, tout en réduisant la dette de mise à niveau qui s'accumule lorsque l'on vous pousse vers de nouvelles versions.

Lorsqu'un rétroportage propre n'est pas possible, Aikido met plutôt à niveau ou reconstruit le composant. L'outil associe également chaque conteneur à sa base d'origine et vous indique le remplacement qui élimine le plus de risques à l'échelle de l'organisation, avec plus de 100 correctifs étudiés et testés chaque jour, ainsi qu'une couverture au niveau du système d'exploitation régie 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é.

Idéal pour : les équipes qui souhaitent éliminer les vulnérabilités de leurs images de base et de leurs dépendances actuelles, sans avoir à migrer vers la distribution d'un éditeur.

{{walkthrough}}

Chainguard

Chainguard épure une image pour la reconstruire à partir de Wolfi, sa propre distribution Linux. Chaque image est livrée avec un SBOM signé et des signatures Sigstore, et l'entreprise s'engage sur un SLA de correction de 7 jours pour les CVE critiques et de 14 jours pour le reste. Des options de niveau fédéral sont également disponibles, incluant des variantes validées FIPS et un durcissement conforme aux normes DISA STIG.

Le coût se mesure en termes de migration and de dépendance vis-à-vis d'un fournisseur (lock-in). Adopter Chainguard implique de migrer vos services vers son catalogue et vers Wolfi ; par conséquent, si votre application dépendait d'un élément supprimé par Chainguard, elle plantera. Ce modèle vous impose d'aller sans cesse de l'avant, si bien que chaque correctif prend la forme d'un nouveau digest à re-tester et à valider à nouveau. Fixer une version sur un digest pour garantir la reproductibilité vous empêche purement et simplement de recevoir les correctifs. 

Chainguard retire également rapidement le support des anciennes versions. Les paquets autres que les plus récents sont conservés environ 12 mois, et sa période de grâce en fin de vie (EOL) dure six mois, couvre uniquement les paquets de dépendances d'une image plutôt que le composant principal, et se situe en dehors du SLA CVE habituel. Tout élément extrait du dépôt OSS général de Wolfi échappe au SLA, l'engagement FIPS ne s'étend pas aux compilations personnalisées, et Chainguard ne détaille pas le contenu d'une image au niveau des CVE, ce qui amène sa propre documentation à vous orienter vers Trivy, Grype, Snyk ou Docker Scout pour effectuer vos scans. 

Idéal pour : les équipes capables de s'engager sur la distribution et le rythme d'un seul fournisseur. Déconseillé à celles qui ont besoin de figer une base ou une version sans subir de phases de tests permanentes.

Pour plus de détails, consultez notre liste complète des alternatives à Chainguard.

Docker Hardened Images

Le catalogue durci de Docker a été lancé en mai 2025 avant de devenir gratuit et open source sous licence Apache 2.0 en décembre 2025. DHI mérite d'être pris en considération par les équipes utilisant déjà Docker Hub. Son objectif est de fournir des images quasi exemptes de CVE sur des fondations standard Alpine et Debian, sans imposer l'adoption d'une distribution propriétaire, tout en proposant des SBOM signés et des attestations VEX. DHI Select y ajoute un SLA de 7 jours pour les CVE critiques ainsi que des variantes FIPS et STIG, tandis que DHI Enterprise introduit des options de personnalisation et un support étendu du cycle de vie pouvant aller jusqu'à cinq ans après la fin de vie en amont.

Le catalogue est plus récent et moins vaste que ceux des acteurs historiques, ce qui signifie que l'historique sur des charges de travail lourdement réglementées est plus limité et qu'une version durcie de votre base exacte n'est pas garantie. De plus, la couverture s'arrête à l'image et ne propose rien pour votre code, vos dépendances, votre IaC ou vos secrets. Enfin, DHI gère la remédiation en allant de l'avant : un correctif arrive sous la forme d'une nouvelle version ou d'un nouveau digest à re-tester, et figer une version pour assurer la stabilité bloque l'application du correctif.

Idéal pour : les équipes déjà présentes sur Docker Hub qui souhaitent disposer d'images sécurisées et n'ont pas besoin des normes FIPS, STIG ou d'un SLA, qui ne sont disponibles que dans les formules payantes. Ne convient pas aux équipes dont la base exacte ne figure pas dans le catalogue de Docker, qui reste encore limité.

RapidFort

RapidFort propose un catalogue d’images sécurisées basées sur des distributions LTS standard telles qu’Alpine, Debian, Ubuntu et Red Hat, plutôt que sur une distribution propriétaire. Cette gamme est destinée aux applications fédérales et de défense, avec une validation FIPS et des mesures de sécurisation conformes aux normes STIG et CIS. En plus de ce catalogue, RapidFort ajoute un profilage d’exécution : le système surveille quels paquets et binaires s’exécutent réellement en production et supprime tout ce qu’il n’a pas détecté comme étant exécuté.

C'est justement là que réside le problème de ce profilage. Il ne conserve que ce qu'il observe ; ainsi, le code qui ne s'exécute pas pendant la fenêtre de profilage peut être supprimé, puis échouer lorsqu'il s'exécute enfin en production. Les profils deviennent obsolètes lorsque l'application ou son trafic évolue ; par conséquent, tout changement significatif implique de refaire le profilage et de réexécuter les tests avant la mise en production. Et comme les autres solutions présentées ici, la couverture s'arrête au niveau de l'image, sans rien au-dessus pour votre code, vos dépendances ou votre cloud.

Idéal pour : les prestataires du gouvernement fédéral, les fournisseurs du secteur de la défense et les équipes soumises à une réglementation qui se sont déjà engagées à respecter les normes FIPS et STIG. Toutefois, les équipes qui souhaitent aller plus loin dans l'optimisation par profilage d'exécution doivent savoir que cette méthode est fragile et nécessite un nouveau profilage à chaque modification de l'application.

Echo

En août 2026, Echo a acquis les actifs de Minimus et est devenu le fournisseur vers lequel Minimus oriente ses clients. Pour une équipe utilisant Minimus, c'est la solution de moindre résistance, mais il convient de savoir exactement de quoi il s'agit. Vous migrerez vers les images d'un autre fournisseur, construites et reconstruites selon son propre calendrier, ce qui correspond précisément au modèle que l'on vous force à abandonner. Echo intègre les travaux sur l'OS de Minimus dans son propre catalogue plutôt de maintenir les images Minimus en vie, ce qui signifie que vous devrez de toute façon changer de plateforme.

Echo est un nouvel acteur du marché qui propose une « usine d’images » basée sur l’IA : celle-ci compile des images à partir de sources diverses, en n’incluant que les composants dont une application a besoin, grâce à des agents qui surveillent les flux d’informations sur les vulnérabilités et régénèrent les images dès que de nouvelles CVE sont signalées en amont. Ces images visent un niveau de vulnérabilité nul (zéro CVE), sont fournies comme des remplacements prêts à l’emploi des images Docker de base standard, et sont validées selon la norme FIPS et conformes aux STIG pour les équipes qui en ont besoin.

La question principale porte sur la maturité. Echo est une entreprise en phase de série A avec une courte expérience opérationnelle ; par conséquent, son pipeline de reconstruction et d’application de correctifs est le moins éprouvé du groupe dans le cadre de charges de travail réglementées et à l’échelle de production. De plus, son catalogue est plus restreint, ce qui signifie que la couverture des charges de travail moins courantes peut s’avérer plus limitée. Comme pour les autres solutions de cette liste, elle corrige les vulnérabilités en déployant une nouvelle image plutôt qu’en appliquant un correctif à la version que vous utilisez, et la couverture s’arrête au niveau de l’image.

Idéal pour : les équipes Minimus recherchant la migration la plus simple, acceptant d'adopter le catalogue d'un autre fournisseur et capables d'assumer le risque d'un vendeur en Série A ayant un historique limité pour gérer le pipeline dont dépendent leurs images.

FAQ