A segurança de container registry é a prática de proteger o sistema que armazena e distribui as suas imagens de containers, de modo que somente imagens confiáveis e verificadas possam entrar nele e somente workloads autorizados possam fazer pull dele. Se a construção de imagens é onde o software é montado, o registry é onde ele aguarda para ser distribuído, e isso o torna um dos alvos de maior alavancagem em todo o seu pipeline. Todo cluster, todo nó, todo job de CI que executa um container acaba retornando a um registry e fazendo pull. Comprometa esse único ponto e você compromete tudo a jusante.
Este é o aprofundamento sobre registries dentro do nosso guia mais amplo sobre segurança de Docker e containers. Se você já reforçou a forma como as imagens são construídas e configuradas, o registry é o próximo elo da cadeia, e ele merece o mesmo escrutínio.
O registry como ponto de estrangulamento da cadeia de suprimentos
Pense no que um registry realmente é: um repositório compartilhado e acessível pela rede de artefatos executáveis para o qual muitas equipes fazem push e do qual ainda mais workloads fazem pull. Essa concentração é exatamente o que o torna perigoso. O OWASP Top 10 de 2025 elevou as falhas de cadeia de suprimentos de software à posição A03 justamente porque os atacantes perceberam que os pontos de distribuição upstream lhes dão um raio de impacto enorme por relativamente pouco esforço.
Alguns padrões de ataque específicos de registries aparecem repetidamente:
Imagens envenenadas ou com backdoor. Um atacante que obtém acesso de push, ou que insere uma camada maliciosa em um build, pode publicar uma image que parece legítima, mas que embarca um criptominerador, um reverse shell ou código de coleta de credenciais. Como a image carrega um nome e uma tag familiares, nada a jusante a questiona.
Imagens públicas typosquatted. Registries públicos hospedam milhões de imagens, e nomes como alpine, alpin e a1pine são fáceis de confundir. Um desenvolvedor copiando uma linha FROM sob pressão de prazo pode nunca perceber que uma image base é uma impostora.
Riscos de pull-through e cache. Caches de proxy são maravilhosos para a confiabilidade, mas um cache que espelha cegamente o que quer que um upstream sirva também pode espelhar fielmente um upstream comprometido. Se você faz cache por tag mutável, pode acabar servindo uma image trocada muito depois de a original ter sido obtida.
O tema por trás de tudo isso é a confiança. Um registry, por padrão, distribui o que quer que tenha sido enviado a ele, para quem quer que pergunte. A segurança de registry é o trabalho de acrescentar cláusulas de "mas somente se" a essa frase.
Registries públicos versus privados
A decisão estrutural mais eficaz que você pode tomar é parar de fazer pull diretamente de registries públicos em produção. Registries públicos como o Docker Hub são indispensáveis para descoberta e para o fornecimento de imagens base, mas são ecossistemas abertos que você não controla. Qualquer pessoa pode publicar; as imagens mudam; limites de taxa e disponibilidade não estão nas suas mãos.
Um registry privado, ou um proxy privado que faz pull-through para fontes públicas, dá a você uma fronteira controlada. As imagens base entram por uma etapa de avaliação, passam por varredura e aprovação, e então são republicadas internamente como imagens "golden" sobre as quais suas equipes têm permissão de construir. Os workloads fazem pull somente do registry interno, então você sempre sabe exatamente o que está sendo distribuído e pode revogar uma image ruim em um único lugar.
A etapa de avaliação importa tanto quanto a fronteira. Antes de promover uma image base pública para dentro, confirme seu digest, revise o que ela realmente contém, prefira variantes mínimas ou distroless que carreguem menos superfície de ataque, e fixe (pin) em um digest em vez de uma tag flutuante, para que aquilo que você aprovou seja aquilo que você continua recebendo.
# Pin by immutable digest, not a mutable tag, when promoting a base image
docker pull alpine@sha256:
docker tag alpine@sha256: registry.internal.example.com/base/alpine:3.20-approved
docker push registry.internal.example.com/base/alpine:3.20-approved
Controle de acesso: autenticação e autorização
Se o registry é um ponto de estrangulamento, suas credenciais são as chaves desse ponto de estrangulamento. Trate-as de acordo.
Comece pelo menor privilégio. Sistemas de CI e agentes automatizados devem autenticar-se como contas robot ou de serviço dedicadas, cada uma restrita exatamente aos repositórios de que precisa e exatamente aos verbos de que precisa. Um job de build que publica um serviço não precisa de acesso de push a todos os repositórios, e quase nada fora de uma etapa de promoção controlada precisa de direitos de delete.
Prefira tokens de curta duração a segredos estáticos de longa duração. Muitos registries permitem trocar uma identidade de workload ou um token OIDC do seu provedor de CI por um token de registry escopado e com expiração, o que significa que não há uma senha durável parada em uma variável esperando para vazar. Onde você precisar usar uma credencial estática, armazene-a em um gerenciador de segredos, faça a rotação em uma cadência definida e restrinja seu escopo estreitamente.
Dois antipadrões merecem ser nomeados e eliminados: credenciais de admin compartilhadas que várias pessoas ou pipelines usam em comum (ninguém consegue dizer quem fez o quê, e a rotação é um pesadelo), e endpoints de registry expostos à internet aberta quando só precisam servir redes internas. Coloque o registry atrás de um endpoint privado ou restrinja-o por política de rede, faça allowlist das faixas de CIDR e das identidades que legitimamente o acessam, e exija autenticação inclusive para pulls de imagens privadas.
Assinatura e verificação no pull e no deploy
O controle de acesso decide quem pode fazer push. A assinatura decide se você pode confiar no que foi enviado, depois do fato e independentemente de como chegou lá. Uma assinatura criptográfica vincula um digest de image a uma identidade, de modo que um consumidor pode verificar que uma dada image foi produzida por um signatário autorizado e não foi alterada desde então.
Quer você use content trust clássico, uma abordagem OCI-native como Notation, ou um fluxo keyless no estilo cosign vinculado à identidade do workload, o formato é o mesmo: os publicadores assinam o digest no momento do push, e os consumidores verificam a assinatura antes de executar a image.
# Sign an image after pushing (cosign-style keyless example)
cosign sign registry.internal.example.com/team/api@sha256:
# Verify before deploy; fail closed if the signature is missing or invalid
cosign verify \
--certificate-identity-regexp '.*@example\.com' \
--certificate-oidc-issuer https://token.actions.example.com \
registry.internal.example.com/team/api@sha256:
A assinatura só compensa se a verificação for imposta, e não opcional. O lugar de impô-la é na fronteira em que as imagens se tornam workloads em execução. No Kubernetes, um admission controller pode rejeitar qualquer pod cuja image não esteja assinada ou falhe na verificação, o que transforma "nós assinamos nossas imagens" em "imagens não assinadas não podem executar aqui". Essa imposição no momento do admission é importante o suficiente para que a abordemos por conta própria em segurança de imagens Kubernetes.
Varredura de imagens no registry
A varredura no CI captura problemas antes de uma image ser publicada, e você absolutamente deve fazê-la. Mas a varredura no CI é um instantâneo tirado no momento do build, e o cenário de vulnerabilidades não fica parado. Uma CVE divulgada no dia seguinte ao seu build recai sobre uma image que seu pipeline já declarou limpa.
A varredura no registry resolve a parte que o CI não consegue. Como o registry mantém toda image que pode vir a ser obtida, ele é o lugar certo para fazer duas coisas:
Gate no push. Faça a varredura das imagens conforme elas chegam e bloqueie ou coloque em quarentena qualquer uma que carregue vulnerabilidades críticas ou de alta severidade, para que uma image reprovada nunca fique disponível para pull em primeiro lugar.
Reescaneie continuamente. Reavalie as imagens armazenadas contra dados de vulnerabilidade atualizados em uma cadência definida, para que, quando uma nova CVE surgir, as tags afetadas sejam sinalizadas, colocadas em quarentena ou bloqueadas para pulls futuros, mesmo que nada na image tenha mudado.
Juntos, o gating e o reescaneamento contínuo significam que o conjunto de imagens que seus workloads podem obter é sempre julgado em relação ao que se sabe hoje, não ao que se sabia no dia do build.
Immutable tags, retenção e garbage collection
Tags mutáveis são uma fonte silenciosa de risco de cadeia de suprimentos. Se :latest ou :v2 podem ser sobrescritas, então a image que você verificou ontem pode não ser a image que você obtém hoje, e sua trilha de auditoria se dissolve.
Configure os repositórios de modo que, uma vez que uma tag seja enviada, ela não possa ser sobrescrita. As immutable tags garantem que um nome sempre se refira ao mesmo conteúdo, o que torna assinaturas, resultados de varredura e provenance significativos ao longo do tempo. Consumidores que fixam por digest obtêm a mesma garantia de graça.
A imutabilidade faz os registries crescerem, então combine-a com política de ciclo de vida. As regras de retenção devem manter o que você precisa para rollback e conformidade, ao mesmo tempo em que expiram imagens antigas, sem tag e substituídas, e a garbage collection deve então recuperar o armazenamento que aqueles manifests expirados e blobs órfãos estavam ocupando. Um registry organizado também é mais fácil de raciocinar e mais barato de reescanear.
Provenance, attestations e SBOMs
Uma assinatura diz a você que uma image é autêntica. A provenance diz de onde ela veio e como foi feita. Armazenar attestations de provenance de build junto da image, seguindo um framework como o SLSA, permite que um consumidor verifique qual pipeline construiu o artefato, a partir de qual revisão de código-fonte e com quais insumos.
Armazene também uma software bill of materials junto de cada image. Um SBOM enumera os componentes dentro da image, e quando ele reside no registry ao lado do artefato que descreve, seus scanners e engines de política conseguem responder "quais das minhas imagens contêm este componente recém-vulnerável?" em segundos, em vez de em uma tarde frenética. É aqui que a higiene de registry encontra a análise de composição de software: o SBOM é o artefato compartilhado do qual ambas as disciplinas dependem.
Segredos: mantenha-os fora das imagens e proteja as credenciais do registry
Duas falhas de manejo de segredos se agrupam em torno dos registries. A primeira é embutir segredos nas imagens. Segredos de build, chaves de nuvem e tokens copiados para uma camada não desaparecem quando uma camada posterior os remove, e uma vez que essa image esteja em um registry, qualquer pessoa que possa fazer pull dela pode desenterrá-los. Use secret mounts de build-time que não persistem, e referencie segredos de runtime a partir de um gerenciador de segredos em vez de embuti-los.
A segunda é o mau manejo das próprias credenciais do registry. O pull secret que um cluster usa para autenticar-se no registry é ele próprio sensível; restrinja-o somente a pull, armazene-o como um segredo gerenciado em vez de em manifests em texto plano, e faça a sua rotação. Uma credencial de pull somente leitura que vaza é muito menos danosa do que uma com capacidade de push.
Auditoria e logging
Por fim, torne o registry observável. Registre em log cada push, pull, mutação de tag e mudança de permissão, envie esses logs ao seu monitoramento central e alerte sobre os padrões que sinalizam problemas: um push a partir de uma identidade inesperada, um pull de uma image em quarentena, um pico repentino de pulls de uma tag antiga, uma tempestade de falhas de autenticação. Bons logs transformam um incidente de mistério em linha do tempo, e muitas vezes são o que informa a você que uma chave de assinatura ou uma credencial robot foi abusada antes que dano real seja causado.
Como a Rainforest ajuda
Proteger um registry é um trabalho em camadas, e a Rainforest foi construída para cobrir essas camadas sem pedir que você costure uma dúzia de ferramentas pontuais. Nossa plataforma faz a varredura de imagens em busca de vulnerabilidades e configurações incorretas onde quer que elas residam, gera e rastreia SBOMs para que você sempre saiba o que há dentro dos seus artefatos, e permite que você defina e imponha políticas — como bloquear itens críticos ou exigir uma assinatura válida — como um gate consistente ao longo do seu pipeline e do seu registry. Como o reescaneamento é contínuo, uma image que estava limpa no momento do build é rejulgada à medida que novas CVEs surgem, e as imagens afetadas vêm à tona antes de chegarem à produção. Você pode ver como isso se encaixa em um programa mais amplo na nossa página de segurança de containers.
Se você quiser ver a varredura de registry e a imposição de políticas funcionando contra as suas próprias imagens, agende uma demonstração e nós a percorreremos juntos.
