Principais ferramentas de endurecimento de imagens em 2026

Os templates standard de imagens de container vêm sobrecarregados com software desnecessário, o que aumenta a superfície de ataque e pode introduzir CVEs e vulnerabilidades. Investigadores que analisaram 7.380 imagens Docker baseadas em Debian descobriram que nenhuma delas estava isenta de vulnerabilidades conhecidas. O image hardening é o processo de otimizar e reduzir imagens de container para versões mais pequenas e seguras, de modo a diminuir os pontos de entrada para atacantes e cumprir as normas regulamentares.

No entanto, o image hardening evoluiu e pode significar coisas diferentes em 2026. Algumas ferramentas reconstroem imagens livres de CVE nas suas próprias distribuições. Contudo, isto significa que tem de migrar cada serviço para essa base e testar novamente para despistar eventuais quebras, ficando preso à distribuição e ao ritmo de lançamentos desse fornecedor. Outra abordagem consiste em aplicar patches à imagem que já utiliza, mantendo-se na mesma distribuição e versão principal (major version), evitando assim a migração.

Esta publicação compara as principais ferramentas de image hardening em 2026 com base na forma como cada uma aplica o hardening, no risco de migração e de quebras (breaking-change), na velocidade de remediação e na integração com o resto do seu fluxo de trabalho de segurança. Comparamos:

• Aikido Security
• Chainguard
• Docker Hardened Images
• Rapidfort
• Echo
• Minimus
• Wiz

TL;DR

A Aikido Security é a nossa principal escolha. Em vez de o obrigar a mudar para uma nova distribuição, aplica patches à imagem base que já utiliza, pelo que não há migração nem breaking changes. Os patches são aplicados através de um pull request de autofix que pode rever e fundir (merge) com um clique. Depois disso, a Aikido continua a reconstruir a imagem à medida que novas vulnerabilidades são corrigidas e alerta-o quando está disponível uma versão mais recente. A Aikido também continua a aplicar patches a versões após atingirem o fim de vida (end-of-life), permitindo-lhe manter uma base mais antiga sem carregar as respetivas CVEs críticas e altas conhecidas. O Aikido Intel expande a cobertura para além das bases de dados públicas, assinalando vulnerabilidades que foram corrigidas silenciosamente a montante, mas nunca receberam um CVE. Cada imagem é uma substituição direta (drop-in replacement) com SBOM, VEX e proveniência SLSA, cobrindo CVEs ao nível do SO sob um SLA de criação de patches definido — tudo isto integrado numa plataforma que também abrange SAST, DAST, SCA, detecção de segredos e postura cloud.

{{cta}}

O que é o hardening de imagens de container?

Uma container base image é a camada inicial fundamental para um container. Uma imagem pública padrão inclui habitualmente gestores de pacotes, shells, compiladores e ferramentas de depuração para funcionar para toda a gente, mas é provável que a sua aplicação não precise da maioria disto. 

Hardening significa remover o software que a carga de trabalho nunca utiliza (o que elimina classes inteiras de vulnerabilidades juntamente com os pacotes) e proteger o que resta com versões corrigidas, predefinições seguras, execução sem root e configurações alinhadas com o CIS/STIG.

O resultado é uma imagem mais pequena e limpa que começa segura e se mantém assim à medida que as vulnerabilidades upstream são encontradas e corrigidas. As imagens endurecidas também geram provas de auditoria, como SBOMs assinados, proveniência de compilação, declarações VEX e assinaturas de conformidade.

Limitações comuns das ferramentas de endurecimento de imagens

A maioria das ferramentas de endurecimento de imagens obriga-o a abandonar a base que utiliza atualmente e a adotar o catálogo delas, ficando dependente do ritmo de reconstrução das mesmas enquanto as utilizar. Essa abordagem tem custos. A adoção implica uma migração e tudo o que o fornecedor removeu e de que a sua aplicação dependia discretamente pode avariar. Manter as correções significa avançar para cada novo digest, pelo que cada correção é uma imagem nova para testar e, sob controlo de alterações, voltar a aprovar. Fixar um digest para garantir estabilidade significa abdicar precisamente das correções que o motivaram a adotar a ferramenta. 

Aplicam-se também geralmente algumas limitações às imagens endurecidas. Retirar pacotes que uma carga de trabalho nunca utiliza remove as vulnerabilidades, mas um CVE num pacote de que realmente precisa continua a exigir uma correção real. E qualquer reconstrução pode alterar o comportamento de que a sua compilação dependia, razão pela qual a alteração de imagens implica sempre uma ronda de testes.

