Betterleaks: scanner de segredos vs. Gitleaks

Scanner de segredos Betterleaks: arquitetura e chaves

A detecção de segredos em repositórios mudou consideravelmente nos últimos anos. Antes, bastava procurar por strings ou chaves suspeitas com alta entropia no código. Hoje, a situação é diferente: repositórios maiores, pipelines de CI/CD mais rápidos e, sobretudo, uma quantidade crescente de código gerado por ferramentas automatizadas ou modelos de IA.

Isso tem uma consequência prática: o problema não é mais apenas encontrar segredos, mas separar o que é realmente perigoso do que apenas aparenta ser. Muitas equipes estão descobrindo que o verdadeiro custo desses scanners não está na execução da análise, mas na revisão de centenas de falsos positivos.

Arquitetura de detecção: o que muda com o Betterleaks?

Betterleaks surge precisamente nesse contexto. Não tenta reinventar completamente a varredura de segredos, mas questiona uma suposição generalizada: a de que detectar padrões é suficiente.

Em muitos repositórios modernos, não é.

O projeto, desenvolvido por Zach Rice e mantido com o apoio do Aikido, propõe algo ligeiramente diferente. Em vez de se concentrar apenas na detecção de correspondências, ele tenta validar se a descoberta faz sentido antes de transformá-la em um alerta.

Isso pode parecer um detalhe insignificante, mas altera significativamente a dinâmica em grandes equipes. Quando um sistema de varredura gera muitos alertas irrelevantes, a reação natural da equipe é ignorá-los. E em segurança, um alerta ignorado pode ser pior do que nenhum alerta.

Para solucionar esse problema, o Betterleaks introduz duas ferramentas técnicas interessantes: a validação usando CEL (Common Expression Language) e uma métrica chamada "Eficiência de Token", baseada na tokenização BPE.

A ideia é que nem tudo que parece ser um segredo realmente o é. Algumas sequências de alta entropia são simplesmente hashes, identificadores ou fragmentos gerados automaticamente. O objetivo do sistema é reduzir esse ruído.

A documentação do projeto menciona uma comparação em que a tokenização BPE atinge uma taxa de recall de 98,6%, em comparação com os 70,4% obtidos usando entropia no conjunto de dados CredData. Como em qualquer benchmark, esses números são indicativos. Eles servem como um bom ponto de referência, mas não substituem os testes em repositórios reais.

Componentes que fazem a diferença

A análise das características do projeto revela uma direção clara: facilitar a implantação em ambientes reais sem adicionar muita complexidade técnica.

Entre os elementos mais proeminentes estão:

• Validação definida por regras usando CEL (Common Expression Language)
• A análise de eficiência de tokens baseada em tokenização BPE, em vez de entropia, alcançou 98,6% de recall contra 70,4% com entropia no conjunto de dados CredData.
• Implementação em Go puro (sem dependência de CGO ou Hyperscan)
• Manipulação automática de segredos codificados duplamente/triplamente
• Conjunto de regras expandido para mais fornecedores
• Análise paralela do Git para uma análise mais rápida do repositório.

Embora esta lista possa parecer apenas um conjunto de melhorias técnicas, o interessante é como elas afetam o uso diário.

Por exemplo, uma implementação completa em Go, sem dependências nativas, simplifica bastante a integração em pipelines de CI/CD. Em muitas equipes, pequenos detalhes como esse determinam se uma ferramenta acaba sendo usada ou esquecida em um repositório.

A tokenização BPE também introduz uma abordagem diferente. Em vez de simplesmente medir a aleatoriedade de uma cadeia, ela analisa padrões de tokens que refletem mais fielmente a forma como as credenciais modernas são estruturadas.

O que acontece quando o scanner encontra algo?

Quando a Betterleaks detecta um possível segredo, o processo não termina aí.

Primeiramente, o contexto é avaliado usando regras definidas em CEL. Isso permite a adição de outras condições: por exemplo, verificar se o formato corresponde ao provedor esperado ou descartar padrões que aparecem frequentemente em exemplos ou dados fictícios.

Esta etapa pode parecer trivial, mas tem um impacto prático significativo. Os falsos positivos não só desperdiçam tempo, como também reduzem a confiança da equipe no sistema de alertas.

Outro aspecto interessante é o tratamento automático de segredos codificados várias vezes. Em alguns repositórios, as credenciais aparecem transformadas usando base64 ou outros esquemas de codificação, o que complica sua detecção.

Mesmo assim, vale a pena lembrar algo que às vezes é esquecido: nenhum scanner pode substituir completamente a revisão humana. Detectar um segredo é apenas o começo; decidir o que fazer com ele (revogar, rotacionar, ignorar ou investigar) continua sendo uma decisão contextual.

Governança e abordagem centrada no ser humano/IA

O Betterleaks é publicado sob a licença MIT e conta com contribuições externas de organizações como o Royal Bank of Canada, a Red Hat e a Amazon.

O projeto também busca se adaptar a uma realidade cada vez mais visível nos repositórios modernos: a mistura de código escrito por desenvolvedores e código gerado por ferramentas automatizadas.

Nesse contexto, a ferramenta visa funcionar bem tanto em fluxos de trabalho operados por humanos quanto em sistemas automatizados que revisam repositórios inteiros. Isso está alinhado com o uso crescente de automação e ferramentas que analisam o código ou geram revisões automáticas.

O roteiro também inclui ideias interessantes: integração com fontes de dados além do GitAssistência de modelo de linguagem para classificação de resultados e mecanismos de revogação automática via APIs do provedor.

Isso abre um debate interessante. Automatizar a revogação de credenciais pode reduzir o tempo de resposta a um incidente, mas também significa depender da precisão do sistema de classificação.

Se uma revogação automática falhar ou for acionada por engano, o impacto operacional pode ser considerável.

Implicações práticas e limitações

Do ponto de vista operacional, o Betterleaks é atraente para equipes que buscam reduzir falsos positivos e simplificar as implementações.

Mas também é importante ter em mente alguns limites:

• As métricas de recall dependem do conjunto de dados utilizado e podem variar consideravelmente entre repositórios.
• A automatização de ações como a revogação de chaves exige controles adicionais e registros de auditoria.
• Os scanners secretos representam apenas uma camada de defesa dentro de uma estratégia mais ampla.

Em muitos casos, a decisão de adotar tal ferramenta depende não tanto de sua precisão teórica, mas de algo mais simples: se ela se integra bem ao fluxo de trabalho da equipe.

Um scanner de alta precisão que gera muito atrito geralmente é descartado. Um scanner razoavelmente preciso e fácil de integrar geralmente é mantido.

Nesse sentido, o Betterleaks busca um equilíbrio. Não promete eliminar todos os falsos positivos nem substituir os processos de segurança existentes, mas visa reduzir o ruído e facilitar a integração em fluxos de trabalho modernos.

O projeto está disponível no GitHub. e é apresentado como uma evolução da abordagem utilizada pelo Gitleaks, com a intenção de se adaptar a repositórios onde a automação, os agentes de análise e o código gerado por modelos de linguagem fazem parte integrante do fluxo de desenvolvimento.