543 mil credenciais ativas no GitHub ainda funcionam

Um estudo da Truffle Security identificou 543.699 credenciais únicas que ainda conseguiam autenticar quando foram verificadas, em 27 e 28 de julho de 2026, apesar de terem sido encontradas em dados públicos derivados de repositórios do GitHub. Mais do que mostrar um problema de desenvolvimento seguro, o levantamento expõe uma lacuna operacional: detectar um segredo, remover um arquivo ou fechar um alerta não significa que o acesso tenha deixado de existir.

A pesquisa, repercutida pelo GBHackers e publicada originalmente pela Truffle Security, analisou o conjunto de dados The Stack v3, que reúne uma grande amostra de repositórios públicos utilizada em pesquisas e treinamento de modelos. Os pesquisadores não se limitaram a procurar padrões semelhantes a chaves ou tokens: os candidatos foram testados contra os serviços emissores para verificar se ainda funcionavam. O resultado foi de 1.103.438 exposições correspondentes a 543.699 credenciais únicas ainda válidas.

O problema não termina quando o segredo é encontrado

Em segurança de software, a primeira reação diante de uma chave de API, token, senha de banco de dados ou credencial de cloud exposta costuma ser remover o valor do código. Essa ação é necessária, mas não encerra o incidente. Uma credencial publicada pode ter sido copiada por bots, indexadores, clones, forks, caches, datasets ou por qualquer pessoa que tenha acessado o conteúdo enquanto ele estava disponível. Depois disso, apagar o arquivo ou criar um novo commit elimina apenas a evidência visível no estado atual do repositório; não invalida a identidade que continua sendo aceita pelo serviço de destino.

A própria documentação do GitHub orienta considerar qualquer segredo vazado como imediatamente comprometido e priorizar sua revogação. A recomendação é explícita: remover o segredo do código, adicionar um novo commit ou até excluir e recriar o repositório não impede que uma credencial já copiada continue sendo utilizada. O incidente só começa a ser efetivamente contido quando o segredo antigo deixa de autenticar.

Credenciais permaneceram válidas por anos

O tempo de sobrevivência encontrado na pesquisa ajuda a dimensionar essa diferença entre exposição e remediação. A idade mediana das credenciais ainda funcionais foi de 784 dias; no percentil 90, o valor chegou a 6,3 anos. A credencial mais antiga estava associada a um arquivo modificado havia aproximadamente 16,1 anos. Segundo a Truffle Security, 2.636 credenciais válidas vinham de arquivos modificados antes de 2015.

Esses números não significam que todas as credenciais tenham permanecido publicamente visíveis por exatamente esse período. O conjunto The Stack v3 preserva o branch padrão e não mantém todo o histórico de commits, por isso a pesquisa utiliza a última modificação do arquivo como aproximação da data de exposição. Ainda assim, o fato decisivo permanece: em julho de 2026, as credenciais testadas continuavam sendo aceitas pelos serviços emissores.

O risco real depende do que existe atrás da credencial

Uma string exposta em um repositório não é, por si só, equivalente a um comprometimento completo. O risco depende do tipo de credencial, dos privilégios concedidos, das restrições de origem, da existência de controles adicionais e dos recursos acessíveis. Mas, quando uma credencial ainda é válida, ela oferece ao atacante algo particularmente valioso: uma forma de tentar acessar um serviço com uma identidade legítima, muitas vezes sem precisar explorar uma vulnerabilidade de software.

Isso pode significar acesso a buckets e serviços de cloud, bancos de dados, APIs pagas, plataformas SaaS, serviços de mensageria, sistemas de desenvolvimento, registries, pipelines de CI/CD ou serviços de inteligência artificial. O impacto pode variar de consumo indevido e fraude até exfiltração de dados, alteração de infraestrutura, movimentação lateral e comprometimento de cadeia de desenvolvimento, dependendo das permissões associadas.

O Blog já mostrou um recorte específico desse problema na notícia “Milhares de credenciais AWS vazadas continuam ativas”. O novo estudo amplia o cenário para múltiplos provedores e tipos de segredo. Os resultados não devem ser comparados diretamente como se representassem a mesma amostra, mas apontam para a mesma fragilidade de fundo: credenciais técnicas podem sobreviver por muito mais tempo do que a aplicação, o projeto ou o processo que originalmente justificou sua criação.

Notícias Relacionadas

Push protection reduz vazamentos, mas não substitui revogação

O estudo também oferece uma leitura importante sobre os controles preventivos do GitHub. O secret scanning passou a ser gratuito para repositórios públicos em 2023, e a proteção de push para usuários passou a bloquear por padrão credenciais suportadas antes que sejam enviadas a repositórios públicos. Ainda assim, os pesquisadores contabilizaram 199.843 credenciais válidas associadas ao período posterior à adoção dessa proteção como padrão.

Esse dado não deve ser interpretado como prova de que a proteção de push “não funciona”. O mecanismo bloqueia segredos suportados pelos padrões de detecção, e o próprio GitHub documenta situações de bypass e limitações para determinados formatos ou versões de tokens. Na amostra da Truffle Security, 51,8% das credenciais ainda válidas pertenciam a formatos que não eram bloqueados pela proteção padrão analisada. Entre os exemplos estavam strings de conexão de bancos de dados, chaves privadas e determinadas chaves de API.

