Principais alternativas ao Minimus em 2026

Atualização, 27 de agosto de 2026: A Echo adquiriu os ativos da Minimus e está a posicionar-se como o caminho de migração para os clientes da Minimus. O registry continua a encerrar a 22 de outubro, portanto, se executa imagens da Minimus, ainda tem de migrar. Mudar para a Echo significa transitar para as imagens e cadência da Echo, o mesmo modelo de catálogo de fornecedor que está a deixar, pelo que vale a pena ponderar em comparação com uma abordagem que corrige a base que já executa. Mais abaixo sobre a Echo.

‍

O Minimus vai encerrar e o seu registo (reg.mini.dev) ficará inativo a 22 de outubro de 2026, após um período de manutenção de 60 dias que começou a 24 de agosto. As imagens já descarregadas continuarão a funcionar, mas não haverá novas atualizações. Se utiliza imagens do Minimus, tem um prazo limite para efetuar a migração.

Mesmo antes disto, o seu modelo não funcionava para todos. Adotar o Minimus significava transitar para as suas imagens, que eram construídas sobre a sua própria distribuição (MinimOS), e depender do seu ritmo de lançamentos. E, dado que as imagens não têm sistema operativo base tradicional (sem shell ou gestor de pacotes), qualquer elemento de que a sua configuração dependesse e que o Minimus tivesse removido tinha de ser refeito. 

Existem alternativas que evitam isto. Em vez de o obrigarem a migrar para a distribuição de um fornecedor, corrigem a imagem base que já utiliza e, nos casos em que fixou uma versão, aplicam as correções necessárias (backport) diretamente nessa versão, em vez de o forçarem a avançar. Este artigo aborda os passos seguintes.

Este artigo aborda os passos seguintes e o que deve procurar para não ter de migrar novamente daqui a um ano. Comparamos:

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

TL;DR

A nossa principal escolha é a Aikido Security. Em vez de o migrar para uma nova distribuição, aplica patches à imagem base que já utiliza, para que nada se corrompa, e a correção surge como um pull request que une apenas uma vez. Depois disso, o Aikido continua a reconstruir a imagem à medida que novas vulnerabilidades são corrigidas e alerta-o quando uma build mais recente estiver disponível. Cada imagem é uma substituição direta com um SBOM, VEX e proveniência SLSA, cobrindo CVEs ao nível do SO sob um SLA de criação de patches definido. Continua a aplicar patches a versões mesmo após o fim de vida, e integra-se numa plataforma que também cobre SAST, DAST, SCA, detecção de segredos e postura de cloud. Tendo já migrado os clientes da Root, o Aikido pode retirá-lo do Minimus da mesma forma.

{{cta}}

O que o Minimus fazia bem

O Minimus construiu as suas imagens sem sistema operativo (distroless) a partir do código-fonte na sua própria distribuição, o MinimOS, transportando apenas o estritamente necessário para uma aplicação correr e nenhuma das ferramentas de shell e gestores de pacotes que alargam a superfície de ataque. O catálogo contava com mais de 1.200 imagens com linhas de base FIPS, CIS, NIST e STIG, e em junho de 2026 todo o projeto passou a ser gratuito e sem registo. Para imagens que encaixavam tal e qual, a adoção consistiu numa alteração de uma única linha num Dockerfile ou manifesto.

Porque precisa agora de uma alternativa ao Minimus

O catálogo do Minimus vai ser encerrado e deixarão de existir atualizações para as imagens do Minimus após 22 de outubro. Tudo o que retirou continua a funcionar, mas as CVEs vão acumular-se sem que cheguem substituições com patches.

Se quer manter as suas imagens livres de vulnerabilidades, é agora forçado a realizar uma migração dispendiosa para fora do Minimus. Sair significa substituir cada imagem do Minimus que aloja um dos seus serviços por outra fonte e voltar a testar. A migração em si é inevitável agora, pelo que vale a pena escolher um substituto que não o prenda à respetiva distribuição e cadência, ou voltará a passar pelo mesmo da próxima vez que um fornecedor mudar de rumo. 

