Les meilleures alternatives à Minimus en 2026

Minimus va cesser ses activités, et son registre (reg.mini.dev) sera désactivé le 22 octobre 2026, à l'issue d'une période de maintenance de 60 jours qui a débuté 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 disposez d'un délai pour effectuer la migration.

Même avant cela, son modèle ne convenait pas à tout le monde. Adopter Minimus impliquait de passer à ses images, qui reposaient sur sa propre distribution (MinimOS), et de s'aligner sur son rythme de publication. Et comme ces images ne comportaient pas de distribution (ni shell ni gestionnaire de paquets), tout élément de votre configuration dont Minimus avait supprimé la prise en charge devait être repensé. 

Il existe des solutions alternatives qui permettent d'éviter cela. Au lieu de vous faire passer à une distribution d'un fournisseur, elles appliquent des correctifs à l'image de base que vous utilisez déjà, et lorsque vous avez verrouillé une version, elles y intègrent les correctifs par rétroportage plutôt que de vous obliger à passer à une version plus récente. Cet article explique la marche à suivre.

Cet article vous explique où aller ensuite et ce qu’il faut prendre en compte pour éviter de devoir migrer à nouveau dans un an. Nous comparons :

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

TL;DR

Notre coup de cœur est Aikido Security. Au lieu de vous faire migrer vers une nouvelle distribution, il applique des correctifs à l’image de base que vous utilisez déjà, ce qui évite toute interruption de service, et le correctif est intégré sous forme de pull request que vous n’avez à merge qu’une seule fois. Par la suite, Aikido continue de reconstruire l’image à mesure que de nouvelles vulnérabilités sont corrigées et vous alerte lorsqu’une nouvelle version est disponible. Chaque image est un remplacement direct doté d'une provenance certifiée par l'SBOM, VEX et SLSA, couvrant les CVE au niveau du système d'exploitation dans le cadre d'un SLA défini pour la création de correctifs. Elle continue d'appliquer des correctifs aux versions même après leur fin de vie, et s'intègre à une plateforme qui couvre également SAST, DAST, SCA, détection de secrets et 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 a bien fait

Minimus a créé ses images « distroless » à partir du code source sur sa propre distribution, MinimOS, en n'incluant que ce dont une application avait besoin pour fonctionner, sans aucun des outils de shell ni de gestion de paquets qui élargissent la surface d'attaque. Le catalogue comptait plus de 1 200 images conformes aux normes FIPS, CIS, NIST et STIG, et en juin 2026, l'ensemble est devenu gratuit, sans obligation d'inscription. Pour les images compatibles telles quelles, l’adoption se résumait à une simple modification d’une ligne dans un Dockerfile ou un manifeste.

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

Le catalogue Minimus va fermer et les images Minimus ne seront plus mises à jour après le 22 octobre. Tout ce que vous avez déjà téléchargé continuera de fonctionner, mais les CVE s'accumuleront sans qu'aucun remplacement corrigé ne soit proposé.

Si vous souhaitez que vos images ne présentent aucune vulnérabilité, vous êtes désormais contraints de procéder à une migration coûteuse hors de Minimus. Quitter la plateforme implique de remplacer chaque image Minimus hébergeant l’un de vos services par une autre source, puis de procéder à de nouveaux tests. La migration elle-même étant désormais inévitable, il vaut mieux choisir une solution de remplacement qui ne vous enferme pas dans sa propre distribution et son propre rythme de mise à jour, sinon vous devrez recommencer cette opération dès que le fournisseur changera de cap. 

Et même si la migration vers cette distribution ne posait pas de problème, le modèle était fragile. Minimus reconstruisait les images à partir des sources en amont et publiait de nouvelles versions ; ainsi, même lorsque le numéro de version ne changeait pas, une image corrigée impliquait un nouveau digest. Pour rester à jour, il fallait effectuer une mise à jour vers chacune d’entre elles, et chaque mise à jour nécessitait de tester et de valider à nouveau une nouvelle image.

La mise à jour automatique fonctionnait bien, jusqu'à ce qu'elle ne fonctionne plus. Par exemple, une vulnérabilité CVE affectait une bibliothèque de votre image et le correctif était inclus dans la version 2.1, mais un autre paquet dont vous dépendiez n'acceptait que les versions antérieures à la 2.0. La solution la plus raisonnable consistait à verrouiller cette dépendance sur une version précise, mais cela vous empêchait alors de passer à une version plus récente, et l'image ne faisait qu'accumuler les vulnérabilités. 

Ce qu'il faut rechercher dans une alternative à Minimus

