Secrets vazados no GitHub: guia completo de prevenção e remediação para times de desenvolvimento

Por que startups vazam secrets com tanta frequência

Startups operam sob pressão de velocidade: MVPs precisam rodar em horas, não dias. Nesse contexto, arquivos .env são commitados por acidente, chaves de terceiros são coladas diretamente no código para um teste rápido e o repositório é tornado público sem uma revisão de histórico. O resultado é previsível: em 2023, o GitGuardian detectou mais de 10 milhões de secrets hardcoded em repositórios públicos do GitHub — um crescimento de 67% em dois anos.

Os vetores de vazamento mais comuns em startups são: (1) commit acidental de arquivo .env ou de configuração; (2) log de CI/CD que imprime variáveis de ambiente em texto puro; (3) histórico de git que preserva um secret mesmo após a remoção do arquivo; (4) fork de repositório privado que se torna público; (5) chave colada em comentário de pull request ou issue para depuração.

Um fator agravante é a herança cultural de tutoriais que ensinam a colar chaves diretamente no código para simplificar exemplos. Desenvolvedores júnior reproduzem esse padrão em produção sem perceber o risco. A ausência de revisões de segurança no processo de code review e a falta de automação de scanning completam o cenário.

O que acontece quando um secret é exposto

Bots rastreiam o GitHub em tempo real. Pesquisas mostram que secrets expostos em repositórios públicos são detectados por atores maliciosos em menos de 60 segundos após o push. Uma chave de AWS comprometida pode resultar em instâncias spot de GPU rodando mineração de criptomoeda, gerando faturas de dezenas de milhares de dólares antes que o time perceba o problema.

O impacto vai além do custo financeiro imediato. Uma chave de banco de dados exposta permite exfiltração completa de dados de clientes, abrindo passivo de LGPD com potencial de multa de até 2% do faturamento bruto, limitada a R$ 50 milhões por infração. Tokens de autenticação de terceiros (Stripe, Twilio, SendGrid) permitem fraude financeira, envio de spam em escala e acesso a dados de clientes da plataforma integrada.

Infostealers modernos como Raccoon e RedLine coletam ativamente arquivos .env de máquinas comprometidas de desenvolvedores. Um desenvolvedor com malware instalado pode vazar secrets de vários projetos simultaneamente, incluindo chaves que nunca chegaram ao repositório público.

Remediação: o que fazer quando o vazamento já ocorreu

A sequência de remediação deve ser executada na ordem certa. O erro mais comum é começar pela limpeza do repositório enquanto a chave ainda está ativa — isso desperdiça tempo enquanto o acesso indevido continua. A primeira ação é sempre revogar ou rotacionar a credencial no console do provedor, gerando uma nova chave e atualizando os sistemas que a utilizam.

Somente após a revogação, inicie a limpeza do histórico do Git. A ferramenta recomendada pelo próprio GitHub é o git-filter-repo, que reescreve o histórico de commits removendo o arquivo ou o conteúdo específico. O BFG Repo Cleaner é uma alternativa mais rápida para repositórios grandes. Após reescrever o histórico, é necessário um push forçado e, em repositórios com forks, contatar o suporte do GitHub para que o cache do Git seja limpo.

Auditar os logs de acesso da chave comprometida é etapa obrigatória, não opcional. No AWS, o CloudTrail registra todas as chamadas de API realizadas com aquela chave. No GCP, o Cloud Audit Log cumpre a mesma função. Examine o período desde a data do commit até a revogação e identifique IPs, regiões e ações executadas. Se detectar acesso não autorizado, eleve o incidente para resposta formal.

Prevenção: como estruturar um pipeline seguro de secrets

A camada mais próxima do desenvolvedor é o pre-commit hook. Com o framework pre-commit e o plugin Gitleaks (ou detect-secrets), o commit é bloqueado localmente se qualquer padrão de secret for detectado no diff. Isso elimina o vetor mais comum antes que o código sequer saia da máquina do desenvolvedor. A configuração leva menos de cinco minutos e pode ser distribuída via .pre-commit-config.yaml no repositório.

