Ferramentas de secret scanning open source em 2026: pusemos seis à prova num repositório com 12 segredos plantados

Que scanners de segredos open source continuam a ser mantidos em 2026?

Dos onze scanners de segredos open source que verificámos a 29 de outubro de 2026, seis publicaram uma versão este ano: o Betterleaks, o Gitleaks, o TruffleHog, o Kingfisher, o Titus e o secretlint. O Nosey Parker está arquivado, e o detect-secrets e o git-secrets estão há mais de dois anos sem publicar uma versão.

A tabela reproduz o que a API do GitHub e o README de cada projeto diziam nesse dia: a licença, a última versão, se a ferramenta consegue testar um segredo junto do fornecedor e se escreve SARIF. As estrelas medem atenção, não manutenção, por isso ficaram de fora.

Há duas linhas que mudam o conselho habitual. O Gitleaks continua a funcionar e o repositório continua a receber commits, mas desde 21 de maio de 2026 o seu README diz que está «feature complete» e que as próximas versões «will be security patches only», ou seja, serão apenas correções de segurança. O autor original passou para o Betterleaks, um projeto MIT novo, criado em fevereiro de 2026 pelas pessoas que fizeram o Gitleaks, cujo desenvolvimento é apoiado pela Aikido Security. E o Nosey Parker, que ainda aparece em muitas listas, foi arquivado pela Praetorian, que o substituiu pelo Titus, um scanner escrito em Go cujas 487 regras vêm do Nosey Parker e do Kingfisher.

Também conta saber quem mantém cada ferramenta. O Kingfisher é da MongoDB, o detect-secrets é da Yelp, o git-secrets vem dos AWS Labs e o Talisman da Thoughtworks. O TruffleHog é o scanner open source da Truffle Security, com licença AGPL-3.0 desde a versão 3.0. O Whispers, da Skyscanner, que algumas listas ainda incluem, está arquivado, e a sua última versão foi a 1.5.3, em agosto de 2021.

O que encontrou cada scanner num repositório com segredos plantados?

A 29 de outubro de 2026, seis scanners de segredos correram sobre um repositório com 12 credenciais falsas: Betterleaks 12, Titus 11, Gitleaks e Kingfisher 10, TruffleHog e detect-secrets 9. Escaparam palavras-passe e um segredo JWT sem prefixo, uma chave presente só no histórico do git e, ao Titus, uma chave live da Stripe. O Titus e o detect-secrets assinalaram um isco cada.

Nesse dia montámos um pequeno repositório com ar de API de uma loja online, com TypeScript, Python, um ficheiro de settings do Django, um ficheiro Docker Compose e um script de deploy em shell, ao longo de três commits. Plantámos 12 credenciais falsas nos sítios onde costumam ir parar:

• um par de chaves de acesso AWS numa config em TypeScript;
• um personal access token do GitHub num cabeçalho curl;
• uma chave live da Stripe no .env;
• um token de bot do Slack em YAML;
• uma chave da OpenAI e uma chave da Anthropic em chamadas de SDK;
• uma chave de API da Google numa tag script de HTML;
• uma palavra-passe dentro de uma connection string do Postgres;
• um segredo de assinatura JWT em Node.js;
• a palavra-passe da base de dados do Django;
• uma chave privada RSA;
• uma chave da SendGrid num ficheiro .env.production que um commit posterior apagou.

Cada valor era aleatório e seguia o formato do fornecedor, e nenhum era uma chave verdadeira. Os dois iscos estavam no README: a chave de exemplo que a AWS documenta, AKIAIOSFODNN7EXAMPLE, e um placeholder da Stripe feito de x. Cada ferramenta correu com as regras por omissão, em modo de histórico do git quando o tem, num Mac, com as versões que o Homebrew distribuía nesse dia. As validações em direto ficaram desligadas, já que uma chave falsa não pode ser verificada:

gitleaks git . --report-format json --report-path gitleaks.json
betterleaks git . --report-format json --report-path betterleaks.json
trufflehog git file://. --no-verification --json > trufflehog.jsonl
kingfisher scan . --no-validate --format json --output kingfisher.json
titus scan --git . --format json --output :memory: > titus.json
detect-secrets scan --all-files > detect-secrets.json

