Buildpacks deslocam o ponto de controle da segurança de containers para fora do Dockerfile

O antigo debate entre Dockerfile e buildpacks virou uma discussão de segurança. Segundo reportagem da InfoQ, a diferença central está em onde a imagem base é declarada, e isso muda quem controla a velocidade de correção de uma CVE crítica em uma frota de serviços.

O problema do FROM em cada repositório

No modelo tradicional, a imagem base aparece numa linha FROM dentro de cada repositório. Propagar uma base corrigida significa alterar todos os serviços. Ferramentas como Renovate e Dependabot automatizam a parte mecânica, mas não eliminam o rebuild: cada FROM atualizado dispara build completo, uma vaga na fila de CI, execução de testes e redeploy, multiplicado pelo número de serviços.

Os Cloud Native Buildpacks invertem essa lógica. Um builder é uma imagem OCI que empacota um conjunto ordenado de buildpacks, o lifecycle e uma imagem base de build, além de uma referência a uma imagem base de runtime (a run image) guardada como metadado. Builds subsequentes pegam uma nova run image, e imagens de aplicação já existentes e compatíveis podem ser rebased sem reconstruir as camadas da aplicação, embora atualizar produção ainda exija testes, promoção e deploy.

A graduação na CNCF e o comando rebase

O projeto Cloud Native Buildpacks graduou dentro da CNCF em 17 de julho de 2026, segundo a InfoQ. A proposta é "concentrar o conhecimento das boas práticas de build de containers num time especializado, em vez de ter desenvolvedores de aplicação mantendo individualmente seus próprios Dockerfiles".

O mecanismo é o comando rebase, que detecta uma run image mais nova e reescreve o manifesto e a configuração OCI. Ao trocar os digests da camada de SO pelos da nova run image, o ciclo de rebuild é contornado. Escrevendo para o grupo CNCF TAG Environmental Sustainability em dezembro de 2023, Joe Kutner descreveu isso como essencialmente uma edição em um arquivo JSON, que leva milissegundos e pouco processamento, sem rebuild, acesso ao código-fonte ou fila de CI. A ressalva: o rebase só substitui camadas compatíveis da run image; vulnerabilidades em dependências da aplicação ainda exigem rebuild.

Fornecedores competem em builders seguros

Essa eficiência é uma das razões pelas quais vendors de buildpacks passaram a competir em segurança de builders. A BellSoft anunciou disponibilidade geral em 21 de julho de 2026 de um builder Paketo endurecido, construído sobre suas Alpaquita Linux-based Hardened Images: conjunto reduzido de pacotes, padrões non-root, assinaturas e dados de SBOM, embora os times de plataforma ainda precisem assinar, atestar, testar e promover as imagens resultantes.

A BellSoft afirma publicar uma imagem corrigida "tipicamente em 24 horas" após a divulgação; contratualmente, seu tier Standard anuncia SLA de remediação de 7 dias para vulnerabilidades críticas e 14 dias para as demais, enquanto o tier gratuito Community não lista SLA.

Outros fornecedores, incluindo Chainguard, Docker, Wiz e Minimus, competem em catálogos de imagens com baixo ou zero CVE, e o mercado está se comoditizando. A Docker liberou todo o seu catálogo de imagens endurecidas de graça sob licença Apache 2.0 em dezembro de 2025, mantendo tiers pagos para remediação com SLA. O tier Select da Docker se compromete a corrigir CVEs críticas em sete dias, igualando o tier Standard da BellSoft.

O que muda para quem constrói software no Brasil

Para times BR que lidam com containerização, o ângulo prático é a redução da curva: em vez de cada squad manter um Dockerfile e acompanhar a cadência de patch, o hardening fica abstraído no builder mantido pela plataforma. Segundo a reportagem, um levantamento da BellSoft com 250 desenvolvedores, tech leads e arquitetos de Spring no Spring I/O 2026 apontou que 64% não reconheciam o próprio Dockerfile como risco de segurança. Um estudo apresentado no ICSME 2025, com 6.292 imagens Docker, encontrou que quase 61% dos repositórios carregavam dependências de aplicação vulneráveis em todas as tags examinadas.

Os buildpacks não são solução universal. Eles abrem mão do controle passo a passo dos Dockerfiles escritos à mão, o que complica cargas que precisam de pacotes de SO customizados ou ecossistemas não cobertos. As image extensions fecham parte dessa lacuna, mas estender a run image pode comprometer a capacidade de rebase. Também podem significar builds frios mais lentos e imagens maiores, além de concentrar confiança no builder da plataforma. A escolha, nas palavras da InfoQ, é entre controle e raio de impacto, com pressão crescente de regulações como o EU Cyber Resilience Act.

Fonte: InfoQ