Imagem de container segura: base, usuário não-root, SBOM e assinatura

Um scanner apontando 180 vulnerabilidades em uma imagem gera duas reações possíveis. A primeira é começar a atualizar pacotes um a um. A segunda, mais produtiva, é perguntar por que aquela imagem tem 180 pacotes que a aplicação não usa.

Segurança de imagem de container é, antes de tudo, um exercício de subtração. Componente que não está na imagem não tem vulnerabilidade, não precisa de atualização e não aparece em relatório. Depois vem o resto: quem executa, com que permissão, e como provar que a imagem que roda é a que você construiu.

Comece pela base: menos é mais

A escolha da imagem base decide a maior parte da superfície.

A troca é sempre entre superfície e conforto de diagnóstico. Imagem sem shell é mais segura e impede que você entre nela para investigar.

A recomendação prática: variante enxuta ou distroless para produção, com a ressalva de que a decisão depende da linguagem. Binário compilado estaticamente cabe em imagem mínima; aplicação interpretada com dependências nativas costuma exigir mais.

Sobre o argumento contra imagens sem shell: a resposta moderna é o container de depuração efêmero, que anexa ferramentas ao pod em execução quando você precisa investigar. Isso remove a última boa razão para manter shell e utilitários na imagem de produção.

Dois detalhes que importam mais do que parecem:

• Fixe a base por versão específica, nunca latest. Base móvel torna a construção irreprodutível e o rollback incerto.
• Reconstrua periodicamente. Imagem construída há oito meses tem oito meses de correções não aplicadas, mesmo que o seu código não tenha mudado. Um pipeline semanal de reconstrução das imagens base é um dos investimentos de melhor relação custo-benefício em segurança.

Multi-stage: a técnica que resolve várias coisas de uma vez

Separar o estágio de build do estágio de execução entrega três ganhos simultâneos:

• Compilador, ferramentas e dependências de build não vão para a imagem final. É uma redução enorme de superfície.
• Segredos usados na construção — token do registry privado, chave de acesso a repositório — não ficam em camada da imagem final.
• Imagem menor significa envio mais rápido e inicialização mais rápida.

Esse segundo ponto merece atenção: camada de imagem guarda histórico. Copiar um arquivo com credencial e apagá-lo numa camada seguinte não remove o arquivo — ele continua acessível na camada anterior, para quem baixar a imagem. Multi-stage resolve isso estruturalmente; mecanismos de montagem de segredo durante o build resolvem também.

Usuário não-root

Root dentro do container não é root do host, mas reduz o custo de uma escapada de forma substancial. Uma vulnerabilidade que exige privilégio dentro do container simplesmente não se aplica se o processo roda sem ele.

O que precisa ser feito:

• Declarar um usuário não privilegiado na imagem, com identificador numérico explícito.
• Ajustar dono dos diretórios que a aplicação escreve, durante a construção.
• Usar porta acima de 1024, já que portas baixas exigem privilégio. O mapeamento externo resolve a aparência.
• Verificar volumes montados, cujo dono precisa bater com o identificador do usuário do container.

E, do lado do orquestrador, reforçar o que a imagem declara: exigir execução sem root, impedir escalonamento de privilégio, remover todas as capacidades do kernel e adicionar de volta apenas o que for necessário, e montar o sistema de arquivos raiz somente leitura, com volumes graváveis apenas onde a aplicação realmente escreve.

Esse conjunto é o que transforma "a imagem declara um usuário" em "o ambiente garante o usuário". Imagem bem construída sem política no orquestrador ainda pode ser executada com privilégio por quem escrever o manifesto errado.

O scanner e o que fazer com o resultado

Scan de vulnerabilidade é obrigatório e produz um problema próprio: volume de achados que ninguém consegue tratar. Dois meses depois, o relatório vira ruído ignorado.

O que torna o scan útil:

• Rodar na construção e falhar o pipeline por severidade alta em componente que a aplicação realmente usa.
• Rodar periodicamente sobre o que está em produção. Vulnerabilidade nova aparece em imagem que não mudou — é o modo de descoberta mais comum, e o scan só na construção não o cobre.
• Priorizar por explorabilidade, não só por severidade. Vulnerabilidade crítica em biblioteca que a aplicação não carrega tem risco diferente de uma média no caminho de rede exposto.
• Aceitar exceções com prazo e justificativa escrita, não com silêncio. Exceção sem prazo vira permanente.
• Reduzir por subtração. Metade dos achados de uma imagem gorda desaparece ao trocar a base.