Os seis encontraram a chave AWS, o token do GitHub, o token do Slack, a chave da Anthropic e a chave privada. As maiores diferenças vieram dos segredos que não trazem prefixo: o Gitleaks, o Kingfisher e o TruffleHog falharam a palavra-passe da base de dados do Django, e o Kingfisher e o TruffleHog falharam também o segredo de assinatura JWT. As chaves de fornecedor também não passaram todas: o TruffleHog e o detect-secrets falharam a chave de API da Google, o detect-secrets a chave da OpenAI e o Titus a chave live da Stripe. Um valor atribuído a JWT_SECRET é uma string aleatória, sem formato que se reconheça, por isso só o apanham as regras que leem o nome da variável ou a entropia da string.

A chave da SendGrid só existia num commit que o commit seguinte apagou. Todas as ferramentas que leem o histórico do git a encontraram. O detect-secrets não, e o README explica porquê: evita «digging through all git history», ou seja, escavar o histórico inteiro do git, e analisa os ficheiros atuais, com uma baseline das descobertas já conhecidas.

Os dois iscos enganaram ferramentas diferentes. O Gitleaks e o Betterleaks ignoram as chaves AWS que terminam em EXAMPLE, porque a sua regra AWS por omissão traz essa exceção, e por isso a chave da documentação passou em silêncio; o detect-secrets assinalou-a. O Titus reportou o placeholder feito de x como uma chave da Stripe e deixou escapar a chave da Stripe verdadeira no .env. O Nosey Parker 0.24.0, que também corremos, fez exatamente o mesmo, o que bate certo com regras herdadas do Nosey Parker.

O número de descobertas é maior do que o número de credenciais. O Titus reportou 16 descobertas para 11 credenciais e o detect-secrets 15 para 9, porque várias regras apanharam o mesmo valor: um token do GitHub apanhado como token e também como cabeçalho curl, uma chave da OpenAI apanhada segunda vez como chave genérica. Cada duplicado é mais uma linha para triar.

Gitleaks, TruffleHog ou Betterleaks: qual deves usar?

Numa instalação nova, começa pelo Betterleaks. Mantém o Gitleaks se já está nos teus hooks e só precisas que continue a funcionar, e junta o TruffleHog ou o Kingfisher quando saber se uma chave está ativa conta mais do que apanhar todas as palavras-passe. As três diferem nas regras, na manutenção e no que fazem depois de uma correspondência.

Gitleaks (MIT, v8.30.1) continua a fazer o seu trabalho: no nosso teste não deu nenhum falso alarme e falhou duas palavras-passe. Não vai receber regras novas. Sair dele custa pouco, porque o Betterleaks lê um ficheiro .gitleaks.toml e respeita os comentários gitleaks:allow.

Betterleaks (MIT) encontrou tudo no nosso teste. A versão 1.9.0 é a estável e a validação é uma flag, --validation. A versão 2 está em release candidate, e o guia de migração diz que os reporters CSV, JUnit, SARIF e de template «have been removed», ou seja, foram removidos. Se a tua pipeline lê SARIF, fica na 1.x por agora.

TruffleHog (AGPL-3.0) diz cobrir mais de 800 tipos de segredos e ter mais de 700 detetores que testam as credenciais contra as APIs dos próprios fornecedores, e corre esses testes por omissão. Para a AWS, o README diz que chama GetCallerIdentity. A opção --results=verified deixa apenas os segredos confirmados como ativos e, no nosso teste, com a verificação desligada, foi também a ferramenta que reportou menos descobertas. Falhou a chave de API da Google, o segredo de assinatura JWT e a palavra-passe do Django. Tem licença AGPL-3.0, por isso lê a licença com a tua equipa jurídica antes de o integrares num produto ou de o redistribuíres.

Kingfisher (Apache-2.0, Rust) valida as descobertas por omissão e consegue revogar algumas delas. Desde a versão 2.0.0, de 23 de agosto de 2026, as suas regras vêm do catálogo do Betterleaks: 462 das suas 488 regras, mais 26 do Veles, da Google. Testámos a 2.14.0; a 2.15.0 saiu na véspera.

Titus (Apache-2.0, Go) é para onde vão os utilizadores do Nosey Parker. Valida com --validate e escreve SARIF.

Um scanner de segredos deve testar se a chave ainda funciona?

Para a triagem, sim, desde que controles onde esse teste corre. Uma validação em direto envia a credencial encontrada à API do fornecedor e diz-te que descobertas são um incidente e quais são chaves mortas. O TruffleHog e o Kingfisher fazem-no por omissão, o Betterleaks e o Titus só com uma flag, e o Gitleaks nunca o faz.

O teste é um pedido real com o segredo real. Corre-o onde a tua política de rede permite chamadas a esses fornecedores e mantém os resultados fora dos logs públicos do CI. O secret scanning do próprio GitHub oferece a mesma ideia, como opção, com as «validity checks».

