Proteger imagens Docker

Uma imagem Docker é composta por uma pilha de camadas, que são conjuntos imutáveis e só de leitura de alterações no sistema de ficheiros empilhados sobre as inferiores. Um SO base fica na base, depois os pacotes necessários para executar e, finalmente, o seu próprio código por cima. Proteger imagens Docker significa controlar o que entra nelas e mantê-las corrigidas após o seu lançamento.

A maioria das vulnerabilidades de um container provém dos pacotes e bibliotecas de código aberto incluídos. Alguns, como o cURL ou uma shell, a sua aplicação poderá nunca chamar após o container estar em execução, pelo que podem ser removidos da imagem. Outros, como o glibc, são necessários para o funcionamento da aplicação e não podem ser removidos. O resto das vulnerabilidades resulta habitualmente de erro humano, como um segredo inserido numa camada ou um container deixado em execução com privilégios de root.

Esta publicação aborda a origem dos riscos numa imagem Docker, como manter as imagens endurecidas é um problema de gerenciamento de vulnerabilidades, as três formas como as ferramentas mantêm uma imagem base corrigida e como o Aikido protege e corrige as imagens que já está a executar.

{{cta}}

TL;DR

A proteção de imagens Docker envolve a remoção de pacotes não utilizados e a correção de vulnerabilidades no que resta. Remover pacotes não utilizados elimina apenas as vulnerabilidades daquilo de que não precisa. Um pacote vulnerável de que a sua aplicação realmente depende ainda precisa de correção, e mesmo uma imagem minimizada continua a acumular novas vulnerabilidades. Além disso, a adoção de imagens endurecidas envolve frequentemente a migração para outra distribuição e atualizações ao ritmo de terceiros. O Aikido fornece novas compilações corrigidas das mesmas versões de imagens base, entregues via PR. Se fixou uma versão, isto permite-lhe permanecer nessa versão, sem alterações que quebrem a compatibilidade ou a necessidade de transitar para uma nova imagem.

De onde vêm os riscos numa imagem Docker 

O FROM linha é a primeira instrução num Dockerfile, que indica a imagem base sobre a qual está a construir. A FROM node:24 define a imagem oficial do Node.js 24 como base, que vem com o runtime do Node.js mais um sistema Debian completo por baixo. Isto inclui um shell, um gestor de pacotes e bibliotecas de sistema, cada uma das quais pode conter vulnerabilidades que herda antes de escrever uma única linha do seu próprio código.

Cada instrução do Dockerfile adiciona uma camada sobre a anterior, e as camadas são imutáveis. Eliminar algo numa camada posterior apenas o oculta, pelo que tudo o que a base incluía permanece na imagem, quer a sua aplicação o utilize quer não. A sua aplicação nunca chama a maioria do que vem incluído na base, mas cada pacote aí presente é uma superfície de ataque.

Por exemplo, o CVE-2023-4911 ("Looney Tunables") foi uma falha de escalação de privilégios locais no carregador dinâmico do glibc, um componente situado na camada base de quase todas as imagens Linux principais. O glibc vinha com a distribuição e qualquer container construído com uma base afetada continha-o. 

Bases diferentes, risco diferente

Nem todas as imagens base incluem a mesma quantidade. Uma imagem de distribuição completa inclui muito mais do que a sua aplicação precisa, incluindo um shell e um gestor de pacotes que provavelmente nunca utilizará. Uma variante "slim" reduz parte disso. Uma imagem "distroless" remove o shell e o gestor de pacotes por completo e mantém apenas o que um runtime necessita. O Alpine é pequeno por conceção e, por ser construído com musl em vez de glibc, nem sequer esteve exposto ao Looney Tunables.

Manter as imagens seguras é um problema de gerenciamento de vulnerabilidades

Uma imagem segura está limpa no dia em que é criada, mas degrada-se com o tempo, à medida que novas vulnerabilidades são descobertas em pacotes já presentes no seu interior. Mantê-la segura significa tratar a imagem como algo que é reexaminado em função de novas divulgações e corrigido de forma contínua. A versão manual envolve o acompanhamento de divulgações em cada pacote de cada base e a aplicação retrospetiva ou atualização manual de cada correção.

