Já parou pra pensar na quantidade de container que você roda no seu dia a dia sem saber direito o que entra neles? Eu mesmo já perdi sono pensando se aquele build automático do CI não tinha puxado uma dependência bizarra, ou deixado uma brecha fácil de explorar. Nessas horas, bate aquela vontade de ter um selo de garantia — tipo “pode rodar tranquilo que ninguém mexeu aqui”. Mas será que existe mesmo esse selo?

Foi lendo sobre alternativas ao Chainguard — que o pessoal do BestDevOps listou — que comecei a revisitar essa ansiedade antiga. Pra quem não conhece, o Chainguard ficou famoso por popularizar o conceito de imagem “hardened”, aquelas imagens de container super mínimas, auditadas, com promessa de segurança reforçada na cadeia de software. Mas agora, em 2026, está cheio de competidor querendo pegar um pedaço desse mercado.

O que aconteceu

A matéria destaca cinco concorrentes que estão crescendo (ou prometem crescer) no mercado de imagens hardened. Até pouco tempo atrás, se você queria uma imagem “imune” (aspas muuito intencionais), era basicamente Chainguard e pronto. Só que, à medida que a ideia foi pegando, empresas como Docker (com as suas variantes slim), Snyk, Distroless, Wolfi e Stacklok começaram a brigar por espaço.

O movimento tem lógica: todo mundo quer garantir que o container que sobe em produção não veio com brinde malicioso ou dependências desnecessárias. As empresas viram nisso uma oportunidade de transformar segurança de base em produto, e agora cada player oferece seu conceito de imagem “limpa”, geralmente acompanhada de ferramentas pra escaneamento e pipeline automatizada.

Por que isso importa

Falar de imagens hardened não é só onda do momento. Quem já precisou passar por um processo de auditoria de segurança sério sabe o quanto é trabalhoso garantir que cada layer do seu container está limpo. E mesmo assim, sempre fica aquela pulga atrás da orelha, porque basear tudo num Alpine genérico, por exemplo, nunca foi garantia de nada.

Antes desse movimento, a prática era montar uma imagem magra, rodar um scanner (tipo Trivy ou Clair), e torcer pra não pegar muita coisa velha ou desconhecida. O problema é que vulnerabilidades zero-day, ou dependências obscuras, sempre podem escapar. O Chainguard ajudou a colocar no radar que dá pra fazer base pensando em cadeia de confiança desde o início, e não só “passando antivírus” depois de buildar.

Outra coisa importante: as soluções novas estão prometendo integração direta com pipeline CI/CD e políticas de assinatura/verificação usando Sigstore ou Notary. O Stacklok, por exemplo, está focando bastante em supply chain attestation (aquela ideia de provar que cada build veio de onde diz que veio). Isso é um salto em relação ao simples scan de vulnerabilidade.

Agora, tem o outro lado: quanto mais fechado e “hardened” for o ambiente, mais chato fica pra quem precisa debugar, monitorar ou até rodar um hotfix numa emergência. Já perdi cabelo tentando instalar um simples curl numa imagem distroless pra investigar um problema em produção. Então, toda essa segurança extra vem com um custo operacional que nem sempre aparece bonito na propaganda.

Na prática

Pra quem trabalha com container, o impacto é direto. Primeiro, a escolha da imagem base já muda a forma como você empacota apps. Uma imagem hardened geralmente não tem shell, nem utilitário nenhum além do binário principal. Se você depende de scripts ou ferramentas de debug, é bom rever o workflow.

Outro ponto: muitas dessas soluções agora vêm com integração de assinatura automática. Por exemplo, adicionando assinatura Sigstore ao build, o Dockerfile pode ficar assim:

FROM cgr.dev/chainguard/python:3.11 as base
LABEL org.opencontainers.image.source=https://github.com/sua-org/seu-projeto

# Build e assinatura (no CI)
sigstore sign --key /path/to/key --output signed-image.tar base

Além disso, é preciso ajustar as pipelines pra garantir que só imagens assinadas sobem pra produção, configurando admission controllers no Kubernetes ou políticas de verificação, tipo:

apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
  name: so-imagem-assinada
spec:
  images:
    - glob: "cgr.dev/chainguard/*"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev

A curva de aprendizado pode ser grande pra quem vinha de um Dockerfile tradicional, mas os benefícios estão aí: menos superfície de ataque, build mais previsível e confiança maior na cadeia de entrega.

O que eu acho disso

Eu gosto muito da ideia de elevar o nível do que a gente espera de uma imagem base. O que me incomoda é o discurso meio mágico de “instale isso e seus problemas acabaram”. No mundo real, a migração traz atrito — e se você trabalha com equipes pequenas ou legados gigantes, o custo de reempacotar tudo pode ser alto. Não é só trocar a imagem e pronto.

Outro ponto: a competição é ótima pro mercado, mas ainda vejo muita solução vendendo feature que devia ser commodity (assinatura, scan, pipeline integrada). O que eu queria mesmo era um padrão aberto, fácil de implementar, que qualquer um pudesse rodar sem vendor lock-in. Stacklok e Wolfi, por exemplo, parecem ir nessa direção, mas a batalha tá só começando.

Pra quem está pensando em migrar, minha dica é: teste aos poucos, não caia na armadilha do hype, e sempre planeje como vai debugar (porque uma hora vai precisar).

E você, já experimentou alguma dessas imagens hardened ou ficou só no tradicional? Como foi a dor — ou o alívio — no seu cenário?