Secret vazou no GitHub: o que fazer nas primeiras 24 horas

Chaves de API, tokens de acesso e senhas no código são uma das causas mais comuns de incidentes graves, e também uma das mais evitáveis. Casos públicos não faltam: credenciais em repositórios deram acesso a dados de dezenas de milhões de usuários em grandes empresas de tecnologia, e já houve chave de acesso esquecida num repositório público por cinco anos antes de alguém notar.

Se você acabou de descobrir que um secret foi para o Git, este é o roteiro. A ordem importa.

Primeiro: pare de pensar em apagar o commit

A reação instintiva é reescrever o histórico e fazer um force push. Isso é necessário depois, mas não resolve o problema, por três motivos:

1. Robôs chegaram antes de você. Repositórios públicos são monitorados continuamente por automações que procuram credenciais. Chaves de nuvem expostas costumam ser testadas em minutos.
2. Cópias existem. Forks, clones locais de colegas, caches de CI, espelhos e ferramentas de terceiros guardam o valor.
3. Repositório privado não é cofre. Qualquer pessoa com acesso de leitura, atual ou passada, e qualquer integração com permissão ao repositório viu o secret.

A regra é simples: todo secret que entrou no Git está comprometido.

Hora 0 a 1: revogar e rotacionar

1. Identifique exatamente o que vazou: qual serviço, qual conta, quais permissões aquela credencial tem.
2. Crie a credencial nova e atualize os sistemas que dependem dela, idealmente num gerenciador de segredos (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, Doppler).
3. Revogue a credencial antiga. Não desative apenas: revogue.
4. Confirme que a antiga não funciona mais. Um teste simples de autenticação com a chave revogada deve falhar.

Se a rotação imediata derrubaria produção, pelo menos reduza as permissões da credencial vazada ao mínimo enquanto prepara a troca.

Hora 1 a 8: investigar o uso

Com a porta fechada, descubra se alguém entrou por ela enquanto estava aberta.

• Defina a janela de exposição: do commit que introduziu o secret até a revogação. Use git log -S "trecho do secret" para achar o commit original.
• Consulte os logs do provedor nesse período: CloudTrail na AWS, Activity Log e logs de entrada no Azure, Cloud Audit Logs no Google Cloud, logs de auditoria do GitHub e do gateway de pagamento.
• Procure sinais típicos de abuso: chamadas de regiões ou IPs incomuns, criação de usuários ou chaves novas, máquinas criadas para mineração, leitura em massa de buckets, transferências ou estornos incomuns.
• Verifique custos anômalos. Mineração de criptomoeda com credenciais vazadas costuma aparecer primeiro na fatura.

Se encontrar uso indevido que envolva dados pessoais, avalie a obrigação de comunicar o incidente à ANPD e aos titulares. O regulamento da ANPD prevê prazo de três dias úteis a partir do conhecimento do incidente, quando ele puder acarretar risco ou dano relevante. Falamos sobre isso em LGPD para times de engenharia.

Hora 8 a 24: limpar e documentar

Agora sim, remova o secret do histórico para que ele não seja encontrado novamente:

# Instale o git filter repo e liste os valores a remover em um arquivo
git filter-repo --replace-text segredos-para-remover.txt

# Force push em todas as branches e tags, depois peça aos colegas para clonar de novo
git push --force --all
git push --force --tags

Depois:

• Peça ao provedor Git a limpeza de caches e referências de pull requests, quando aplicável.
• Invalide caches de CI que possam conter o valor.
• Registre o incidente: o que vazou, quando, como foi detectado, janela de exposição, impacto e ações tomadas. Esse registro é evidência para ISO 27001, SOC 2 e LGPD.

Como evitar que aconteça de novo

A prevenção funciona em camadas, porque nenhuma é perfeita sozinha.

1. Hook de pre commit na máquina do desenvolvedor

Bloqueia o secret antes mesmo do commit. É a camada mais barata, mas depende de instalação em cada máquina e pode ser contornada.

2. Bloqueio no push e no pull request

Uma verificação no servidor, que ninguém consegue pular, rejeita o push ou falha o status check do PR quando encontra uma credencial. A detecção de secrets da TransiTax Security faz isso e ainda valida se a chave é ativa, para separar incidente real de chave de exemplo.

3. Varredura do histórico completo

Secrets antigos continuam comprometidos. Na primeira conexão de um repositório, varra todos os commits de todas as branches.

4. Imagens de container e artefatos

Secrets também vazam em camadas de imagens Docker, arquivos .env copiados no build e logs de CI. A análise de imagens de container cobre esse caminho.

5. Eliminar secrets de longa duração

A melhor credencial é a que não existe. Prefira identidade federada (OIDC) para pipelines de CI acessarem a nuvem, papéis temporários no lugar de chaves estáticas e gerenciadores de segredos com rotação automática.

Checklist rápido

• Credencial revogada e confirmada como inválida
• Nova credencial em gerenciador de segredos
• Logs do provedor analisados na janela de exposição
• Avaliação de comunicação à ANPD, se houver dado pessoal envolvido
• Histórico do Git limpo e caches invalidados
• Incidente documentado
• Bloqueio de secrets ativo no pull request