As melhores alternativas ao Minimus em 2026

O Minimus vai encerrar as suas atividades e o seu registo (reg.mini.dev) deixará de estar disponível a 22 de outubro de 2026, após um período de manutenção de 60 dias que teve início a 24 de agosto. As imagens já descarregadas continuarão a funcionar, mas não haverá novas atualizações. Se utilizar imagens do Minimus, tem um prazo para a migração.

Mesmo antes disso, o seu modelo não funcionava para toda a gente. Adotar o Minimus significava passar a utilizar as suas imagens, que eram criadas com base na sua própria distribuição (MinimOS), e depender do seu calendário de lançamentos. E como as imagens não incluem distribuição (sem shell nem gestor de pacotes), tudo aquilo de que a sua configuração dependesse e que o Minimus tivesse removido tinha de ser reformulado. 

Existem alternativas que evitam isso. Em vez de o transferir para uma distribuição de um fornecedor, aplicam correções à imagem base que já utiliza e, nos casos em que fixou uma versão, incorporam as correções nessa versão, em vez de o obrigar a atualizar. Este artigo aborda os próximos passos a seguir.

Este artigo aborda os próximos passos a dar e o que deve ter em conta para não ter de migrar novamente daqui a um ano. Comparamos:

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

TL;DR

A nossa escolha principal é Aikido Segurança. Em vez de o migrar para uma nova distribuição, aplica correções à imagem base que já está a utilizar, pelo que nada fica inoperacional, e a correção é enviada como um pedido de integração que basta integrar uma única vez. Depois disso, o Aikido continua a recompilar a imagem à medida que novas vulnerabilidades são corrigidas e alerta-o quando estiver disponível uma compilação mais recente. Cada imagem é um substituto direto com proveniência « SBOM », VEX e SLSA, abrangendo CVEs ao nível do sistema operativo ao abrigo de um SLA definido para a criação de correções. Continua a aplicar correções às versões mesmo após o fim da vida útil e integra-se numa plataforma que também abrange SAST, DAST, SCA, deteção de « secrets » e a postura na nuvem. Tendo já migrado os clientes da Root, o Aikido pode fazer a sua transição do Minimus da mesma forma.

{{cta}}

O que a Minimus fez bem

A Minimus criou as suas imagens «distroless» a partir do código-fonte na sua própria distribuição, a MinimOS, incluindo apenas o necessário para a execução de uma aplicação e sem nenhuma das ferramentas do shell e do gestor de pacotes que aumentam a superfície de ataque. O catálogo chegou a contar com mais de 1 200 imagens com padrões de referência FIPS, CIS, NIST e STIG e, em junho de 2026, todo o conjunto passou a ser gratuito, sem necessidade de registo. Para as imagens que se adaptavam tal como estavam, a adoção consistiu numa alteração de uma única linha num Dockerfile ou num manifesto.

Por que precisa de uma alternativa ao Minimus agora

O catálogo do Minimus vai ser encerrado e não haverá mais atualizações das imagens do Minimus a partir de 22 de outubro. Tudo o que já tiver descarregado continuará a funcionar, mas as vulnerabilidades (CVEs) irão acumular-se sem que haja uma versão corrigida para substituir as atuais.

Se quiser manter as suas imagens livres de vulnerabilidades, é agora obrigado a realizar uma migração dispendiosa para fora do Minimus. Sair do Minimus implica substituir todas as imagens do Minimus que alojam um dos seus serviços por outra fonte e voltar a testá-las. A migração em si é agora inevitável, pelo que vale a pena escolher um substituto que não o vincule à sua própria distribuição e cadência de atualizações; caso contrário, terá de repetir este processo na próxima vez que um fornecedor mudar de rumo. 

E mesmo que não houvesse problemas em migrar para a sua distribuição, o modelo era frágil. O Minimus recompilava imagens a partir do código-fonte original e lançava novas versões; por isso, mesmo quando o número da versão não mudava, uma imagem corrigida significava um novo resumo. Manter-se atualizado implicava avançar para cada uma delas, e cada avanço representava uma nova imagem para testar e voltar a aprovar.

