Quay: recuperar a confiança exige revisar as chaves
Um registro de containers precisa demonstrar quem autoriza o acesso às imagens. A recuperação proposta relaciona chaves confiadas, conteúdo publicado e decisões dos serviços que consomem esse conteúdo.
Read in EnglishPor Pentesty
O que as fontes confirmam
O aviso da Red Hat descreve a CVE-2026-123710 como crítica: um cliente não autenticado pode instalar uma chave de assinatura confiada e emitir tokens de acesso a qualquer repositório. O aviso orienta restringir o endpoint /keys e revisar eventos de rotação e exclusão de chaves. A exposição depende do alcance desse serviço por clientes não confiáveis.
A orientação pública da Red Hat esclarece que trocar senhas ou regenerar tokens de robôs não revoga uma chave indevida. Há uma alteração upstream de 11 de novembro que cita a correção do CVE; isso, isoladamente, não identifica uma versão instalada ou um pacote empresarial corrigido.
Desenhe o registro como uma relação de confiança
Proponha um mapa com três partes: quem administra a autoridade do registro, quem publica imagens e quem recebe o conteúdo. Em cada ligação, registre o serviço e a pessoa responsável. O desenho serve para organizar perguntas de aceite e evitar que uma equipe encerre a investigação com uma prova que outra equipe ainda precisa avaliar.
Considere uma aplicação interna que recebe uma nova imagem por uma rotina de entrega. No exercício proposto, a equipe precisa conseguir ligar a autorização de publicação ao conteúdo aprovado e à execução esperada. Se uma dessas relações ficar sem prova, registre a pendência junto do serviço que depende dela.
Nossa análise de tokens e confiança em imagens no Docker Hub complementa essa discussão. As situações técnicas são diferentes; use a relação entre autoridade, publicação e consumo para organizar a revisão do seu ambiente.
Preserve provas antes do aceite
A equipe de resposta deve definir a coleta e a autorização antes de modificar o ambiente. A ficha proposta reúne referências de chaves e eventos, sem guardar material privado no relatório compartilhado. Para cada registro, anote origem, horário, responsável pela coleta e a pergunta que ele pode responder.
Escolha um conjunto pequeno de imagens relevantes ao negócio. Registre qual aprovação sustenta cada versão, onde ela foi publicada e quais serviços a utilizaram no período examinado. Quando a associação não puder ser demonstrada, mantenha a incerteza visível. Uma ausência de registro exige investigação, sem ser convertida automaticamente em confirmação de uso indevido.
- Autoridade. Peça ao responsável pelo registro que revise a relação de chaves confiadas e documente a decisão sobre cada entrada examinada, com o motivo e as referências de suporte.
- Conteúdo. Associe cada imagem escolhida à sua aprovação e ao identificador observado. Preserve separadamente a conclusão sobre o conteúdo e a conclusão sobre quem podia publicá-lo.
- Consumidores. Solicite ao dono de cada aplicação a relação de versões efetivamente utilizadas no escopo. Registre quais serviços têm evidência suficiente e quais continuam aguardando verificação.
Teste o retorno em um caminho controlado
Depois de autorizada a recuperação, proponha um ensaio isolado com uma imagem inofensiva e um consumidor de teste. Defina previamente uma publicação permitida e uma ação que deve ser negada. Guarde os resultados e peça a um revisor que confira se eles correspondem às identidades e aos recursos previstos.
O aceite também deve mostrar qual mudança entrou em execução. A análise de correção no processo que atende o site oferece uma pergunta útil: a prova descreve algo disponível, instalado ou realmente ativo? Adapte essa pergunta ao registro, sem tomar o sucesso do ensaio como prova de ausência de comprometimento.
Se o teste falhar, preserve o resultado e encaminhe a divergência ao responsável correto. Evite acumular decisões informais durante a janela. Uma operação liberada precisa de escopo, condição de retorno e próximo responsável registrados.
Entregue uma decisão que os consumidores reconheçam
Ao final, cada serviço deve receber uma conclusão sobre o que pode voltar a usar e sob quais condições. Inclua a relação de imagens examinadas, as provas necessárias, as limitações e a próxima revisão. Isso permite distinguir uma liberação restrita de uma decisão que ainda depende de investigação.
Para avaliar o processo, entregue a um revisor uma ficha com uma imagem deliberadamente sem aprovação associada. O exercício é bem-sucedido quando essa lacuna impede o aceite daquele caminho e chega à pessoa capaz de resolvê-la. A qualidade da entrega está na rastreabilidade da decisão.
Perguntas frequentes
Trocar a senha elimina uma chave indevida?
A orientação da Red Hat diz que isso não revoga a chave de assinatura. A decisão de recuperação precisa incluir essa autoridade.
O commit upstream identifica o pacote instalado?
O commit é uma referência de alteração. A equipe ainda deve relacioná-lo ao produto, ao pacote e ao estado efetivamente observados.
Que imagem deve entrar primeiro no exercício?
Escolha com o responsável pelo negócio uma imagem de teste e um serviço de validação, sem dados reais nem consumidores de produção.
Qual evidência impede um encerramento prematuro?
Uma ficha que mantenha separados autoridade, conteúdo e consumidores, com uma conclusão própria para cada parte e responsáveis pelas lacunas.
Fontes e referências
- SecurityWeek: referência editorial de 12 de novembro
- Red Hat: aviso CVE-2026-123710
- Red Hat: orientação pública sobre o impacto nas imagens
- Quay: alteração upstream de 11 de novembro
Análise original da Pentesty, publicada em 12 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.