E mesmo que não se importasse de migrar para a respetiva distribuição, o modelo era frágil. O Minimus reconstruía imagens a partir do upstream e enviava novos lançamentos, pelo que, mesmo quando o número de versão não mudava, uma imagem com patches significava um novo resumo (digest). Manter-se atualizado significava avançar para cada uma delas, e cada avanço representava uma imagem nova para testar e reaprovar.

Avançar funcionou bem até deixar de funcionar. Por exemplo, uma CVE afetou uma biblioteca na sua imagem e a correção foi enviada na versão 2.1, mas outro pacote de que dependia apenas aceitava versões inferiores à 2.0. A decisão sensata era fixar essa dependência numa versão exata, mas depois já não conseguia atualizar e a imagem acumulava vulnerabilidades. 

O que procurar numa alternativa ao Minimus

• Um grande catálogo pronto a usar: Quantas das bases que realmente utiliza é que este já cobre? Procure por uma verdadeira amplitude em Debian, Ubuntu e Alpine, tanto em amd64 como em arm64.
• Proveniência verificável: Um SBOM assinado, um documento VEX e proveniência SLSA associados a cada pull, para que possa provar o que está numa imagem e como foi construída.
• Segurança após o fim de vida: A aplicação de patches continua mesmo após a distribuição upstream avançar, permitindo-lhe manter uma base mais antiga sem carregar as respetivas CVEs críticas e altas conhecidas.
• Cobertura além da imagem base: Procure uma ferramenta que também chegue às suas dependências, código (SAST), IaC, segredos e runtime, para que um resultado chegue acompanhado do contexto circundante.
• Evidência de conformidade por predefinição: Linhas de base FIPS, CIS, NIST e STIG com os artefactos de auditoria gerados automaticamente.
• Um fornecedor com bases sólidas em que possa confiar: Pondere o suporte, o historial e o quanto perderia se isto voltasse a acontecer.

Principais alternativas ao Minimus

Aikido Security

Enquanto a Minimus o obrigou a migrar para a sua própria distribuição, o Aikido corrige a base image que já utiliza. Aikido Images é um registo de mais de 2.000 substituições diretas, onde as vulnerabilidades críticas e graves conhecidas na base já se encontram corrigidas. Estas imagens são recompiladas, corrigidas, minimizadas e protegidas durante a compilação, obtendo assim a proteção completa, uma superfície de ataque reduzida e predefinições seguras na base que já executa.

‍

Para exemplo, debian:bookworm disponibiliza uma correção glib2.0 para a CVE-2025-4373, que a Debian corrigiu no Trixie e Sid, mas não no Bookworm. A variante do Aikido Images de debian:bookworm contém a correção glib2.0 que a resolve.

Uma vez que a substituição é direta e proposta pelo AutoFix sob a forma de pull request, a correção é aplicada no momento em que efetua o merge, e cada pull proveniente de docker.aikido.io chega acompanhado de um SBOM, VEX e proveniência SLSA. O Aikido continua a corrigir versões após o upstream ter deixado de o fazer, incluindo aquelas que atingiram o fim de vida (end-of-life), permitindo-lhe manter uma base mais antiga sem carregar as respetivas falhas de segurança conhecidas e sem ser forçado a migrar para uma versão mais recente para se manter protegido.

A equipa por trás destas imagens integrou a empresa na sequência da aquisição da Root pelo Aikido, a empresa responsável pelo SlimToolkit (anteriormente DockerSlim), uma das ferramentas de hardening de imagens open source mais utilizadas, com mais de 23.000 estrelas no GitHub e uma capacidade documentada de reduzir o tamanho das imagens até 30x. Os clientes existentes da Root foram migrados para o Aikido Images e Libraries, e o Aikido pode retirá-lo da Minimus exatamente da mesma forma. 

O Aikido angariou 85 milhões de dólares e conta com a confiança de mais de 150.000 equipas, incluindo empresas como Revolut, Belfius, a Premier League, Deel e SoundCloud, além da Visma, que utiliza o Aikido em mais de 200 empresas do seu portefólio e 6.000 programadores. Uma empresa com liquidez suficiente para adquirir a Root por completo não é aquela que está prestes a desativar o seu registo.