Não verificado não quer dizer seguro. A palavra-passe de uma base de dados na tua rede privada não pode ser testada a partir de um runner de CI que está fora dessa rede, por isso uma ferramenta que valida reporta-a como não verificada, e um filtro sobre os resultados verificados deixa-a cair.

Onde deve correr o secret scanning: pre-commit, CI ou dentro do agente?

Em três sítios: um hook de pre-commit em cada portátil, uma análise no CI a cada push que o programador não consegue saltar, e uma análise do histórico completo quando adotas a ferramenta. Um hook de pre-commit sozinho não chega, porque git commit --no-verify contorna os hooks pre-commit e commit-msg, como diz a documentação do git.

No GitHub, a proteção de push bloqueia um push que contenha um segredo detetado. O secret scanning corre de graça nos repositórios públicos; nos repositórios privados e internos de uma organização, exige o GitHub Secret Protection no GitHub Team ou no GitHub Enterprise Cloud, faturado por committer ativo.

Os agentes de código acrescentam um passo antes do commit. O Claude Code, o Cursor ou o Codex conseguem ler um ficheiro .env quando nada o proíbe, como mostrámos ao explicar o que o Claude Code envia à Anthropic e como pôr o .env fora do seu alcance, e um valor que o agente leu pode acabar num ficheiro que ele escreve.

É neste passo que a CybeDefend trabalha: as guardas do VibeDefend recusam a leitura do .env por um agente no Claude Code, no Cursor e no Codex e apontam-no para a variável de ambiente, e a análise do diff verifica os ficheiros que o agente alterou à procura de segredos e de problemas SAST e IaC antes do commit. A página como funciona o VibeDefend mostra as duas coisas.

O pull request continua a ser a última barreira, e as verificações de segurança ao pull request de um agente de IA incluem uma passagem dedicada aos segredos.

Como juntar os resultados dos scanners de segredos com os dos outros scanners?

Põe cada scanner a escrever SARIF 2.1.0, o formato que as plataformas de alojamento de código e as ferramentas de gestão de vulnerabilidades leem, e depois junta os ficheiros. Cinco das seis ferramentas que testámos escrevem-no, e cada comando abaixo produziu um ficheiro SARIF 2.1.0 válido no nosso repositório de teste.

Há duas armadilhas: o Betterleaks v2 remove o reporter SARIF, e a própria ajuda do Kingfisher ainda chama experimental à sua saída SARIF.

gitleaks git . --report-format sarif --report-path gitleaks.sarif
betterleaks git . --report-format sarif --report-path betterleaks.sarif   # 1.x only
trufflehog git file://. --sarif > trufflehog.sarif
kingfisher scan . --format sarif --output kingfisher.sarif
titus scan --git . --format sarif --output :memory: > titus.sarif

Análises no pre-commit e no CIUm ficheiro SARIF por ferramentaJuntar e deduplicarTriar e guardar o histórico

Um ficheiro junto não é uma lista triada. A mesma chave volta de duas ferramentas com dois nomes de regra diferentes, um falso positivo que descartaste reaparece na execução seguinte, e nada guarda o registo que um auditor pede. O problema da triagem é o mesmo que descrevemos em porque é que a maioria das descobertas SAST é ruído.

O CybeDefend Open Source foi feito para esse passo. Corre os scanners que escolheres, qualquer ferramenta que escreva SARIF, e põe o que encontram numa única fila deduplicada, de graça e nos teus servidores. O lançamento está para breve, e a lista de espera do CybeDefend Open Source já está aberta.

Que scanners de segredos gratuitos não são totalmente open source nem locais?

O secret scanning do GitHub e o ggshield da GitGuardian são gratuitos para começar, mas nenhum corre inteiramente na tua máquina com licença open source. O GitHub analisa de graça os repositórios públicos e exige um plano pago de Secret Protection para os privados. A CLI do ggshield é MIT, mas a análise passa pela API da GitGuardian e exige uma conta.

O scanning do GitHub é uma funcionalidade alojada: lê o histórico inteiro de um repositório no GitHub, em todas as branches, e a proteção de push funciona do lado do servidor. Isso faz dele uma boa rede de segurança e uma má escolha para código que vive noutro sítio. O que apanha e o que lhe escapa num fluxo de trabalho com o Copilot está no nosso guia dos riscos de segurança do GitHub Copilot.

