Para quem é este artigo: desenvolvedores que mantêm código em repositórios públicos, como o GitHub, e empresas que operam APIs. Este artigo reapresenta os números de um estudo de uma empresa de segurança com as palavras deste site. Ele não explica como encontrar credenciais de terceiros.
O que é este estudo (não é um estudo oficial do GitHub)
Em 29 de setembro de 2026, a Truffle Security, uma empresa de segurança que vende ferramentas de detecção de segredos, publicou um estudo sobre credenciais deixadas em repositórios públicos. Como fornecedora de ferramentas de detecção, a publicadora tem interesse comercial no tema. Este artigo usa os números do estudo conforme divulgados e marca separadamente a interpretação deste site.
O GitHub não vazou nada. As credenciais foram escritas no código e publicadas pelos proprietários de cada repositório. O papel do GitHub é oferecer recursos de prevenção, como a proteção de push (que bloqueia envios que contenham segredos), e, como mostrado abaixo, esses recursos cobrem um conjunto limitado de tipos.
Como o estudo funcionou e como ler os números
- Os dados de origem são o The Stack v3, um conjunto de dados de repositórios públicos coletados por terceiros para treinar LLMs (modelos de linguagem de grande porte). A coleta foi encerrada em 7 de agosto de 2025.
- Apenas o branch padrão (como main) no momento da coleta foi examinado. Commits antigos, outros branches e o que foi removido antes não estão incluídos. Não se trata de uma varredura de todo o código público do GitHub.
- “Ativa” significa que o provedor confirmou que a credencial ainda autenticava em 27–28 de julho de 2026. Algumas podem ter sido revogadas desde então.
- O tempo desde a exposição é contado a partir da data da última modificação do arquivo que contém a credencial. O estudo observa que isso tende a subestimar a idade real.
- Alguns tipos ficam de fora de certos números. As chaves de API do Google foram testadas apenas com o Gemini, e as chaves privadas não podem ser testadas sem o host a que pertencem, por isso nenhuma delas está incluída nos índices de sobrevivência por tipo.
Os números: o que sobrou e quanto
Na semana de 29 de fevereiro de 2024, o GitHub começou a ativar por padrão a proteção de push para envios a repositórios públicos, para todos os usuários. Segundo o estudo, 199.843 (36,8%) das 543.699 credenciais ativas apareceram depois dessa data.
Além disso, 51,8% das credenciais ativas eram strings de conexão, chaves de API do Google ou chaves privadas, tipos que a proteção de push não bloqueia por padrão. Para os tipos que a proteção de push cobre, o número de vazamentos por milhão de arquivos caiu cerca de 53% ao comparar os 12 meses antes e depois da mudança. Os tipos que ela não cobre caíram apenas cerca de 7%. O próprio estudo observa que outros fatores podem estar misturados, como provedores de nuvem incentivando clientes a usar credenciais de curta duração no mesmo período.
Quantas sobreviveram, por tipo
A tabela abaixo recalcula os percentuais a partir das contagens publicadas no estudo. “Encontradas” é o número de credenciais encontradas nos branches padrão; “Ativas” é quantas ainda autenticavam no momento do teste.
| Tipo | Encontradas | Ativas | Parcela ativa |
|---|---|---|---|
| Tokens do npm | 101.886 | 1 | 0,001% |
| Tokens do Hugging Face | 30.437 | 15 | 0,05% |
| Tokens do GitHub | 73.048 | 260 | 0,4% |
| Tokens do Slack | 8.903 | 198 | 2,2% |
| Chaves do Stripe (incluindo chaves de modo de teste) | 124.132 | 4.493 | 3,6% |
| Chaves de acesso da AWS | 82.411 | 6.819 | 8,3% |
| Tokens do Docker Hub | 3.790 | 1.244 | 32,8% |
| Chaves do SendGrid | 22.800 | 9.189 | 40,3% |
| Chaves de conta de serviço do Google Cloud | 126.963 | 69.041 | 54,4% |
| Strings de conexão do MySQL | 2.421 | 1.806 | 74,6% |
| Strings de conexão do PostgreSQL | 12.985 | 11.465 | 88,3% |
| Strings de conexão do MongoDB | Não contabilizadas | 51.067 | — |
O detector usado para o MongoDB registra apenas as strings com as quais conseguiu se conectar, por isso não é possível calcular nenhuma parcela e o tipo fica de fora dos índices de sobrevivência. Apenas a contagem de ativas é informada.
Por que os tipos diferem tanto
A diferença se deve menos à facilidade de encontrar as credenciais e mais ao fato de alguém interrompê-las depois de encontradas. Dentro do que pudemos confirmar na documentação oficial de cada provedor, o quadro é o seguinte.
O emissor as interrompe automaticamente
- Tokens do GitHub: o GitHub documenta que tokens válidos enviados a um repositório público ou gist são revogados automaticamente
- Tokens do npm: desde 2019, o npm revoga tokens válidos encontrados via GitHub e envia um e-mail ao proprietário
- Hugging Face: um mecanismo oficial permite que qualquer pessoa, e não apenas o proprietário, invalide um token vazado
Só você pode interrompê-las
- Strings de conexão de banco de dados: não há emissor; elas funcionam até que você troque a senha
- Muitas chaves de API: o que o emissor faz depois que o GitHub o notifica depende dele
- Chaves privadas dos seus próprios servidores: só o proprietário sabe onde são usadas
O programa de parceiros de detecção de segredos do GitHub notifica os emissores sobre credenciais encontradas em repositórios públicos. A documentação do GitHub recomenda tratar qualquer segredo que ele reporte como público e comprometido, mas deixa a implementação a cargo do emissor. O emissor decide se revoga, reemite ou entra em contato com o usuário.
Os dois provedores de nuvem respondem de formas que não equivalem a uma revogação completa.
- AWS: a AWS anexa uma política gerenciada chamada "AWSCompromisedKeyQuarantineV3" a um usuário do IAM cuja chave de acesso pode ter sido exposta. Ela nega certas ações, como iniciar instâncias ou alterar o IAM, mas não apaga a chave. A AWS pede aos clientes que não removam a política e que sigam as instruções do caso de suporte que ela abre.
- Google Cloud: desde 16 de junho de 2024, chaves de contas de serviço detectadas em locais como repositórios públicos são desativadas automaticamente por padrão. As organizações podem optar por não participar (
WAIT_FOR_ABUSE) com a restrição de política da organizaçãoiam.serviceAccountKeyExposureResponse. O estudo ainda encontrou mais da metade ativa; ele não explica por quê.
Visão deste site: apagar deixa cópias em outros lugares
O próprio estudo usou um conjunto de dados montado em agosto de 2025. Se um proprietário apagou um arquivo depois disso, a credencial continua no conjunto de dados. O mesmo vale para forks, clones de outras pessoas, espelhos e dados de busca ou de treinamento de IA.
Por isso, trate “enviado a um repositório público” como “vazado” e invalide a credencial do lado do emissor. Reescrever o histórico é uma limpeza para impedir a disseminação adicional.
Seu repositório
Apagar ou reescrever o histórico
Forks, clones, espelhos
Nas máquinas de outras pessoas
Conjuntos de dados, arquivos
Cópias do momento da coleta
Revogada pelo emissor
Toda cópia deixa de funcionar
Se você descobrir que vazou uma
Revogue a chave junto ao emissor
Verifique uso e cobranças
Emita uma nova chave e substitua
Limpe o histórico por último
Se você encontrar a chave de outra pessoa, não a teste
Se você encontrar uma credencial em um repositório de outra pessoa, não verifique se ela funciona. Avise o proprietário ou o emissor. Para os tipos suportados em repositórios públicos do GitHub, o GitHub notifica o emissor.
Como prevenir vazamentos
A proteção de push ajuda, mas não basta por si só. Como os números mostram, os tipos que ela não bloqueia por padrão passam direto, e os usuários podem contornar um bloqueio escolhendo um motivo. Combine-a com o que segue.
- Varra antes de fazer commit: impeça segredos na sua própria máquina, antes do envio, com um scanner como o gitleaks (veja impedir segredos antes do commit com o gitleaks).
- Varra o histórico de repositórios antigos: a proteção de push não faz nada em commits feitos antes de ser ativada. Varra o histórico completo de repositórios abandonados e arquivados pelo menos uma vez.
- Use credenciais de curta duração: as GitHub Actions podem se conectar à AWS ou ao Google Cloud com OIDC (recebendo uma credencial válida apenas por pouco tempo em cada execução), em vez de armazenar uma chave de longa duração. O Hugging Face oferece a mesma abordagem.
- Restrinja o que cada chave pode fazer: somente leitura, apenas APIs específicas, restrições de IP de origem ou de referenciador e uma data de expiração. Isso limita o que um vazamento pode lhe custar.
- Mantenha os bancos de dados fora da internet: uma string de conexão vazada é inútil se não puder ser acessada de fora. As strings de conexão de banco de dados foram o tipo de maior duração na tabela.
Os fundamentos para manter segredos fora do código estão em o que é realmente perigoso em .env e chaves de API, e segredos deixados em servidores web são tratados em auditoria de diretórios públicos.
Para empresas que operam APIs
O que separou o topo da tabela da base foi se o emissor interrompe automaticamente as chaves vazadas. Como responsável pela proteção das chaves dos seus usuários, considere:
- Aderir ao programa de parceiros de detecção de segredos do GitHub e revogar chaves válidas e notificar os usuários quando for notificado
- Dar às chaves um prefixo distintivo (por exemplo, que comece com o nome do seu serviço) para que sejam fáceis de detectar
- Oferecer um canal ou uma API pelos quais qualquer pessoa possa reportar e invalidar uma chave vazada
- Tornar chaves com expiração e chaves com escopo restrito o padrão
Fontes (registros públicos)
Os números deste artigo vêm das fontes públicas abaixo. Não reproduzimos o texto nem os gráficos do estudo; usamos apenas suas contagens e as reorganizamos.
- Estudo da Truffle Security (fornecedora de ferramentas de detecção de segredos), 29 de setembro de 2026 — trufflesecurity.com
- Cobertura: BleepingComputer (30 de setembro de 2026) / SecurityWeek (1 de outubro de 2026) / GIGAZINE (2 de outubro de 2026, em japonês)
- GitHub: proteção de push ativada por padrão (GitHub Blog) / Sobre a proteção de push / Padrões suportados / Programa de parceiros / Expiração e revogação de tokens
- npm: Blog do npm (18 de junho de 2019)
- Hugging Face: Tokens de acesso de usuário (revogando um token vazado)
- AWS: AWSCompromisedKeyQuarantineV3
- Google Cloud: Desativação automática de chaves de contas de serviço vazadas (16 de maio de 2024) / Melhores práticas para gerenciar chaves de contas de serviço
Leia a seguir
- Um caso do mesmo período em que cerca de 4.800 contas do GitHub foram usadas indevidamente com tokens roubados: Segredos de CI e credenciais de nuvem roubados (novembro de 2026)
- Configurações do GitHub: Como configurar a autenticação de dois fatores no GitHub
- Prevenção: Impedir segredos antes do commit com o gitleaks / Verificador de vazamento de segredos (cole para analisar)
- Fundamentos: O que é realmente perigoso em .env e chaves de API / O que é um arquivo .env
- O que um vazamento pode custar: Código escrito por IA vazou uma chave de API e gerou cobranças fraudulentas
- Ataques que têm como alvo credenciais de desenvolvedores: Como se defender de worms da cadeia de suprimentos / A cadeia de comprometimento de TanStack, Nx Console e GitHub (maio de 2026)
- Restringir permissões de chaves: Privilégio mínimo para chaves SSH