Uma proporção crescente de correções reais nunca chega a receber um CVE. A monitorização contínua do Aikido é alimentada, em parte, pelo Aikido Intel, que analisa registos de alterações (changelogs) e o histórico de commits upstream para detetar vulnerabilidades que foram corrigidas silenciosamente sem um CVE associado. E enquanto a maioria destas ferramentas remedia um CVE através da atualização do pacote afetado para uma versão mais recente, o Aikido tira o máximo partido de patches retrocompatíveis (backports), extraindo a correção da versão mais recente e aplicando-a à versão que já utiliza. Isto mantém a alteração reduzida, pelo que a imagem tem maior probabilidade de se comportar da forma esperada pela aplicação, com menor dívida de atualização acumulada quando é forçado a adotar novas versões.

Quando um backport limpo não é possível, o Aikido atualiza ou recompila o componente em alternativa. Também mapeia cada container para a respetiva base de origem e aponta para a substituição que elimina o maior risco em toda a organização, com mais de 100 patches investigados e testados diariamente e cobertura ao nível do SO abrangida por um SLA de criação de patches definido.

As vulnerabilidades de pacotes ao nível da aplicação em ecossistemas como npm, PyPI, Maven e Go são corrigidas diretamente através de Aikido Libraries. Tudo isto integrado numa plataforma madura de segurança de software que também abrange SAST, DAST, SCA, detecção de segredos, postura na nuvem e varredura de imagens de contêiner, para que uma detecção numa imagem apareça com o contexto do código e da nuvem à sua volta.

Ideal para: equipas que pretendem eliminar vulnerabilidades das base images e dependências que já utilizam, sem necessidade de migrar para a distribuição de um fornecedor.

{{walkthrough}}

Chainguard

A Chainguard reduz uma imagem ao essencial e recompila-a a partir do Wolfi, a sua própria distribuição Linux. Disponibiliza todas as imagens com um SBOM assinado e assinaturas Sigstore, e publica um SLA de remediação de 7 dias para CVEs críticos e 14 dias para os restantes. Existem também opções de nível federal, com variantes validadas pela FIPS e hardening segundo as normas DISA STIG.

O custo traduz-se na migração e no lock-in. Adotar a Chainguard significa migrar os seus serviços para o respetivo catálogo e para o Wolfi, e se a sua aplicação dependesse de algum elemento removido pela Chainguard, deixará de funcionar. O modelo obriga-o a avançar continuamente, pelo que cada correção surge sob a forma de um novo digest que tem de testar e aprovar novamente, sendo que fixar (pinning) uma versão a um digest para garantir a reprodutibilidade impede que os patches cheguem até si. 

A Chainguard também torna obsoletas as versões anteriores com muita rapidez. Os pacotes que não sejam a versão mais recente são mantidos durante cerca de 12 meses, e o período de transição de fim de vida (end-of-life) prolonga-se por seis meses, abrangendo apenas os pacotes de dependência sob uma imagem em detrimento do componente principal, situando-se fora do SLA de CVE habitual. Qualquer elemento obtido a partir do repositório geral Wolfi OSS fica de fora do SLA, o compromisso FIPS não se estende a compilações personalizadas e a Chainguard não especifica o conteúdo de uma imagem ao nível dos CVE, pelo que a sua própria documentação o remete para Trivy, Grype, Snyk ou Docker Scout para efetuar análises. 

Ideal para: Equipas que podem assumir um compromisso com a distribuição e o ritmo de um único fornecedor. Não recomendado para equipas que precisam de manter uma base ou versão estável sem testes constantes.

Para uma análise mais detalhada, consulte a nossa lista completa de alternativas ao Chainguard.

Docker Hardened Images

O catálogo otimizado da Docker foi lançado em maio de 2025 e tornou-se gratuito e open source sob a licença Apache 2.0 em dezembro de 2025. O DHI merece ser considerado por equipas que já utilizam o Docker Hub. O seu objetivo é fornecer imagens com uma taxa de CVEs quase nula em bases standard Alpine e Debian, sem necessidade de adotar uma distribuição proprietária, disponibilizando SBOMs assinados e atestações VEX. O DHI Select acrescenta um SLA de CVE crítico de 7 dias, juntamente com variantes FIPS e STIG, enquanto o DHI Enterprise adiciona opções de personalização com suporte de ciclo de vida alargado até cinco anos após o fim de vida upstream.

