A segurança da informação costuma ser deixada de lado até que algo grave aconteça. Em ambientes com containers, esse descuido pode sair caro. Mesmo com boas intenções, atualizações mal planejadas ampliam a superfície de ataque e introduzem vulnerabilidades difíceis de detectar.
O ponto crítico é que muitas dessas falhas não estão no código da aplicação. Elas estão escondidas nas imagens base herdadas, repletas de bibliotecas obsoletas, pacotes desnecessários e riscos que passam despercebidos.
Pense em uma imagem de container como um prédio antigo que você herdou. À primeira vista, tudo parece funcionar. Com o tempo, surgem infiltrações, fechaduras quebradas, rachaduras. E então você percebe que não se trata apenas de pequenos reparos, mas de problemas estruturais que afetam toda a segurança da construção.
Com containers, acontece o mesmo. Herdamos imagens que carregam uma quantidade enorme de software desatualizado, muitas vezes sem saber. E como a responsabilidade por essa limpeza nem sempre é clara nos times, a decisão é adiar.
Neste artigo, mostramos porque a abordagem tradicional de manutenção contínua pode não ser suficiente. Estratégias como multi-stage build oferecem um caminho mais inteligente: construir com segurança desde o início, reduzindo a complexidade e permitindo que sua aplicação nasça em um ambiente confiável.
O Problema do Prédio Antigo: Vulnerabilidades Herdadas em Imagens Populares
Para visualizar melhor o que estamos discutindo até aqui, vamos escanear algumas imagens base famosas no Docker Hub.Você também pode fazer esse teste por conta própria.
DICA: É possível escanear imagens oficiais listadas no Docker Hub usando ferramentas como o Trivy. E, para uma visão completa do que está rodando no seu cluster Kubernetes, o Zora oferece um mapeamento detalhado de vulnerabilidades e misconfigurations.
Todas essas imagens acima tem mais de 10 milhões de downloads e talvez algumas delas estejam rodando na sua infraestrutura neste momento.
Um detalhe importante: todas elas usam a mesma imagem base, o Debian 12.10 , o que significa que já carregam, desde o início, a mesma vulnerabilidade crítica associada ao pacote zlib1g.
Um padrão parecido aparece ao analisar imagens de bancos de dados como Redis, MySQL e MongoDB. Mesmo sem serem escritos em Go, essas imagens incluem o binário da linguagem em sua base. No momento da análise (março/2025), apresentavam 3 vulnerabilidades críticas e 31 de alta severidade, como pode ser visto abaixo.
Essas vulnerabilidades críticas, inclusive, já possuem correções disponíveis, o que é comum no ecossistema open source. No entanto, estes pacotes precisam ser atualizados em um novo build da imagem. Até que essa ação aconteça, a vulnerabilidade permanece ativa.
Esse cenário não se limita a imagens públicas. O mesmo acontece dentro dos seus clusters, com as suas próprias imagens: elas acumulam não só vulnerabilidades do seu código, mas também falhas herdadas das bases utilizadas. E corrigir isso é um processo trabalhoso e caro.
No último relatório do MITRE sobre CVEs, foi destacado que mais de 80% das vulnerabilidades em containers estão nas imagens base. Como vimos acima, isso não se restringe a poucos casos. Mesmo imagens oficiais e amplamente utilizadas concentram um número significativo de vulnerabilidades ativas, que exigem trabalho contínuo.
Os Desafios da Patching Contínuo: Aqui é necessário refletir sobre o custo e a complexidade envolvidos na manutenção contínua de imagens. Todos os dias surgem novas vulnerabilidades, e a maior parte dos ambientes já começa essa jornada com uma quantidade significativa de CVES antigas a serem corrigidas.
Estudos apontam que cada CVE leva, em média, de 2 a 15 horas para ser corrigida.
Fazendo uma conta simples, apenas para resolver as falhas críticas e de alta severidade na imagem oficial do Nginx, seriam necessárias aproximadamente 140 horas de trabalho.
Agora, aplique essa estimativa ao volume de imagens utilizadas no seu ambiente. Considere a diversidade de stacks, o número de vulnerabilidades abertas e o tempo necessário para remediá-las com segurança.
O resultado é um custo elevado com tempo de engenharia, ciclos de build e validações manuais. Um esforço constante e pouco visível, que consome energia da equipe sem gerar valor direto, apenas para manter o mínimo necessário: a segurança das imagens de containers.
Estratégias Complementares: Shift-left e imagens seguras
No desenvolvimento seguro, a cada dia é mais comum utilizarmos a estratégia de "shift-left" que significa antecipar ações de segurança para as etapas mais iniciais do ciclo de desenvolvimento, ao invés de deixá-las só para o deploy. No caso de imagens de containers, isso se traduz em garantir que as imagens base já estejam seguras e validadas ainda na esteira de desenvolvimento ou no processo de build.
Como Adotar Imagens Base com Zero Vulnerabilidades Seguindo não apenas a premissa de redução de custo, como também do ganho de eficiência e principalmente de segurança, é que a abordagem da utilização de uma imagem base com zero vulnerabilidades se apresenta como a saída mais saudável para seus ambientes.
Essas imagens podem ser obtidas de duas principais maneiras:
1 - Criadas pelo próprio time: um time de especialistas deverá produzir e manter as imagens base das linguagens e frameworks utilizados no ambiente.
2 - Criadas e mantidas por um parceiro: o time de especialistas parceiro produz e mantém imagens base de diversas linguagens e frameworks com zero vulnerabilidades, efetua reanálises periódicas e constantes e atualiza essas imagens para versões mais seguras, mantendo sempre o padrão de zero vulnerabilidades. Saiba como a Getup pode lhe ajudar aqui.
Mas... e as ferramentas de debug?
Uma objeção comum ao uso de imagens enxutas é a ausência de ferramentas administrativas e debug. Na prática, essas ferramentas não deveriam estar na imagem (sabemos que tem uma discussão filosófica por aqui e podemos aprofundar em um segundo momento); incluir pacotes desnecessários contradiz as boas práticas da construção de containers, além de ampliar a superfície de ataque.
Containers devem conter apenas o que é necessário para executar a aplicação. Nada mais.
Claro, podem surgir momentos em que é preciso investigar algo em produção. E para isso já existem soluções mais seguras do que manter utilitários internos na imagem. Um bom exemplo é o uso de ephemeral containers para debug, disponível nativamente no kubectl desde a versão 1.25 do Kubernetes. Esse recurso permite inspeções pontuais sem comprometer o isolamento ou abrir brechas desnecessárias.
Conclusão: Do Prédio Antigo para uma Nova Estrutura Segura
Não pretendo esgotar o assunto aqui, mas levantar um ponto que precisa ser direcionado antes que vire uma dor maior. A proposta deste artigo é simples: provocar uma reflexão sobre o estado das suas imagens de containers e o impacto no seu dia a dia.
Se puder, comece fazendo um scan em algumas imagens que você já utiliza. Ter uma visão do que está rodando agora é o primeiro passo para decidir como lidar com o problema, seja com o seu time ou com apoio externo.
E se fizer sentido conversar sobre como acelerar essa transição com mais segurança e menos esforço, estamos por aqui: getup.io/lp/images