Fixar numa versão de confiança faz sentido quando já testou essa versão e pretende continuar a executá-la, mas continua a precisar de monitorizar novas divulgações. Uma imagem que é fixada e esquecida acumulará vulnerabilidades recentemente descobertas. Se essa imagem atingir o fim de vida e deixar de receber correções a montante, a sua lista de falhas conhecidas e não corrigidas aumenta. Por exemplo, o Node.js 20 atingiu o fim de vida a 30 de abril de 2026, pelo que um container que continue fixado em node:20 continua a funcionar, mas todas as vulnerabilidades divulgadas para essa linha desde então ficam sem correção, sem perspetiva de remediação.

O instinto oposto, saltar sempre para a versão mais recente, é igualmente problemático. Por exemplo, a porta de entrada oculta (backdoor) no xz-utils é uma biblioteca de compressão que se encontra na maioria das imagens base do Linux. Estava presente em duas versões recentes específicas, a 5.6.0 e a 5.6.1, e as equipas que ainda se mantinham na linha mais antiga 5.4 nunca foram expostas. A orientação da CISA posteriormente foi para fazer o downgrade e não o upgrade. 

O que o protege realmente é tomar decisões ponderadas sobre as versões que executa. Considere uma equipa que fixa debian:bookworm, regista que a escolheu em detrimento da versão mais recente porque a testou e é estável, e a verifica contra novas divulgações à medida que vão surgindo. Quando um novo CVE é divulgado num pacote dessa imagem, já sabem que o executam e o porquê. Isto permite-lhes avaliar a exposição real face ao custo de alteração.

Como proteger imagens Docker

Reduzir a superfície de ataque

Comece com uma imagem base mínima ou pré-endurecida. A base determina a maior parte do que herda, tornando esta a escolha de maior impacto que pode fazer. (Abordado mais detalhadamente na secção seguinte)

Utilize multi-stage builds para manter as ferramentas de compilação fora da imagem final. A compilação da imagem normalmente inclui um compilador, cabeçalhos de desenvolvimento e um gestor de pacotes para compilar a sua aplicação e instalar as respetivas dependências. Numa compilação de etapa única, tudo isso permanece integrado na imagem final, mesmo que a aplicação em execução nunca o utilize. Um multi-stage build produz o artefacto numa etapa inicial e copia apenas esse artefacto para uma etapa final limpa, evitando que qualquer ferramenta de compilação seja enviada.

Remova pacotes de que a aplicação em execução não necessita. Provavelmente não precisa de uma shell, uma vez que a maioria das aplicações inicia o seu processo diretamente e nunca chama uma em runtime. Utilitários como cURL ou wget são úteis durante a compilação, mas provavelmente não são necessários em runtime, pois a sua aplicação efetua chamadas de rede através das suas próprias bibliotecas. Além disso, qualquer elemento obtido pelo cURL durante a compilação já está integrado na imagem no momento do envio, não restando nada para ser descarregado. 

Definir as permissões corretamente

Execute o container como um utilizador não root. Se um atacante obtiver a execução de código na sua aplicação, obtém os privilégios com os quais o container está a ser executado. O modo non-root reduz o raio de impacto de uma intrusão

Utilize um sistema de ficheiros raiz só de leitura. Isto impede que um atacante que já esteja no interior escreva ficheiros, introduza ferramentas ou modifique o container em runtime. Qualquer elemento que necessite genuinamente de escrita pode receber um ponto de montagem com permissão de escrita específico.

Remova as capacidades do Linux que não utiliza. Os containers iniciam com um conjunto de capacidades do kernel que a maioria das aplicações nunca utiliza. CAP_NET_RAW, por exemplo, permite que um processo crie pacotes de rede falsificados e está ativo por predefinição, mas uma aplicação web típica nunca precisa disto, enquanto um atacante que consiga aceder pode utilizá-lo para falsificar tráfego na sua rede. Remova as que não precisa e adicione novamente apenas o estritamente necessário. A remoção destas capacidades (e a adição apenas do necessário) elimina operações privilegiadas que, de outra forma, estariam disponíveis para um atacante.