O README do ggshield diz que, para o usar, «you need to authenticate against GitGuardian servers», ou seja, tens de te autenticar nos servidores da GitGuardian, com uma conta ou uma chave de API; diz também que os teus ficheiros e segredos não ficam guardados. Para muitas equipas é uma troca razoável, e é uma troca diferente de correr o Betterleaks no teu próprio runner.

O que fazer quando um scanner encontra um segredo verdadeiro?

Revoga-o ou faz a rotação primeiro, e só depois decide se o histórico precisa de ser reescrito. O guia do GitHub sobre a remoção de dados sensíveis diz que o primeiro passo, para uma palavra-passe, um token ou uma credencial, é revogá-los e/ou fazer a rotação, e que um segredo revogado deixa de dar acesso, o que pode bastar.

1. Revoga a credencial ou faz a rotação junto do fornecedor. O Kingfisher, e o Betterleaks a partir da versão 2, conseguem revogar sozinhos alguns tipos de credenciais.
2. Vê nos logs de acesso do fornecedor como foi usada enquanto esteve exposta.
3. Tira-a do código e põe-na num gestor de segredos ou numa variável de ambiente que o código lê.
4. Reescreve o histórico só se não houver alternativa; o guia do GitHub descreve os passos.
5. Regista os falsos positivos para que deixem de voltar: um comentário gitleaks:allow ou betterleaks:allow, uma entrada no ficheiro de exclusões da ferramenta, ou uma baseline do detect-secrets.

Perguntas frequentes

Qual é o melhor scanner de segredos open source em 2026?

No nosso teste de 29 de outubro de 2026, o Betterleaks 1.9.0 encontrou as 12 credenciais plantadas num pequeno repositório e não deu nenhum alarme nos iscos. O TruffleHog é a melhor escolha quando precisas de saber se uma chave está ativa, já que valida por omissão. O Gitleaks continua a funcionar, e o README limita as próximas versões a correções de segurança.

Gitleaks: o que é?

O Gitleaks é um scanner de segredos open source, com licença MIT, que procura credenciais no código e no histórico do git através de padrões. Corre como hook de pre-commit e no CI, escreve SARIF e não testa se as chaves estão ativas. No nosso teste encontrou 10 das 12 credenciais plantadas e falhou duas palavras-passe.

O Gitleaks ainda tem manutenção?

O Gitleaks continua a ser mantido, mas só com correções de segurança. Desde 21 de maio de 2026, o README diz que o Gitleaks está «feature complete» e que não vai integrar funcionalidades novas; a última versão é a v8.30.1, de 21 de março de 2026. O autor original trabalha agora no Betterleaks, que lê os ficheiros de configuração e os comentários de exceção do Gitleaks.

O que é o Betterleaks?

O Betterleaks é um scanner de segredos com licença MIT, criado em fevereiro de 2026 pelas pessoas que fizeram o Gitleaks, incluindo o seu autor original, com desenvolvimento apoiado pela Aikido Security. A versão 1.9.0 é a estável. A versão 2 está em release candidate, deixa a validação em direto desligada por omissão e remove o reporter SARIF.

O TruffleHog é gratuito e open source?

Sim. O TruffleHog no GitHub é open source sob AGPL-3.0 desde a versão 3.0 e não custa nada a correr. Diz cobrir mais de 800 tipos de segredos, valida as credenciais junto dos fornecedores por omissão e escreve SARIF desde a versão 3.97.0, lançada em agosto de 2026.

O detect-secrets analisa o histórico do git?

Não, e é de propósito. O detect-secrets analisa os ficheiros da tua working tree, por omissão os que o git segue, e guarda uma baseline das descobertas conhecidas para que só os segredos novos bloqueiem um commit. No nosso teste falhou uma chave que só existia no histórico de um ficheiro apagado. A última versão, a 1.5.0, é de maio de 2024.

Como detetar chaves de API hardcoded no código?

Corre uma vez um scanner por padrões, como o Betterleaks ou o Gitleaks, sobre o código e todo o histórico do git, e depois a cada commit e a cada push. As chaves de fornecedores como a AWS, o GitHub ou a Stripe são reconhecidas pelo prefixo e pelo formato. Os segredos genéricos, como as palavras-passe, precisam de regras sobre os nomes das variáveis e a entropia, e é aí que as ferramentas mais diferem.

O secret scanning do GitHub é gratuito?

Nos repositórios públicos, sim: o secret scanning corre automaticamente e de graça. Nos repositórios privados e internos de uma organização, exige o GitHub Secret Protection no GitHub Team ou no GitHub Enterprise Cloud, faturado por committer ativo.