A alternativa é corrigir a base que já utiliza, mantendo a sua distribuição e versão principal no lugar e o código aberto sob a sua aplicação acessível. Não há nenhum catálogo de fornecedores para o qual migrar nem a necessidade de alterar a plataforma. 

O que procurar numa ferramenta de endurecimento de imagens

Nem todas as ferramentas que oferecem "endurecimento de imagens" fazem o mesmo trabalho. Deve procurar estes aspetos antes de tomar uma decisão.

• Um grande catálogo pronto a usar: Quantas das bases que utiliza atualmente dispõem de versões endurecidas oferecidas pela ferramenta? Procure uma verdadeira abrangência em distribuições como Debian, Ubuntu e Alpine, suporte para amd64 e arm64, e um catálogo ativamente mantido.
• Proveniência verificável: Isto significa um SBOM assinado (lista de materiais de software, o inventário completo do que está na imagem), um documento VEX (vulnerability exploitability exchange, que regista os CVEs que não o afetam diretamente) e proveniência SLSA (uma norma que atesta como e onde a imagem foi criada) associados a cada pull. 
• Segurança após o fim de vida (EOL): Procure correções que continuem mesmo após a distribuição upstream ter avançado, para que possa permanecer numa base mais antiga sem aceitar as suas vulnerabilidades críticas e altas conhecidas.
• Inteligência de remediação: A ferramenta apenas deteta vulnerabilidades que tenham recebido um CVE? Com a transição do NVD do NIST para um modelo baseado no risco em 2026, uma parte crescente das vulnerabilidades reais não receberá um CVE em tempo útil, e algumas nunca o receberão. Qualquer ferramenta ligada apenas a feeds públicos de CVE herda esses pontos cegos. 
• Cumpre as normas de conformidade: Estas normas exigem imagens minimizadas e proveniência documentada. Certifique-se de que a ferramenta produz essa evidência automaticamente.

Principais ferramentas de endurecimento de imagens em 2026

Aikido Security

Aikido Images corrige a imagem base que já utiliza em vez de o obrigar a migrar para uma nova, o que significa ausência de alterações disruptivas. O Aikido Images é um registo com mais de 2.000 imagens de substituição direta onde as vulnerabilidades CRITICAL/HIGH conhecidas na base já foram corrigidas. Essas imagens são reconstruídas, corrigidas, minimizadas e endurecidas durante a compilação, para que obtenha o tratamento completo, uma superfície de ataque mais reduzida e predefinições protegidas, na base que já utiliza.

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

Como a substituição é direta e proposta pelo AutoFix sob a forma de um pull request, a correção entra em vigor no momento em que faz o merge, em vez de no final de um ciclo de testes e migração, e cada pull 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 terminado o suporte, mesmo aquelas que atingiram o fim de vida (EOL), permitindo-lhe manter-se numa base mais antiga sem acumular falhas de segurança conhecidas e sem ser forçado a avançar para uma versão mais recente para se manter coberto.

O Aikido também compila as suas imagens a partir de código aberto padrão (os mesmos pacotes upstream distribuídos pela distro), ao contrário de várias destas ferramentas que reconstroem tudo a partir do seu próprio código-fonte ou de uma distribuição proprietária.

Uma quota 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 lê registos de alterações upstream e históricos de commits para detetar vulnerabilidades que foram corrigidas de forma silenciosa sem um CVE associado. E enquanto a maioria destas ferramentas remedia um CVE atualizando o pacote afetado para uma versão mais recente, o Aikido faz uma utilização intensiva de patches backported, aplicando a correção da versão mais recente à versão que já está a executar. Isto mantém a alteração reduzida, tornando mais provável que a imagem se comporte conforme a sua aplicação espera, com menos dívida de atualização acumulada quando é empurrado para novas versões. 

Quando um backport limpo não é possível, o Aikido atualiza ou recompila o componente. O Aikido também mapeia cada container para a base que herda e indica-lhe a substituição que elimina o maior risco em toda a organização, contando com mais de 100 correções investigadas e testadas diariamente e cobertura ao nível do SO sob 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.

A equipa por trás destas imagens juntou-se através da aquisição da Root, a empresa responsável pelo SlimToolkit (antigo DockerSlim), uma das ferramentas de otimização de imagens de código aberto mais utilizadas, com mais de 23 000 estrelas no GitHub e uma capacidade documentada de reduzir o tamanho de imagens até 30 vezes. A criação e otimização de imagens de contêiner foi onde esta equipa começou, e a ferramenta continua gratuita e aberta para qualquer pessoa utilizar.

