--- title: "Secret vazou no GitHub: o que fazer nas primeiras 24 horas" description: "Guia de resposta a incidente para chaves de API, tokens e senhas expostos no Git: revogar, investigar, limpar o histórico e evitar que aconteça de novo." url: "https://security.transitax.com/blog/vazamento-de-secrets-no-git" --- Resposta a incidentes # Secret vazou no GitHub: o que fazer nas primeiras 24 horas Guia de resposta a incidente para chaves de API, tokens e senhas expostos no Git: revogar, investigar, limpar o histórico e evitar que aconteça de novo. [Equipe de Pesquisa TransiTax Security](https://security.transitax.com/sobre#pesquisa)Publicado em 12 de agosto de 20265 min de leitura Resumo - Apagar o commit não resolve: trate todo secret exposto como comprometido e revogue primeiro. - Robôs varrem repositórios públicos continuamente; uma chave de nuvem pode ser usada em minutos após o push. - Depois de rotacionar, investigue os logs do provedor no período em que a chave ficou exposta. - Prevenção eficaz combina hook de pre commit, bloqueio no pull request e varredura do histórico completo. Neste artigo 1. [Primeiro: pare de pensar em apagar o commit](#primeiro-pare-de-pensar-em-apagar-o-commit) 2. [Hora 0 a 1: revogar e rotacionar](#hora-0-a-1-revogar-e-rotacionar) 3. [Hora 1 a 8: investigar o uso](#hora-1-a-8-investigar-o-uso) 4. [Hora 8 a 24: limpar e documentar](#hora-8-a-24-limpar-e-documentar) 5. [Como evitar que aconteça de novo](#como-evitar-que-aconteca-de-novo) 6. [Checklist rápido](#checklist-rapido) 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](#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](#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. | Tipo de secret | Onde revogar | Atenção | | --- | --- | --- | | Chave de acesso AWS | IAM, desativar e excluir a access key | Verifique também sessões temporárias criadas com ela | | Service principal Azure | Entra ID, remover o secret do app | Revise atribuições de papel do principal | | Chave de conta de serviço GCP | IAM, excluir a chave | Prefira identidade federada no lugar de chaves | | Token GitHub ou GitLab | Configurações do usuário ou do app | Revise repositórios e organizações acessíveis | | Chave de gateway de pagamento | Painel do gateway | Mercado Pago, PagSeguro e Pagar.me permitem gerar nova chave e invalidar a anterior | | Senha de banco de dados | Banco e aplicação | Reveja também regras de rede que expõem o banco | | Chave privada SSH ou TLS | Servidores e autoridade certificadora | Revogue certificados emitidos com a chave | ## [Hora 1 a 8: investigar o uso](#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](https://security.transitax.com/blog/lgpd-seguranca-de-aplicacoes). ## [Hora 8 a 24: limpar e documentar](#hora-8-a-24-limpar-e-documentar) Agora sim, remova o secret do histórico para que ele não seja encontrado novamente: ```bash # 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](https://security.transitax.com/conformidade/iso-27001), [SOC 2](https://security.transitax.com/conformidade/soc-2) e LGPD. ## [Como evitar que aconteça de novo](#como-evitar-que-aconteca-de-novo) A prevenção funciona em camadas, porque nenhuma é perfeita sozinha. ### [1\. Hook de pre commit na máquina do desenvolvedor](#1-hook-de-pre-commit-na-maquina-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](#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](https://security.transitax.com/funcionalidades/secrets) faz isso e ainda **valida se a chave é ativa**, para separar incidente real de chave de exemplo. ### [3\. Varredura do histórico completo](#3-varredura-do-historico-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](#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](https://security.transitax.com/funcionalidades/imagens-de-container) cobre esse caminho. ### [5\. Eliminar secrets de longa duração](#5-eliminar-secrets-de-longa-duracao) 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](#checklist-rapido) - [ ] 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 Quer ver isso rodando no seu código? Em 30 minutos mostramos a TransiTax Security num repositório seu, separando o que é explorável do que é ruído. [Falar com um especialista](https://security.transitax.com/contato) Escrito por Equipe de Pesquisa TransiTax Security Engenheiros de segurança de aplicações e de nuvem que acompanham registros de pacotes, bases de vulnerabilidades e técnicas de ataque. [Conheça a equipe](https://security.transitax.com/sobre#pesquisa). Neste artigo 1. [Primeiro: pare de pensar em apagar o commit](#primeiro-pare-de-pensar-em-apagar-o-commit) 2. [Hora 0 a 1: revogar e rotacionar](#hora-0-a-1-revogar-e-rotacionar) 3. [Hora 1 a 8: investigar o uso](#hora-1-a-8-investigar-o-uso) 4. [Hora 8 a 24: limpar e documentar](#hora-8-a-24-limpar-e-documentar) 5. [Como evitar que aconteça de novo](#como-evitar-que-aconteca-de-novo) 6. [Checklist rápido](#checklist-rapido) 7. [Perguntas frequentes](#perguntas-frequentes) ## Perguntas frequentes Respostas diretas às dúvidas mais comuns sobre o tema. ### Apagar o commit resolve o vazamento de uma chave? Não. A chave pode ter sido copiada por robôs, forks, clones e caches antes da remoção. O primeiro passo é sempre revogar e rotacionar a credencial. ### Em quanto tempo uma chave vazada no GitHub é explorada? Em repositórios públicos, credenciais de nuvem costumam ser testadas por automações em questão de minutos após o push. ### Repositório privado também precisa de detecção de secrets? Sim. Todas as pessoas e integrações com acesso ao repositório, atuais e passadas, podem ter visto o secret, e repositórios privados já foram expostos por engano ou por tokens vazados. ### Como saber se uma chave vazada foi usada? Consulte os logs de auditoria do provedor na janela entre o commit e a revogação, procurando IPs incomuns, criação de recursos, leitura de dados e custos anômalos. ### Preciso comunicar a ANPD se uma chave vazou? Só se o incidente envolver dados pessoais e puder causar risco ou dano relevante aos titulares. Nesse caso, o prazo previsto no regulamento da ANPD é de três dias úteis. ## Continue lendo - [O que é SAST: guia completo de análise estática de código16 de setembro de 2026Fundamentos](https://security.transitax.com/blog/o-que-e-sast) - [DevSecOps na prática: segurança no CI/CD sem travar o time6 de maio de 2026DevSecOps](https://security.transitax.com/blog/devsecops-pipeline-ci-cd) - [Pentest com IA: como funciona e quando substituir o pentest manual10 de setembro de 2026Pentest](https://security.transitax.com/blog/pentest-com-ia) ## Veja o que é explorável no seu código Em 30 minutos mostramos a plataforma num repositório seu, separamos o risco real do ruído e montamos uma proposta em reais. [Falar com um especialista](https://security.transitax.com/contato) Resposta em até 1 dia útil.