O GitHub apresentou em 13 de outubro de 2026 um classificador de segredos sensível a contexto, treinado para separar credenciais reais de strings que apenas se parecem com elas. O trabalho é assinado pelos pesquisadores Batu Ozturkler e Shengyu Fu e descreve um modelo compacto que elevou em 11,5% a aceitação ponderada dos alertas pelos donos de repositórios, reduziu em 86% o tempo mediano de execução da varredura pós-push e cortou mais de 98% dos custos de serviço em comparação com o pipeline anterior, baseado em chamadas a LLMs.
A varredura de segredos do GitHub opera em dois momentos. A proteção de push analisa as mudanças antes que o envio seja aceito, dando ao desenvolvedor a chance de tratar o achado antes que a credencial entre no repositório.
Já a varredura pós-push age depois do commit, examinando continuamente o conteúdo e gerando alertas para que desenvolvedores e times de segurança investiguem e corrijam. O equilíbrio é difícil: detectar de menos deixa credenciais reais no código; alertar demais faz as pessoas gastarem tempo com strings que não são segredos.
Um classificador compacto no lugar de LLMs remotos
Segundo o GitHub, a eficiência do novo classificador sensível a contexto tornou viável estender a detecção genérica de segredos também à proteção de push, devolvendo resultados antes do envio das mudanças, e não só depois que o código foi commitado. A empresa afirma que o modelo é pequeno e barato de rodar em sua infraestrutura de inferência, o que o torna mais simples de escalar do que um pipeline dependente de chamadas remotas a modelos de linguagem.
Como funciona o pipeline de duas etapas
O scanner combina duas etapas. A primeira faz a geração de candidatos: filtros de expressões regulares varrem o conteúdo em busca de padrões que lembrem credenciais, com alta revocação, de forma rápida e determinística.
A segunda é a classificação por contexto: um ModernBERT ajustado fino avalia cada candidato acompanhado de seu entorno — caminho do arquivo, tipo de segredo, nomes de variáveis e trechos de código ou texto próximos, e estima a probabilidade de ser um segredo verdadeiro. Achados de alta confiança viram alertas; valores parecidos, como placeholders, fixtures de teste e checksums, são filtrados antes de chegar ao desenvolvedor.
O GitHub faz questão de destacar uma escolha de projeto: o modelo não substitui a varredura determinística, ele a complementa. As expressões regulares seguem sendo a ferramenta adequada para encontrar candidatos rapidamente, e o aprendizado de máquina entra onde oferece mais alavancagem, distinguir o que "parece um segredo" do que "provavelmente é um segredo real".
O problema dos falsos positivos que quase parecem reais
A maior parte dos falsos positivos não é aleatória. São hard negatives: strings que casam com um padrão de credencial mas não são utilizáveis.
Entre os exemplos citados estão uma senha atribuída ao lado da URL de um banco de dados de produção contra o mesmo valor em uma fixture de teste; uma connection string em configuração de deploy contra uma string de localhost em um guia de instalação; e um valor de alta entropia ligado a uma credencial de API contra um checksum, identificador de build ou hash de asset.
Credenciais estruturadas costumam trazer prefixo, comprimento, alfabeto ou checksum característicos. Segredos genéricos não.
A sintaxe se sobrepõe à de identificadores de build, hashes de arquivos e valores de exemplo, e é o contexto que decide. Acrescentar mais regras pode suprimir parte desses casos, mas cada exceção nova corre o risco de esconder um segredo verdadeiro, motivo pelo qual sinais aprendidos pelo modelo, como tipo de segredo, nomes de variáveis e vizinhança do código, entram em cena no lugar de heurísticas manuais.
Por que isso importa
Em um post companheiro, Secret protection must scale with software, o GitHub argumenta que a proteção de segredos precisa acompanhar o ritmo de desenvolvimento acelerado por IA, em que mais código é produzido e mais credenciais circulam. A combinação de maior precisão e menor custo computacional é o que permite varrer mais superfícies, repositórios, commits e pull requests, sem transformar cada achado em uma tarefa de triagem.
Os números relatados resumem o ganho: 11,5% de melhora na aceitação dos alertas, 86% menos tempo mediano de execução na varredura pós-push e mais de 98% de economia de custo em relação ao pipeline baseado em LLMs. Para times de segurança, o efeito prático é mais confiança nas descobertas: se a varredura erra para menos, credenciais reais ficam expostas; se alerta demais, o time aprende a ignorar o aviso, e o pior cenário é justamente o alerta verdadeiro que ninguém olha.
