Os segredos não expiram quando você os exclui: limpando o histórico do Git

Em resumo: Uma chave API vazada e confirmada em um repositório permanece no histórico muito depois de o arquivo ser excluído. Detecção, rotação e reescrita do histórico são necessárias – a exclusão por si só é uma falsa sensação de segurança.

A armadilha de apagar e fazer commit

Quando um desenvolvedor percebe que enviou uma credencial ao repositório, o instinto é excluir a linha e publicar uma correção. Mas o segredo continua no histórico do Git, ao alcance de qualquer pessoa que tenha acesso a um clone. Se o repositório já foi público ou espelhado, presuma que o segredo foi comprometido no momento do envio.

A única suposição segura é que um segredo vazado é um segredo ativo até que seja rotacionado.

A verdadeira sequência de remediação

• Alterne a credencial imediatamente – trate-a como violada, e não apenas exposta.
• Revogar e auditar qualquer uso da chave vazada durante a janela de exposição.
• Reescreva o histórico para limpar o segredo de todos os commits acessíveis e espelhos de atualização forçada.
• Adicione varredura de segredos antes do commit e na CI para detectar o próximo vazamento antes que ele entre no histórico.

A detecção deve ser contínua

Vazamentos de segredos não exigem apenas uma limpeza pontual; são um problema de detecção contínua. A varredura feita somente no momento do commit perde segredos enviados por outros caminhos, enquanto a varredura apenas do histórico não detecta o erro de amanhã. As duas são necessárias.

As varreduras do KENSAI revelam credenciais expostas com o contexto necessário para priorizar a rotação: qual chave vazou, onde ela está acessível e qual é a urgência da exposição.

Como é uma boa higiene na prática

Trate todos os segredos que já tocaram um repositório como já expostos e projete de forma que a exposição possa sobreviver. Credenciais de curta duração e rotacionadas automaticamente transformam uma chave vazada em um problema que expira por conta própria, em vez de uma porta aberta que permanece aberta por meses.

Antecipe a detecção com hooks de pre-commit e pre-receive que bloqueiam um segredo antes que ele seja registrado e combine-os com a varredura no servidor para capturar o que escapar. O objetivo não é uma limpeza isolada, mas um controle permanente que torne novos vazamentos raros, visíveis e rápidos de revogar.

Conclusão

Excluir um segredo vazado é a etapa menos importante. Gire primeiro, limpe o histórico depois e coloque a detecção contínua no lugar para que as janelas de exposição diminuam em vez de se repetirem.