A atualização automática funcionava bem até deixar de funcionar. Por exemplo, uma vulnerabilidade CVE afetou uma biblioteca na sua imagem e a correção foi lançada na versão 2.1, mas outro pacote do qual dependia só aceitava versões anteriores à 2.0. A medida mais sensata era fixar essa dependência a uma versão específica, mas, nesse caso, não era possível atualizar, e a imagem acabava por acumular vulnerabilidades. 

O que procurar numa alternativa ao Minimus

• Um vasto catálogo de soluções prontas a usar: quantas das plataformas em que realmente trabalha já estão abrangidas? Procure uma verdadeira variedade de opções no Debian, no Ubuntu e no Alpine, tanto em amd64 como em arm64.
• Proveniência verificável: Um ficheiro « SBOM » assinado, um documento VEX e a proveniência SLSA anexados a cada pull, para que possa comprovar o conteúdo de uma imagem e a forma como foi criada.
• Segurança após o fim do ciclo de vida: aplicação de correções que continua mesmo depois de a distribuição de origem ter avançado para a próxima versão, para que possa manter uma base mais antiga sem ter de lidar com as vulnerabilidades CVE conhecidas como críticas e de alto risco.
• Cobertura para além da imagem base: procure uma ferramenta que também abranja as suas dependências, o código (SAST), a IaC ( secrets) e o tempo de execução, para que cada descoberta seja apresentada com o seu contexto.
• Provas de conformidade por predefinição: diretrizes FIPS, CIS, NIST e STIG com os artefactos de auditoria gerados automaticamente.
• Um fornecedor com quem pode contar: avalie o seu histórico, os resultados alcançados e quanto perderia se a situação se repetisse.

As melhores alternativas ao Minimus

Aikido Security

Enquanto o Minimus o transfere para a sua própria distribuição, o « Aikido » aplica correções à imagem base que já utiliza. O «Aikido Images» é um registo com mais de 2 000 substituições prontas a utilizar, nas quais as vulnerabilidades críticas e de alto risco conhecidas na imagem base já foram corrigidas. Essas imagens são recompiladas, corrigidas, minimizadas e reforçadas durante o processo de compilação, para que obtenha um tratamento completo, uma superfície de ataque mais reduzida e configurações predefinidas mais seguras, na imagem base que já utiliza.

‍

Para exemplo, debian:bookworm lança uma versão corrigida glib2.0 relativamente à vulnerabilidade CVE-2025-4373, que o Debian corrigiu nas versões Trixie e Sid, mas não na Bookworm. A variante « Aikido Images» de debian:bookworm contém a versão corrigida glib2.0 isso encerra o assunto.

Como a troca é uma alteração direta que o AutoFix propõe como um pedido de integração, a correção é aplicada no momento em que se efetua a integração, e cada pedido de integração proveniente de docker.aikido.io chega com uma proveniência SBOM, VEX e SLSA. O Aikido continua a aplicar correções às versões mesmo depois de o upstream as ter descontinuado, incluindo aquelas que chegaram ao fim do ciclo de vida, para que se possa permanecer numa base mais antiga sem ter de lidar com as suas falhas de segurança conhecidas e sem ser obrigado a atualizar para uma versão mais recente para manter a proteção.

A equipa responsável por estas imagens juntou-se à empresa através da aquisição da Root pela Aikido. A Root é a empresa responsável pelo SlimToolkit (anteriormente DockerSlim), uma das ferramentas de reforço de imagens de código aberto mais utilizadas, com mais de 23 000 estrelas no GitHub e uma capacidade comprovada de reduzir o tamanho das imagens até 30 vezes. Os clientes existentes da Root foram migrados para as Imagens e Bibliotecas do Aikido , e o Aikido pode ajudá-lo a deixar de utilizar o Minimus da mesma forma. 

Aikido já angariou 85 milhões de dólares e conta com a confiança de mais de 150 000 equipas, incluindo empresas como a Revolut, a Belfius, a Premier League, a Deel e a SoundCloud, bem como a Visma, que gere a « Aikido » em mais de 200 empresas do seu portfólio e 6 000 programadores. Uma empresa com liquidez suficiente para adquirir a Root na totalidade não é do tipo que esteja prestes a desativar o seu registo.