SBOM e assinatura: provar o que você entrega

Duas práticas que deixaram de ser exóticas e passaram a ser exigidas por cliente corporativo.

SBOM é a lista de materiais da imagem: todo componente e versão que ela contém, em formato padronizado. Gerado na construção e publicado junto da imagem.

Por que importa, concretamente: quando aparece uma vulnerabilidade grave em uma biblioteca amplamente usada, a pergunta é "estamos afetados, e onde?". Com SBOM de cada imagem, isso é uma consulta de minutos. Sem, é uma varredura manual de dias — e foi exatamente o cenário vivido por muita empresa em incidentes recentes de cadeia de suprimentos.

Assinatura garante que a imagem que está rodando foi construída pelo seu pipeline e não foi alterada. O conjunto moderno envolve assinar a imagem, gerar atestado de procedência — descrevendo qual pipeline, qual commit e quais entradas produziram aquele artefato — e verificar a assinatura no momento da execução, com política que recusa imagem não assinada.

Esse último ponto é o que dá valor real. Assinar sem verificar é cerimônia. A verificação no cluster, com política que bloqueia o que não passa, é o que efetivamente impede que alguém execute uma imagem que não veio do seu pipeline.

Registry: o elo esquecido

• Registry privado, com autenticação e autorização por repositório.
• Espelhamento das imagens públicas que você usa. Isso resolve limite de taxa, resolve indisponibilidade do registry público e resolve o caso da imagem que é removida da origem.
• Política de retenção — e cuidado: limpeza agressiva demais remove a imagem para a qual você precisaria reverter. É uma causa clássica e evitável de rollback impossível.
• Imutabilidade de tag nas versões de produção. Tag que pode ser sobrescrita significa que a imagem em produção pode mudar sem novo deploy.

O checklist

1. Base enxuta, fixada por versão específica.
2. Multi-stage, sem ferramentas de build na imagem final.
3. Nenhum segredo em camada — montagem durante o build ou estágio separado.
4. Usuário não-root declarado, com identificador numérico.
5. Política no orquestrador exigindo não-root, sem escalonamento, capacidades mínimas, raiz somente leitura.
6. Scan na construção, com falha por severidade alta relevante.
7. Scan periódico do que está em produção.
8. Exceções com prazo e justificativa.
9. SBOM gerado e publicado com a imagem.
10. Imagem assinada, com atestado de procedência.
11. Verificação de assinatura no momento da execução.
12. Registry privado, com espelho das públicas e retenção que preserva o rollback.
13. Reconstrução periódica para absorver correções da base.

Erros comuns

• Base completa quando uma enxuta resolveria.
• latest na base, com construção irreprodutível.
• Nunca reconstruir, acumulando correções não aplicadas.
• Segredo em camada de imagem, "removido" na camada seguinte.
• Rodar como root por conveniência.
• Imagem declara usuário e o manifesto sobrescreve com privilégio.
• Sistema de arquivos raiz gravável sem necessidade.
• Scan só na construção, sem varredura periódica da produção.
• Relatório com centenas de achados que ninguém trata.
• Exceção sem prazo, que vira permanente.
• Assinar e não verificar na execução.
• Depender de registry público a cada deploy.
• Retenção do registry apagando a imagem necessária para reverter.
• Tag sobrescrevível em produção.

Onde a Solvefy/Cloud entra

Tratamos isso como uma frente completa: revisão e redução das imagens base, reestruturação da construção em multi-stage com segredos fora das camadas, execução sem privilégio reforçada por política no orquestrador, scan integrado ao pipeline com triagem por explorabilidade e exceções com prazo, geração de SBOM, assinatura com atestado de procedência e verificação obrigatória na execução, além de registry privado com espelho e retenção que preserva o caminho de volta. Entregamos o antes e depois em número de componentes e de vulnerabilidades — que costuma cair por subtração antes de qualquer correção.

Sabe o que exatamente está rodando dentro das suas imagens? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.