• Un vaste catalogue de solutions prêtes à l'emploi : quelle part des bases que vous exploitez réellement couvre-t-il déjà ? Recherchez une véritable diversité couvrant Debian, Ubuntu et Alpine, aussi bien sur amd64 que sur arm64.
• Provenance vérifiable : une signature « SBOM », un document VEX et une provenance SLSA sont joints à chaque pull, ce qui vous permet de prouver le contenu d'une image et la manière dont elle a été créée.
• Sécurité après la fin de vie : application de correctifs qui se poursuit même après l'abandon de la distribution en amont, ce qui vous permet de conserver une version de base plus ancienne sans en héberger les vulnérabilités CVE connues (critiques et à risque élevé).
• Couverture au-delà de l'image de base : recherchez un outil qui couvre également vos dépendances, votre code (SAST), votre infrastructure en tant que code (IaC), vos secrets et votre environnement d'exécution, afin que chaque résultat s'accompagne de son contexte.
• Preuves de conformité par défaut : référentiels FIPS, CIS, NIST et STIG, avec des éléments d'audit générés automatiquement.
• Un fournisseur sur lequel vous pouvez compter : évaluez ses antécédents, ses résultats passés et le montant que vous perdriez si cela se reproduisait.

Les meilleures alternatives à Minimus

Aikido Security

Alors que Minimus vous faisait passer à sa propre distribution, « Aikido » applique des correctifs à l’image de base que vous utilisez déjà. «Aikido Images » est un répertoire regroupant plus de 2 000 images prêtes à l’emploi, dans lesquelles les vulnérabilités critiques et élevées connues de l’image de base ont déjà été corrigées. Ces images sont reconstruites, corrigées, allégées et renforcées lors de leur compilation ; vous bénéficiez ainsi d’un traitement complet, d’une surface d’attaque réduite et de paramètres par défaut verrouillés, sur l’image de base que vous utilisez déjà.

‍

Pour exemple, debian:bookworm fournit une version corrigée glib2.0 pour la vulnérabilité CVE-2025-4373, que Debian a corrigée dans Trixie et Sid, mais pas dans Bookworm. La variante « Aikido Images » de debian:bookworm comporte le correctif glib2.0 et voilà, c'est terminé.

Comme ce swap est un remplacement direct proposé par AutoFix sous forme de pull request, le correctif est appliqué dès que vous exécutez la commande ` merge`, et chaque pull provenant de docker.aikido.io est accompagné d’une provenance SBOM, VEX et SLSA. Aikido continue à corriger les versions même après que l’amont les ait abandonnées, y compris celles qui ont atteint leur fin de vie, ce qui vous permet de rester sur une base plus ancienne sans en subir les failles de sécurité connues et sans être contraint de passer à une version plus récente pour rester protégé.

L'équipe à l'origine de ces images a rejoint Aikido à la suite du rachat de Root, la société créatrice de SlimToolkit (anciennement DockerSlim), l'un des outils open source les plus utilisés pour le renforcement de la sécurité des images, avec plus de 23 000 étoiles sur GitHub et une capacité avérée à réduire la taille des images jusqu'à 30 fois. Les clients existants de Root ont été migrés vers les images et bibliothèques Aikido , et Aikido peut vous aider à abandonner Minimus de la même manière. 

Aikido a levé 85 millions de dollars et compte plus de 150 000 équipes parmi ses utilisateurs, notamment des entreprises telles que Revolut, Belfius, la Premier League, Deel et SoundCloud, ainsi que Visma, qui gère Aikido pour plus de 200 sociétés de son portefeuille et 6 000 développeurs. Une entreprise disposant de suffisamment de liquidités pour acquérir Root dans son intégralité n’est pas du genre à fermer son registre.

Une part croissante des correctifs réels ne se voit jamais attribuer de numéro CVE. La veille continue menée par Aikido s'appuie en partie sur Aikido Intel, qui analyse les journaux de modifications et l'historique des commits en amont afin de détecter les vulnérabilités qui ont été corrigées discrètement sans numéro CVE. Et alors que la plupart de ces outils corrigent un CVE en mettant à niveau le paquet concerné vers une version plus récente, Aikido recourt massivement aux correctifs rétroportés : il récupère le correctif de la version plus récente et l’applique à la version que vous utilisez déjà. Cela permet de limiter l’ampleur de la modification, de sorte que l’image a plus de chances de se comporter comme votre application l’attend, tout en réduisant la « dette de mise à niveau » qui s’accumule lorsque vous êtes contraint de passer à de nouvelles versions.