O catálogo é mais recente e menos abrangente do que o dos intervenientes estabelecidos, pelo que o historial em cargas de trabalho fortemente reguladas é mais curto e não é garantida uma versão otimizada da sua base exata. A cobertura cinge-se também à imagem, não contemplando o código, as dependências, a IaC ou os secrets. Além disso, o DHI aplica a remediação avançando para a frente. Uma correção surge sob a forma de uma nova versão ou digest que tem de testar novamente, e a fixação para garantir estabilidade retarda a aplicação do patch.

Ideal para: Equipas que já utilizam o Docker Hub, pretendem imagens otimizadas e não necessitam de FIPS, STIG ou de um SLA, que se encontram disponíveis nos escalões pagos. Não recomendado para equipas cuja base exata não conste do catálogo da Docker, que ainda se encontra em desenvolvimento.

RapidFort

A RapidFort disponibiliza um catálogo de imagens otimizadas construídas sobre distribuições LTS standard como Alpine, Debian, Ubuntu e Red Hat, em vez de uma distribuição proprietária. A oferta está orientada para o setor federal e de defesa, contando com validação FIPS e hardening CIS e STIG. Para além do catálogo, a RapidFort inclui a análise de perfil em runtime (runtime profiling), monitorizando quais os pacotes e binários que são efetivamente executados em produção e removendo tudo o que não detetou em funcionamento.

Essa criação de perfis constitui também o senão. A ferramenta retém apenas o que observa, pelo que o código que não é acionado durante a janela de análise de perfil pode ser removido e falhar quando for finalmente executado em produção. Os perfis tornam-se desatualizados quando a aplicação ou o respetivo tráfego sofrem alterações, pelo que qualquer modificação relevante implica um novo perfil e novos testes antes do envio para produção. E, tal como as restantes soluções apresentadas, a cobertura cinge-se à imagem, sem proteção adicional para o código, dependências ou Cloud.

Ideal para: Empreiteiros federais, fornecedores de defesa e equipas reguladas já comprometidas com a conformidade FIPS e STIG, embora as equipas que procurem a otimização mais profunda do runtime profiling devam ter em conta que se trata de uma solução frágil e que requer a recriação de perfis sempre que a aplicação sofre alterações.

Echo

Em agosto de 2026, a Echo adquiriu os ativos da Minimus e tornou-se o fornecedor para o qual a Minimus está a direcionar os seus clientes. Para uma equipa da Minimus, esse é o caminho de menor resistência, mas convém ser claro sobre o que é. Estaria a migrar para as imagens de outro fornecedor, construídas e reconstruídas ao ritmo deles, que é precisamente o modelo do qual está a ser forçado a sair. A Echo integra o trabalho de SO da Minimus no seu próprio catálogo em vez de manter as imagens da Minimus ativas, por isso está a mudar de plataforma de qualquer forma.

A Echo é um interveniente mais recente que propõe uma fábrica de imagens impulsionada por IA, a qual compila imagens a partir do código-fonte, incluindo apenas os componentes necessários à aplicação, com agentes que monitorizam feeds de vulnerabilidades e regeneram imagens à medida que os CVEs surgem a montante. As imagens visam um número nulo de CVEs, são disponibilizadas como substituições diretas para as bases standard da Docker e incluem validação FIPS e alinhamento STIG para as equipas que o necessitem.

A principal questão prende-se com a maturidade. A Echo é uma empresa em ronda Series A com um historial operacional reduzido, pelo que o pipeline de recompilação e correção é o menos testado do grupo em cargas de trabalho reguladas e à escala de produção, e o catálogo é mais reduzido, pelo que a cobertura para cargas de trabalho menos comuns poderá ser mais limitada. Tal como no resto desta lista, a remediação é efetuada através do envio de uma nova imagem em vez da correção da versão que executa, e a cobertura cinge-se à imagem.

Ideal para: Equipas da Minimus que pretendem a mudança com o mínimo esforço, que se sentem confortáveis em adotar o catálogo de outro fornecedor e que conseguem suportar o risco de um fornecedor de Série A com um histórico curto a gerir o pipeline de que dependem as suas imagens.

FAQ