Na camada do repositório, o GitHub Secret Scanning está habilitado por padrão em repositórios públicos e identifica mais de 200 tipos de secrets de provedores parceiros, notificando o committer e o administrador do repositório. O GitHub Advanced Security adiciona o Push Protection, que bloqueia o push antes de o secret ser gravado no histórico — a proteção mais eficaz disponível nativamente na plataforma. Para organizações com GitHub Enterprise, o recurso cobre também repositórios privados.

Para secrets em pipelines de CI/CD, nunca use variáveis de ambiente em texto claro nos arquivos de workflow. Utilize GitHub Actions Secrets (criptografados em repouso com libsodium), AWS Secrets Manager com OIDC federation ou HashiCorp Vault com autenticação JWT. Esses mecanismos injetam o secret apenas no contexto de execução, sem que ele apareça em logs ou no código-fonte. Habilite o mascaramento automático de secrets nos logs do runner.

O princípio de least privilege deve guiar a criação de todas as chaves. Uma chave de API usada apenas para leitura de um bucket S3 específico não deve ter permissão de escrita nem acesso a outros serviços. Com IAM roles bem definidas e políticas de recursos com ARN explícito, o raio de explosão de um eventual vazamento é drasticamente reduzido. Implemente rotação automática com TTL curto (30–90 dias) para credenciais de longa duração.

Ferramentas e referências do ecossistema

O ecossistema de detecção de secrets é maduro e em grande parte gratuito. Gitleaks é open source, altamente configurável via TOML e disponível como action do GitHub. TruffleHog da Truffle Security oferece varredura de histórico completo e integração nativa com GitHub Actions, detectando secrets com alta precisão usando verificadores de entropia e regex. GitGuardian oferece uma camada SaaS com dashboard centralizado, ideal para equipes que gerenciam múltiplos repositórios.

As referências normativas fundamentais para esse tema são: OWASP Top 10 — A05:2021 Security Misconfiguration (que cobre exposição de credenciais), OWASP ASVS v4.0 seção 6.4 (Secret Management), e a documentação oficial do GitHub sobre Secret Scanning e Push Protection. O CWE-312 (Cleartext Storage of Sensitive Information) e CWE-798 (Use of Hard-coded Credentials) são as fraquezas catalogadas correspondentes.

A Decripte oferece AppSec e DevSecOps gerenciados para startups de todos os portes — do MEI ao Enterprise com mais de 100.000 colaboradores. Nossos serviços incluem gestão de exposição de secrets, revisão de pipelines de CI/CD, implantação de cofres de segredos e monitoramento contínuo de repositórios. Comece gratuitamente com o plano de Gestão de Ameaças ou conheça nossos planos completos em decripte.com.br/planos.

Boas práticas consolidadas: checklist para o time de desenvolvimento

Adotar um checklist operacional transforma práticas de segurança em hábito do time. O conjunto mínimo para qualquer startup que usa GitHub deve cobrir: (1) arquivo .gitignore configurado antes do primeiro commit, bloqueando .env, *.pem, *.key e diretórios de configuração local; (2) pre-commit hooks com Gitleaks ativos em todos os repositórios; (3) Push Protection habilitado na organização do GitHub; (4) zero secrets hardcoded — toda credencial referenciada por variável de ambiente ou cofre; (5) rotação trimestral de chaves de longa duração; (6) revisão de permissões de apps OAuth autorizados no GitHub da organização.

Para repositórios que já existem sem essas proteções, o ponto de partida é uma varredura completa do histórico com TruffleHog ou Gitleaks em modo de scan total (`--no-git` ou `--all-branches`). Essa auditoria inicial frequentemente revela secrets esquecidos de meses ou anos atrás. Cada achado deve ser tratado como um incidente ativo: revogar primeiro, limpar depois, documentar sempre.

A cultura de segurança é tão importante quanto a tecnologia. Times que discutem abertamente incidentes de segurança sem punição — usando blameless postmortems — aprendem mais rápido e constroem sistemas mais seguros. Inclua um tópico de AppSec em cada sprint retrospectiva e mantenha um canal dedicado a alertas de segurança integrado ao Slack ou Teams, alimentado pelos scanners automatizados.