‍Ideal para: Equipas empresariais que pretendem eliminar vulnerabilidades críticas e graves das imagens base e dependências que já utilizam, sem migrar para uma nova distribuição ou lidar com atualizações contínuas.

{{walkthrough}}

Chainguard

A Chainguard reduz uma imagem ao essencial e reconstrói-a a partir do Wolfi, a sua própria distribuição Linux. As imagens endurecidas são fornecidas com SBOMs e assinaturas Sigstore, são reconstruídas a partir da origem e contam com um SLA de remediação publicado de 7 dias para CVEs críticos e 14 dias para tudo o resto. A Chainguard disponibiliza ofertas para conformidade federal, com variantes validadas pela FIPS, módulos criptográficos validados pelo NIST e endurecimento DISA STIG.

O custo é a migração e a dependência de fornecedor. Adotar a Chainguard significa migrar os seus serviços para o respetivo catálogo e distribuição Wolfi, e se a sua aplicação depender de algo que a Chainguard removeu, irá falhar. O modelo também o mantém num ciclo de atualizações contínuas, pelo que cada correção resulta numa nova imagem para testar novamente. Fixar uma versão a um resumo (digest) para garantir a reprodutibilidade impede que as correções cheguem até si, o que anula o motivo pelo qual a adotou. 

A Chainguard também retira de circulação as versões mais antigas com relativa rapidez. As versões de pacotes que não sejam a mais recente são mantidas durante cerca de 12 meses, e a sua cobertura de fim de vida (end-of-life) está limitada a seis meses, aplicando-se apenas aos pacotes de dependências subjacentes a uma imagem e não ao componente principal. O resultado é uma pressão constante para avançar para versões mais recentes, o que gera trabalho adicional para equipas que preferem manter uma versão estável.

Ideal para: Equipas que conseguem comprometer-se com a distribuição e o ritmo de lançamentos de um único fornecedor. Não é adequado para equipas que precisam de manter as suas imagens base e respetivas versões, ou fixar uma versão sem retestes constantes.

Docker Hardened Images

O catálogo de imagens endurecidas da Docker foi lançado em maio de 2025 e tornou-se gratuito e de código aberto 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 é disponibilizar imagens base com um número próximo de zero CVEs, construídas sobre bases standard Alpine e Debian, e inclui SBOMs assinados, proveniência SLSA Build Level 3 e atestações VEX. O DHI Select acrescenta um SLA de 7 dias para CVEs críticos e variantes FIPS e STIG. O DHI Enterprise adiciona opções de personalização, estando disponível o suporte ELS (Extended Lifecycle Support) como suplemento pago por um período máximo de cinco anos após o fim de vida da origem.

O DHI é uma entrada mais recente, pelo que o historial em cargas de trabalho altamente reguladas é mais curto. Possui um catálogo menos profundo do que outras opções desta lista e não estende a cobertura para além das imagens de contêiner.

Ideal para: Equipas que preferem adotar imagens endurecidas dentro do seu fluxo de trabalho Docker existente, mas não para equipas cujas bases se encontram fora do catálogo da Docker, que continua a ser mais limitado do que outras ferramentas presentes.

Rapidfort

A RapidFort oferece um catálogo de imagens endurecidas baseadas em distribuições LTS standard como Alpine, Debian, Ubuntu e Red Hat, em vez de uma distribuição proprietária de contêineres. A oferta está fortemente orientada para cargas de trabalho federais e de defesa, incluindo FedRAMP, FISMA e CMMC. 

Para além do catálogo, a RapidFort oferece profiling em tempo de execução para otimizar ainda mais as imagens. O seu profiler observa quais os pacotes e binários que são efetivamente executados em produção, gera um inventário RBOM (Runtime Bill of Materials) e remove tudo o que não detetou em execução. Consegue reduzir uma imagem, mas a técnica é frágil porque o profiler retém apenas o que observa; qualquer elemento que não seja exercitado durante o profiling é candidato a remoção. Qualquer nova funcionalidade, dependência ou alteração de configuração implica um novo processo de profiling e testes antes do envio para produção.

Ideal para: Empreiteiros federais, fornecedores do setor da defesa e equipas reguladas já comprometidas com a conformidade FIPS e STIG. No entanto, as equipas que optam pela otimização mais profunda baseada no profiling em tempo de execução devem ter em conta que esta abordagem é frágil e exige um novo profiling sempre que a aplicação sofre alterações.