Uma parte cada vez maior das correções efetivas nunca recebe um CVE. A monitorização contínua do Aikido é alimentada, em parte, pelo Aikido Intel, que analisa os registos de alterações e o histórico de commits do upstream para detetar vulnerabilidades que foram corrigidas silenciosamente sem que lhes fosse atribuído um CVE. E enquanto a maioria destas ferramentas corrige um CVE atualizando o pacote afetado para uma versão mais recente, o Aikido recorre intensamente a patches retroportados, obtendo a correção da versão mais recente e aplicando-a à versão que já está a utilizar. Isso mantém a alteração mínima, pelo que é mais provável que a imagem se comporte da forma que a sua aplicação espera, com menos «dívida de atualização» que se acumula quando é forçado a adotar novas versões.

Quando não é possível efetuar um backport sem problemas, o Aikido procede à atualização ou à recompilação do componente. Além disso, associa cada container à base de que herda e indica a substituição que elimina o maior risco em toda a organização, com mais de 100 patches pesquisados e testados diariamente e cobertura ao nível do sistema operativo, ao abrigo de um SLA definido para a criação de patches.

As vulnerabilidades de pacotes ao nível da aplicação em ecossistemas como o npm, PyPI, Maven e Go são corrigidas diretamente através das Bibliotecas «Aikido ». Tudo isto integra-se numa plataforma de segurança de software madura que também abrange a deteção de SAST, DAST, SCA e secrets , a avaliação da postura na nuvem e a análise de imagens em container , de modo que cada imagem detetada é apresentada juntamente com o código e o contexto na nuvem que a rodeiam.

Ideal para: equipas que pretendem eliminar as vulnerabilidades das imagens base e das dependências que já utilizam, sem migrarem para uma distribuição de um fornecedor.

{{walkthrough}}

Chainguard

Chainguard desmonta uma imagem e reconstrói-a a partir do Wolfi, a sua própria distribuição Linux. Fornece todas as imagens com uma assinatura « SBOM » e assinaturas Sigstore, e publica um SLA de correção de 7 dias para CVEs críticos e de 14 dias para todos os restantes. Existem também opções de nível federal, com variantes validadas pela FIPS e reforço de segurança DISA STIG.

O custo reside na migração e no «lock-in». Adotar o « Chainguard » significa transferir os seus serviços para o catálogo e para o Wolfi, e se a sua aplicação dependesse de algo que o « Chainguard » tenha removido, ela deixaria de funcionar. O modelo obriga-o a avançar continuamente, pelo que cada correção é implementada como um novo «digest» que tem de voltar a testar e aprovar, e fixar-se a um «digest» para garantir a reprodutibilidade impede que as correções lhe cheguem de todo. 

Chainguard Além disso, as versões mais antigas são retiradas rapidamente. Os pacotes que não são os mais recentes são mantidos durante cerca de 12 meses, e o seu período de carência de fim de vida útil tem a duração de seis meses, abrange apenas os pacotes de dependência incluídos numa imagem — em vez do componente principal — e não está abrangido pelo SLA normal da CVE. Qualquer elemento extraído do repositório geral do Wolfi OSS fica fora do SLA, o compromisso FIPS não se estende a compilações personalizadas e o Chainguard não indica o que está incluído numa imagem ao nível do CVE; por isso, a sua própria documentação remete para o Trivy, o Grype, o Snyk ou o Docker Scout para a verificação. 

Ideal para: Equipas que se possam comprometer com a distribuição e a cadência de um único fornecedor. Não é adequado para equipas que precisem de manter uma base ou uma versão estável sem a necessidade de realizar novos testes constantemente.

Para saber mais, consulte a nossa lista completa de alternativas ao Chainguard .

Docker Hardened Images