Manter os Secrets e ficheiros perdidos fora da imagem

Mantenha os Secrets fora das camadas. Um secret obtido através de ARG ou COPY permanece no histórico da imagem mesmo que uma camada posterior o elimine, e qualquer pessoa que obtenha a imagem pode descompactar as camadas e lê-lo. Utilize montagens de secrets ou montagens SSH para expor um secret a um único passo de compilação sem o escrever numa camada.

Manter um secret fora das camadas é apenas metade do trabalho. O container em execução ainda precisa do valor, pelo que deve injetá-lo em runtime a partir de um gestor de secrets dedicado (Vault, um gestor de secrets na Cloud ou Kubernetes secrets) montado como ficheiro ou injetado no ambiente, rodando-o periodicamente em vez de integrar credenciais de longa duração em qualquer lugar.

Utilize um ficheiro .dockerignore . Este ficheiro controla o que entra inicialmente no contexto de compilação, para que .git, configurações locais e credenciais perdidas nunca sejam copiadas para a imagem através de um comando COPY instrução.

Afixar com cuidado

Fixe a imagem base pelo digest e não pela tag. FROM node:24 é resolvido novamente ao longo do tempo, pelo que duas builds com um mês de diferença podem puxar imagens diferentes, e uma base comprometida pode infiltrar-se silenciosamente. Fixar por digest (@sha256:...) torna a base determinística, para que possa criar exatamente a imagem que testou. Tenha em atenção que, se o seu modelo de correção enviar correções como novas imagens, um digest fixado também retém essas correções. Se, em vez disso, conseguir obter uma build corrigida da mesma versão que fixou, evita esse problema e mantém-se seguro.

Não confie em latest. Alguns assumem que significa a versão mais recente e estável, mas no Docker é apenas a etiqueta predefinida aplicada à última imagem enviada sem uma tag de versão explícita. Pode apontar para uma imagem mais antiga do que espera e pode mudar entre builds.

Verificar e manter

Gere um SBOM para cada imagem. Uma lista de materiais de software é o inventário completo do que está dentro da imagem, cada pacote e versão. É isto que lhe permite responder "somos afetados?" no momento em que surge uma nova vulnerabilidade. 

Assine cada imagem quando é criada e verifique essa assinatura antes de ser executada com um controlador de admissão que rejeita qualquer coisa não assinada. Essa cadeia impede que uma imagem adulterada ou não aprovada chegue à produção, mesmo que alguém consiga aceder ao seu registo.

Trate os containers em execução como imutáveis. Assim que uma imagem for implementada, não corrija nem reconfigure o container em execução. Crie uma nova imagem, teste-a e volte a implementar. O que está a ser executado corresponde sempre ao que construiu, testou e assinou, o que elimina a deriva de configuração e torna a reversão tão simples como voltar a implementar a imagem anterior.

Volte a verificar as imagens continuamente. Uma imagem que passou limpa na verificação da semana passada pode conter uma vulnerabilidade crítica hoje, porque novas vulnerabilidades são divulgadas diariamente contra pacotes que já lá estão dentro. Por isso, verificar no momento da build não é suficiente. 

Três formas de manter uma imagem base endurecida

Manter uma imagem base endurecida à medida que novas vulnerabilidades são descobertas é um trabalho contínuo e existem três formas de lidar com isso.

Faça-o você mesmo

Mantenha a sua própria base endurecida. Escolha uma imagem mínima, remova o que não precisa e volte a criá-la sempre que um pacote no seu interior apresentar uma vulnerabilidade. Mantém o controlo total, mas requer trabalho e manutenção contínuos. Está a acompanhar divulgações em cada pacote na base e a aplicar correções manualmente ou a atualizar cada uma. Multiplique isso por cada base em cada serviço, e isso consome tudo o resto que poderia estar a construir.