Echo

A Echo é uma empresa mais recente, cuja proposta se baseia numa fábrica de imagens impulsionada por IA que compila imagens de contêiner a partir do código-fonte, incluindo apenas os componentes de que a aplicação realmente necessita. Os seus agentes monitorizam os feeds de vulnerabilidades e regeneram imagens à medida que novos CVEs surgem na origem. As imagens resultantes visam zero CVEs e são disponibilizadas como substitutas diretas das imagens base standard da Docker. As imagens contam com validação FIPS e alinhamento STIG para equipas que necessitem dessas garantias, posicionando-se a Echo como uma alternativa direta à Chainguard e às Docker Hardened Images no segmento de imagens base reconstruídas. 

Onde a Echo apresenta menos provas dadas é no historial operacional do pipeline de reconstrução e correção impulsionado por IA sob cargas de trabalho reguladas e à escala de produção. 

Ideal para: Equipas que pretendem uma estratégia de imagens base reconstruídas. No entanto, as equipas devem sentir-se confortáveis em avaliar um fornecedor em ronda de Série A com um catálogo mais reduzido e um historial operacional mais curto.

Minimus

A Minimus foi fundada em outubro de 2022 por cofundadores que anteriormente criaram a Twistlock (adquirida pela Palo Alto Networks em 2019). O produto foi lançado publicamente na conferência RSAC em abril de 2025, pelo que o seu historial ainda é bastante recente. As imagens da Minimus são construídas a partir do código-fonte de origem, contendo apenas o software necessário para executar uma aplicação. O respetivo pipeline monitoriza projetos de código aberto, reconstrói pacotes quando os mantenedores publicam novas versões e disponibiliza novas imagens após testes automatizados e assinatura. O catálogo publicado conta com mais de 1 200 imagens endurecidas e suporta as linhas de base de conformidade FIPS, CIS, NIST e STIG.

Adotar a Minimus implica migrar os seus serviços para as respetivas imagens e, dado que o modelo reconstrói a partir da origem e disponibiliza novos lançamentos em vez de aplicar correções retroativas (backporting) na versão que fixou, manter-se atualizado significa transitar para cada novo resumo (digest). Cada correção resulta numa nova imagem para testar e aprovar, e fixar uma versão para garantir estabilidade impede a aplicação das correções. O historial também é curto, estando o produto disponível publicamente apenas desde abril de 2025 e, tal como as restantes opções aqui apresentadas, fica-se pela imagem base, não abrangendo o resto da sua pilha tecnológica.

Ideal para: Equipas que pretendem imagens construídas a partir do código-fonte e que conseguem executar um pipeline de reconstrução e nova implementação que acompanha o ritmo dos novos resumos (digests). No entanto, não é adequado para equipas que precisam de manter uma versão fixa e ainda assim obter a correção de segurança, sem terem de avançar para uma nova versão e realizar retestes a cada correção.

Wiz

A Wiz assegura o endurecimento através do WizOS, o seu próprio catálogo de imagens base mínimas construídas a partir do código-fonte e mantidas com um nível muito baixo de CVEs conhecidos, fornecidas com SBOMs, proveniência verificável e um SLA de remediação de 7 dias para vulnerabilidades críticas e 14 dias para graves e médias. Existem variantes endurecidas com FIPS e STIG para cargas de trabalho reguladas. O WizOS integra-se na plataforma de segurança na nuvem da Wiz, permitindo que uma imagem base vulnerável seja visualizada em conjunto com os sinais de nuvem, código e runtime associados, juntamente com recomendações para a substituição por um equivalente do WizOS, aplicação de políticas através de controlador de admissão (admission-controller) e atualizações com um clique no IDE.

As desvantagens prendem-se com o âmbito e o modelo. Tal como a Chainguard, o WizOS obriga a migrar os serviços para as imagens da Wiz em vez de aplicar correções retroativas na versão que já utiliza, pelo que cada correção constitui uma nova imagem a testar e aprovar. O catálogo é também mais recente e restrito do que o dos especialistas, tendo começado com imagens focadas em Go e expandido posteriormente, pelo que a existência de um equivalente endurecido para a sua base exata não é garantida. 

Ideal para: Equipas que já utilizam a Wiz e pretendem que as imagens base endurecidas sejam identificadas e aplicadas na mesma plataforma que utilizam para a segurança na nuvem e em runtime. Não é adequado para equipas cujas bases se encontram fora do catálogo do WizOS, que continua em expansão.