O catálogo reforçado do Docker foi lançado em maio de 2025 e tornou-se gratuito e de código aberto ao abrigo da licença Apache 2.0 em dezembro de 2025. Vale a pena considerar o DHI para equipas que já utilizam o Docker Hub. Tem como objetivo fornecer imagens com número de CVE quase nulo nas bases padrão Alpine e Debian, sem necessidade de adotar nenhuma distribuição proprietária, e inclui SBOMs assinados e atestados VEX. O DHI Select acrescenta um SLA de 7 dias para CVEs críticos, além de variantes FIPS e STIG, e o DHI Enterprise acrescenta personalização com suporte de ciclo de vida alargado até cinco anos após o fim de vida útil do upstream.

O catálogo é mais recente e menos abrangente do que o dos operadores já estabelecidos, pelo que o historial em cargas de trabalho fortemente regulamentadas é mais curto e não há garantia de que exista uma versão reforçada da sua base específica. A cobertura limita-se também à imagem, não abrangendo o seu código, dependências, IaC ou secrets. Além disso, o DHI aplica as correções através de atualizações progressivas. Uma correção chega sob a forma de uma nova versão ou resumo que tem de voltar a testar, e a fixação para garantir a estabilidade retém a aplicação do patch.

Ideal para: Equipas que já estão no Docker Hub, que pretendem imagens reforçadas e não necessitam de FIPS, STIG ou de um SLA, recursos que só estão disponíveis nos planos pagos. Não é adequado para equipas cuja base específica não se encontre no catálogo do Docker, que ainda é limitado.

RapidFort

A RapidFort oferece um catálogo de imagens reforçadas baseadas em distribuições LTS padrão, como Alpine, Debian, Ubuntu e Red Hat, em vez de uma distribuição proprietária. A gama de produtos está orientada para trabalhos no âmbito federal e de defesa, com validação FIPS e reforço de segurança segundo as diretrizes STIG e CIS. Para além do catálogo, a RapidFort adiciona a análise de perfis em tempo de execução, monitorizando quais os pacotes e binários que são efetivamente executados em produção e removendo tudo o que não foi detetado como executado.

Essa análise de desempenho é também o senão. Ela apenas guarda o que observa, pelo que o código que não é executado durante o período de análise pode ser eliminado e, posteriormente, falhar quando for finalmente executado em produção. Os perfis tornam-se obsoletos quando a aplicação ou o seu tráfego se alteram, pelo que qualquer alteração significativa implica uma nova análise de desempenho e novos testes antes do lançamento. E, tal como os outros aqui referidos, a cobertura limita-se à imagem, sem abranger o código, as dependências ou a nuvem.

Ideal para: contratantes federais, fornecedores do setor da defesa e equipas sujeitas a regulamentação que já estejam empenhadas no cumprimento das normas FIPS e STIG; no entanto, as equipas que pretendam uma otimização mais aprofundada através da análise de desempenho em tempo de execução devem ter em conta que esta é frágil e requer uma nova análise sempre que a aplicação sofrer alterações.

Echo

A Echo é uma empresa recém-chegada ao mercado que apresenta uma «fábrica de imagens» baseada em IA, que compila imagens a partir da fonte, incluindo apenas os componentes de que uma aplicação necessita, com agentes que monitorizam os feeds de vulnerabilidades e regeneram imagens à medida que surgem novos CVEs a montante. As imagens têm como objetivo o número zero de CVEs, são fornecidas como substitutos diretos das bases Docker padrão e vêm com validação FIPS e alinhadas com as STIG para as equipas que assim o necessitem.

A questão principal é a maturidade. A Echo é uma empresa em fase de Série A com um historial operacional curto, pelo que o pipeline de «reconstrução e aplicação de patches» é o menos comprovado do grupo em cargas de trabalho regulamentadas e à escala de produção; além disso, o catálogo é mais reduzido, pelo que a cobertura para cargas de trabalho menos comuns pode ser mais limitada. Tal como acontece com o resto desta lista, a correção é feita através do envio de uma nova imagem, em vez da aplicação de patches à versão que está a executar, e a cobertura limita-se à imagem.

Ideal para: Equipas que pretendem adotar uma estratégia de imagens base criadas a partir do código-fonte e que estão dispostas a assumir o risco de um fornecedor em fase de Série A, com um historial ainda curto, ser responsável pela gestão do pipeline do qual as suas imagens dependem.

FAQ