O problema que não melhora
Dados divulgados pelo GitHub revelam um cenário preocupante sobre a gestão de credenciais em repositórios de código. Em 2025, foram adicionados 28,65 milhões de segredos hardcoded em repositórios públicos do GitHub, um aumento de 34% em relação ao ano anterior. Mas o número mais alarmante é outro: 64% dos segredos válidos detectados em 2022 ainda estavam ativos e exploráveis em janeiro de 2026.
Isso significa que chaves de API, tokens de acesso e credenciais que foram expostas há quatro anos continuam funcionando. Não foram rotacionadas, não foram revogadas. Qualquer pessoa com acesso ao histórico do repositório pode utilizá-las.
O problema não se limita a tecnologias tradicionais. Pesquisadores da Hush Security também identificaram credenciais de MCP (Model Context Protocol) hardcoded em repositórios públicos, demonstrando que a exposição de segredos se estende a tecnologias emergentes de IA e automação.
Repositórios internos são piores
Um achado complementar torna o cenário ainda mais grave: repositórios internos são aproximadamente seis vezes mais propensos que repositórios públicos a conter segredos hardcoded. A lógica por trás disso é compreensível, embora perigosa. Desenvolvedores tratam repositórios internos como “seguros” e relaxam as práticas de segurança, inserindo credenciais diretamente no código para agilizar o desenvolvimento.
O problema é que repositórios internos não são blindados. Incidentes de exfiltração de código-fonte, funcionários que mudam de empresa e acessos indevidos por contas comprometidas podem expor esses segredos para fora da organização. Quando isso acontece, credenciais que nunca foram rotacionadas se tornam portas abertas para atacantes.
Novo recurso do GitHub Enterprise
Para ajudar organizações a dimensionar o problema, o GitHub lançou um novo recurso no Enterprise que oferece uma contagem completa de quem possui credenciais expostas em repositórios da organização. A funcionalidade se integra ao Secret Scanning, permitindo que equipes de segurança identifiquem não apenas quais segredos estão expostos, mas quem tem acesso a eles e há quanto tempo.
Esse tipo de visibilidade é o primeiro passo para remediar o problema. Sem saber quantas credenciais estão expostas e quem as controla, é impossível priorizar a rotação de forma racional.
Checklist prático para equipes de DevOps
Independentemente de usar o GitHub Enterprise ou não, toda equipe de desenvolvimento deveria implementar práticas básicas de higiene de credenciais:
- Secret scanning no CI/CD: configure ferramentas como GitHub Secret Scanning, GitLeaks ou TruffleHog para rodar automaticamente em cada push. Bloqueie merges que contenham segredos detectados.
- Rotação periódica: defina uma política de rotação para chaves de API e tokens de acesso. Credenciais de produção devem ser rotacionadas no máximo a cada 90 dias.
- Cofres de segredos: utilize AWS Secrets Manager, HashiCorp Vault ou Azure Key Vault para gerenciar credenciais. O código deve referenciar o cofre, nunca armazenar o valor diretamente.
- Pre-commit hooks: implemente hooks locais que detectem padrões de segredos antes que o commit sequer chegue ao repositório remoto.
- Auditoria retroativa: não basta proteger commits futuros. Revise o histórico do Git em busca de segredos antigos e revogue imediatamente qualquer credencial encontrada.
A negligência é o verdadeiro risco
O dado de 64% de segredos ainda ativos após quatro anos mostra que o problema principal não é técnico, e sim comportamental. As ferramentas de detecção existem, as práticas são bem documentadas, e os cofres de segredos estão amplamente disponíveis. O que falta é a disciplina de tratar rotação de credenciais como uma atividade operacional contínua, não como uma tarefa pontual após um incidente.
Para organizações que ainda não implementaram secret scanning automatizado em seus pipelines, o momento de começar é agora. O custo de configurar essas ferramentas é insignificante comparado ao risco de ter credenciais de produção expostas por anos sem que ninguém perceba.