Lorsqu'un backport propre n'est pas possible, Aikido procède à la mise à jour ou à la recompilation du composant. La solution établit également une correspondance entre chaque conteneur et la base dont il hérite, et vous oriente vers le remplacement qui présente le moins de risques pour l'ensemble de l'organisation, grâce à plus de 100 correctifs étudiés et testés quotidiennement, ainsi qu'à une couverture au niveau du système d'exploitation dans le cadre d'un SLA défini pour la création de correctifs.

Les vulnérabilités des paquets au niveau des applications, présentes dans des écosystèmes tels que npm, PyPI, Maven et Go, sont corrigées directement via les bibliothèques «Aikido ». L’ensemble s’inscrit dans une plateforme de sécurité logicielle éprouvée qui couvre également SAST, DAST, SCA, détection de secrets, cloud ainsi que analyse d’images de conteneurs. Ainsi, la détection d’une image s’accompagne du code et du contexte cloud qui s’y rapportent.

Idéal pour : les équipes qui souhaitent éliminer les vulnérabilités des images de base et des dépendances qu'elles utilisent déjà, sans pour autant migrer vers une distribution fournie par un éditeur.

{{walkthrough}}

Chainguard

Chainguard décompose une image et la reconstruit à partir de Wolfi, sa propre distribution Linux. Chaque image est fournie avec un fichier « SBOM » signé et des signatures Sigstore, et l'entreprise publie un SLA de correction de 7 jours pour les CVE critiques et de 14 jours pour toutes les autres vulnérabilités. Des options conformes aux normes fédérales sont également disponibles, avec des variantes validées FIPS et un renforcement de sécurité conforme aux STIG de la DISA.

Le prix à payer, c’est la migration et le verrouillage. Adopter Chainguard implique de transférer vos services vers son catalogue et Wolfi, et si votre application dépendait d’un élément supprimé par Chainguard , elle cessera de fonctionner. Ce modèle vous oblige à suivre le rythme des mises à jour : chaque correction est publiée sous la forme d’un nouveau digest que vous devez retester et approuver à nouveau, et le fait de vous verrouiller sur un digest pour garantir la reproductibilité empêche purement et simplement les correctifs de vous parvenir. 

Chainguard de plus, les versions plus anciennes sont rapidement retirées. Les paquets qui ne sont pas les plus récents sont conservés pendant environ 12 mois, et leur période de grâce de fin de vie dure six mois ; celle-ci ne couvre que les paquets de dépendances d’une image, et non le composant principal, et ne relève pas du SLA CVE habituel. Tout ce qui est extrait du dépôt général Wolfi OSS ne relève pas du SLA, l’engagement FIPS ne s’étend pas aux versions personnalisées, et Chainguard ne vous indique pas le contenu d’une image au niveau CVE ; sa propre documentation vous renvoie donc vers Trivy, Grype, Snyk ou Docker Scout pour effectuer une analyse. 

Idéal pour : les équipes capables de s'aligner sur le cycle de distribution et la cadence d'un seul fournisseur. Ne convient pas aux équipes qui doivent maintenir une base ou une version stable sans avoir à effectuer de nouveaux tests en permanence.

Pour en savoir plus, consultez notre liste complète des alternatives à « Chainguard ».

Docker Hardened Images

Le catalogue sécurisé de Docker a été lancé en mai 2025 et est devenu 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 qui utilisent déjà Docker Hub. Il vise à fournir des images présentant un nombre de CVE quasi nul sur des bases Alpine et Debian standard, sans nécessiter l’adoption d’une distribution propriétaire, et fournit des SBOM signées ainsi que des attestations VEX. DHI Select ajoute un SLA de 7 jours pour les CVE critiques ainsi que des variantes FIPS et STIG, tandis que DHI Enterprise offre des options de personnalisation avec une prise en charge étendue 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 complet que celui des acteurs établis ; son historique de performance dans des environnements fortement réglementés est donc plus court, et il n’est pas garanti qu’une version renforcée correspondant exactement à votre base soit disponible. La couverture se limite également à l’image, sans rien pour votre code, vos dépendances, votre infrastructure en tant que code (IaC) ou vos secrets. De plus, DHI corrige les vulnérabilités par « rolling forward » : un correctif arrive sous la forme d’une nouvelle version ou d’un résumé que vous devez retester, et le « pinning » pour des raisons de stabilité retarde 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

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 qui souhaitent mettre en place une stratégie d'images de base développées en interne et qui sont prêtes à assumer le risque lié au fait qu'un fournisseur de série A, dont l'expérience est encore limitée, gère le pipeline dont dépendent leurs images.

FAQ