Mude para a distribuição reconstruída de um fornecedor

Algumas plataformas disponibilizam imagens endurecidas reconstruídas na sua própria distribuição. Migra os seus serviços para a base deles, volta a testar para detetar falhas e, em seguida, vive ao ritmo de lançamento deles, avançando para um novo digest em cada correção. Isto traz dois custos. A própria migração pode quebrar qualquer coisa de que a sua aplicação dependesse e que o fornecedor tenha removido. E manter-se corrigido significa a mesma armadilha de atualização em que qualquer atualização de dependência tropeça, onde uma nova versão principal pode mover caminhos de pacotes, alterar predefinições e quebrar um Dockerfile funcional. Se fixar um digest para garantir estabilidade, acaba por não receber as correções exatas para cuja adoção implementou a ferramenta.

Permita que uma ferramenta corrija a base que já executa

Alguns fornecedores permitem-lhe manter a sua versão no lugar, fornecendo builds corrigidas da mesma versão, em vez de transitar para uma nova imagem. Obtém uma nova build da mesma versão com a CVE corrigida, que adota ao rever e juntar como qualquer outra alteração, e não através da edição da imagem em execução. Desta forma, mantém-se na versão que já testou e continua a eliminar a vulnerabilidade.

Como a Aikido protege imagens Docker

Aikido Security fornece novas builds corrigidas das mesmas versões de imagem base que já executa.

Aikido Images é um registo de mais de 2.000 imagens de substituição direta onde as vulnerabilidades críticas e de alta gravidade conhecidas na base já estão corrigidas. Cada uma é reconstruída, corrigida, minimizada e endurecida durante a build, para que obtenha uma superfície de ataque menor e predefinições seguras na base que já executa.

Enquanto uma ferramenta de distribuição reconstruída envia a correção como uma nova imagem para a qual migra, a Aikido aplica a correção à versão que fixou. Retira a correção da versão mais recente e aplica-a à versão que já executa, para que a alteração permaneça pequena e a imagem se comporte da mesma forma que sempre fez. Quando uma aplicação limpa de correções não é possível, a Aikido atualiza ou reconstrui o componente. A troca é uma substituição direta que o AutoFix propõe como pull request, e cada pull de docker.aikido.io inclui um SBOM, VEX e proveniência SLSA.

Continua a corrigir versões mesmo depois de o upstream avançar, incluindo bases que atingiram o fim de vida, permitindo-lhe manter uma versão mais antiga sem carregar as suas falhas conhecidas e sem precisar de atualizar apenas para se manter coberto.

Uma proporção crescente de correções reais para pacotes nunca chega a receber uma CVE, pelo que, se você ou as suas ferramentas apenas lerem a base de dados de CVE, estão a perder vulnerabilidades. A correção da Aikido é alimentada em parte pela Aikido Intel, que lê registos de alterações (changelogs) e histórico de commits do upstream para detetar vulnerabilidades que foram silenciosamente corrigidas no upstream sem uma CVE, para que a cobertura não se limite ao que as bases de dados públicas conseguiram enriquecer.

Os pacotes ao nível da aplicação em npm, PyPI, Maven e Go são corrigidos diretamente através de Aikido Libraries, utilizando a mesma abordagem de aplicação de correções aplicada às suas dependências. E a varredura de imagens de contêiner da Aikido verifica pacotes de SO vulneráveis, dependências, runtimes desatualizados, malware e riscos de licença em imagens base, comandos de Dockerfile e workloads de Kubernetes, para que um resultado apareça com o contexto do código e da cloud.

A equipa por trás destas imagens chegou ao Aikido através da aquisição da Root, a empresa responsável pelo SlimToolkit (antigamente DockerSlim), uma das ferramentas open source de endurecimento de imagens mais utilizadas. O endurecimento de imagens foi o ponto de partida desta equipa, e a ferramenta continua gratuita e aberta para qualquer pessoa utilizar.

{{walkthrough}}

FAQ