Termos importantes

Secret (segredo de aplicação)

Qualquer dado sensível usado para autenticar ou autorizar acesso a um sistema: chaves de API, tokens OAuth, senhas de banco de dados, certificados privados, chaves de criptografia e credenciais de serviços de nuvem. Secrets não devem jamais ser armazenados em código-fonte ou histórico de versionamento.

Push Protection

Recurso do GitHub Secret Scanning que analisa o conteúdo de um push antes de gravá-lo no repositório. Se um padrão de secret reconhecido for detectado, o push é bloqueado e o desenvolvedor é notificado com instruções de remediação. Disponível nativamente para repositórios públicos e via GitHub Advanced Security para repositórios privados.

Least Privilege (mínimo privilégio)

Princípio de segurança que determina que cada chave, token ou credencial deve ter exatamente as permissões necessárias para sua função — nem mais, nem menos. Uma chave com least privilege corretamente aplicada, mesmo quando comprometida, limita o alcance do atacante ao escopo mínimo de acesso autorizado.

Reescrita de histórico Git (git-filter-repo)

Processo de modificação do histórico de commits de um repositório Git para remover arquivos, conteúdos ou padrões específicos de todos os commits em que aparecem. Diferente de um commit de remoção, a reescrita altera os hashes de todos os commits subsequentes e exige push forçado. É a única forma de remover um secret do histórico de forma efetiva — mas não substitui a revogação da chave.

Por onde começar

1. Revogar ou rotacionar a chave comprometida imediatamente: Acesse o console do provedor (AWS IAM, Stripe Dashboard, GitHub Settings > Developer Applications etc.) e revogue a chave exposta ou gere uma nova, invalidando a anterior. Isso deve ocorrer antes de qualquer outra ação — enquanto a chave está ativa, o acesso indevido continua independentemente do que você faça no repositório.
2. Atualizar todos os sistemas que usavam a chave comprometida: Identifique todos os ambientes (produção, staging, CI/CD, scripts locais) que dependem da chave revogada e atualize-os com a nova credencial. Verifique variáveis de ambiente no servidor, secrets do GitHub Actions, configurações do Kubernetes e quaisquer outros locais onde a chave estava referenciada.
3. Auditar os logs de acesso da chave comprometida: No AWS, consulte o CloudTrail filtrando pelo Access Key ID da chave revogada. No GCP, use o Cloud Audit Log. No GitHub, verifique o Token Log do aplicativo OAuth. Documente todos os IPs de origem, timestamps e ações executadas. Se identificar atividade anômala, eleve para resposta a incidente formal e preserve as evidências.
4. Reescrever o histórico do Git para remover o secret: Use o git-filter-repo para reescrever o histórico: `git filter-repo --path-glob '*.env' --invert-paths` (para remover o arquivo inteiro) ou `--replace-text` para substituir o valor específico. Após a reescrita, realize um push forçado em todas as branches: `git push --force --all`. Avise os colaboradores para que façam novo clone do repositório.
5. Solicitar limpeza de cache ao GitHub e verificar forks: Após o push forçado, abra um ticket com o suporte do GitHub para garantir que o cache de objetos Git seja limpo. Verifique se existem forks públicos do repositório que possam ter preservado o histórico com o secret. Para repositórios públicos, considere que o secret deve ser tratado como permanentemente comprometido, mesmo após a limpeza.
6. Habilitar Secret Scanning e Push Protection no repositório: Nas configurações do repositório, acesse Security > Code security and analysis e habilite Secret Scanning e Push Protection. Para organizações, habilite globalmente em Organization Settings > Code security. Configure alertas por e-mail para administradores e, se disponível, webhooks para integração com o canal de segurança do time.
7. Realizar postmortem e atualizar os processos do time: Conduza um blameless postmortem documentando: como o secret vazou, quanto tempo ficou exposto, qual foi o impacto real e potencial, e quais controles preventivos estavam ausentes. Atualize o runbook de segurança do time com as lições aprendidas. Implemente os controles faltantes (pre-commit hooks, cofre de secrets, .gitignore revisado) antes de fechar o incidente.

Perguntas frequentes