Ao mesmo tempo, houve evidência de benefício preventivo: famílias de credenciais cobertas pela proteção tiveram redução muito maior de novas exposições após a implementação do controle do que tipos não cobertos. A mensagem operacional, portanto, não é abandonar secret scanning ou push protection, mas entender sua função correta. Eles ajudam a evitar e detectar vazamentos; revogação, rotação e resposta a incidentes tratam o risco depois que o segredo já escapou.

A diferença entre provedores mostra o valor da revogação automática

Um dos achados mais reveladores está na diferença de sobrevivência entre tipos de credenciais. A Truffle Security encontrou 101.886 tokens npm comprometidos na amostra, mas apenas um permanecia válido. Tokens do próprio GitHub apresentaram taxa de sobrevivência de 0,36%, e tokens do Hugging Face, 0,05%. Em contraste, 88% das URIs PostgreSQL testadas e 75% das URIs MySQL ainda funcionavam; chaves de contas de serviço do Google Cloud chegaram a 54%, enquanto chaves SendGrid ficaram em 40%.

Esses percentuais pertencem ao conjunto analisado e não devem ser generalizados automaticamente para toda a Internet. Mas eles mostram uma diferença arquitetural relevante: quando o provedor consegue receber um sinal confiável de comprometimento e invalidar rapidamente a credencial, o tempo de exposição efetiva pode cair drasticamente. Quando a remediação depende exclusivamente de alguém perceber o alerta, localizar o proprietário, avaliar dependências e executar manualmente a rotação, o segredo pode continuar funcionando por meses ou anos.

Do repositório ao impacto no negócio

Para a empresa, o risco não está apenas no vazamento do código. Uma credencial ativa pode gerar custos de consumo em cloud e inteligência artificial, permitir acesso a dados protegidos, abrir caminho para alterações em infraestrutura ou ser usada como ponto inicial de uma intrusão mais ampla. A notícia do Blog sobre LLMjacking mostrou exatamente como chaves e credenciais roubadas podem ser convertidas em consumo de serviços de IA pago pela vítima. Em outro contexto, tokens de identidade na nuvem demonstram que a mesma discussão se estende para artefatos capazes de representar sessões e identidades já autenticadas.

Há também impacto de governança. Uma credencial sem proprietário conhecido, criada para uma integração antiga e ainda válida anos depois, é um ativo de acesso fora do ciclo normal de IAM. Isso dificulta auditorias, amplia privilégios invisíveis e cria uma espécie de dívida de identidade: a empresa mantém acessos que já não consegue explicar claramente, mas que continuam tecnicamente utilizáveis.

Como reduzir o risco de segredos expostos

Revogar ou rotacionar antes de limpar o histórico

Quando uma credencial real aparece em um repositório público, a prioridade deve ser invalidá-la no serviço emissor. Somente depois disso faz sentido concentrar esforços em remover o segredo do código e, quando necessário, do histórico Git. Essa ordem reduz a janela em que uma cópia já coletada continua útil para um atacante.

Investigar o período de exposição

A rotação contém o acesso futuro, mas não responde se a credencial foi utilizada antes da descoberta. Logs de autenticação, trilhas de auditoria, eventos de cloud, consultas a banco, consumo de APIs e alterações de infraestrutura devem ser revisados de acordo com o alcance da identidade comprometida. Credenciais privilegiadas ou com acesso a dados sensíveis devem ser tratadas como incidentes com prioridade proporcional ao potencial de impacto.

Bloquear segredos antes do commit e monitorar depois dele

Secret scanning, push protection, verificações pre-commit e controles no pipeline devem atuar em conjunto. O objetivo é reduzir a chance de a credencial entrar no repositório e, ao mesmo tempo, identificar segredos que tenham escapado do controle preventivo. Em organizações com muitos repositórios, esse processo precisa gerar responsáveis, prazos de tratamento e evidência de que a credencial foi de fato revogada — não apenas de que o alerta foi encerrado.

Preferir credenciais temporárias e identidades de workload

A estratégia mais robusta é reduzir a quantidade de segredos de longa duração que precisam ser armazenados. Credenciais temporárias, federação, OpenID Connect (OIDC), roles e identidades de workload limitam o valor de uma credencial copiada porque sua validade é curta e pode estar vinculada a contexto, origem ou finalidade específica. A OWASP também recomenda reduzir o impacto de roubo de secrets por meio de credenciais temporárias e controles de menor privilégio em ambientes CI/CD.

Aplicar menor privilégio e ownership claro

Toda credencial técnica deveria ter um proprietário, uma finalidade conhecida, permissões mínimas e um ciclo de vida definido. A mesma exposição produz consequências muito diferentes quando a chave pode apenas ler um recurso específico ou quando possui capacidade administrativa. Inventário, revisão periódica e expiração ajudam a impedir que segredos sobrevivam indefinidamente após a desativação do sistema que os utilizava.

Conclusão

O principal alerta do estudo não está apenas no número de credenciais encontradas, mas na distância entre detecção e remediação efetiva. Ferramentas modernas conseguem identificar muitos secrets e bloquear parte dos vazamentos antes do push, mas o risco continua existindo enquanto a credencial comprometida permanece aceita pelo sistema de destino.

Para equipes de DevSecOps, IAM, Cloud Security e resposta a incidentes, isso muda a pergunta operacional. Não basta saber quantos segredos foram encontrados em código; é preciso saber quantos foram revogados, quanto tempo levou a contenção, quais privilégios existiam atrás deles e se houve uso indevido antes da descoberta. Em um ambiente no qual identidades de máquinas, APIs e pipelines têm acesso direto a recursos críticos, fechar o alerta sem encerrar a credencial pode criar uma falsa sensação de segurança.