Gitleaks vs TruffleHog: qual scanner de segredos usar

Se você já rodou um scanner de segredos num pipeline e recebeu 40 falsos positivos para 1 credencial real, sabe que a escolha da ferramenta não é só "qual detecta mais". É sobre o que você faz com o resultado: bloquear o commit, abrir um ticket, ou acordar alguém às 3h porque uma chave da AWS está exposta e ativa.

Gitleaks e TruffleHog resolvem o mesmo problema — achar segredos em código, histórico git e outras fontes — mas partem de filosofias diferentes. Este post compara as duas a partir da documentação oficial de cada projeto, sem benchmark de performance (porque nenhuma das fontes oficiais traz esse dado).

Premissas e limitações desta comparação

Antes de ir aos critérios, vale deixar claro o que este texto não cobre, porque as duas páginas de origem (README do Gitleaks e do TruffleHog no GitHub) vieram truncadas e sem alguns dados que normalmente importam numa decisão de ferramenta:

• Sem benchmark de performance. Não há dado oficial comparando velocidade de scan, consumo de memória ou comportamento em repositórios grandes.
• Licença não confirmada no material consultado. Os repositórios têm um arquivo LICENSE, mas o conteúdo não foi extraído nesta pesquisa. Confirme a licença direto no repositório antes de adotar em ambiente corporativo, especialmente se for usar o TruffleHog Enterprise.
• Nenhum comando foi executado neste ambiente. Os exemplos de instalação e uso abaixo vêm da documentação oficial; valide a sintaxe na sua máquina antes de colocar em produção ou em pipeline de CI.
• Lista de comandos CLI do TruffleHog é parcial. A documentação consultada mostra o subcomando github em detalhe, mas não há o mesmo nível de detalhamento de flags que existe para o Gitleaks (que documenta dir, git, stdin, version, completion e dezenas de flags).

Dito isso, dá para comparar o que importa de fato: abordagem de detecção, cobertura, maturidade do projeto e encaixe operacional.

Cenário: por que isso importa

Um scanner de segredos normalmente entra em três pontos do fluxo:

1. Pre-commit hook — barra o segredo antes de ele sair da máquina do desenvolvedor.
2. CI/CD — audita pull requests e branches, geralmente como gate de merge.
3. Varredura contínua / histórico — escaneia repositórios inteiros, incluindo commits antigos, em busca de segredos que já vazaram.

A ferramenta certa depende de qual desses pontos é sua prioridade — e de quanto ruído (falsos positivos) sua equipe está disposta a investigar manualmente.

Critérios de comparação

1. Abordagem de detecção

Gitleaks usa um motor baseado em regex — o próprio blog do mantenedor resume a filosofia como "regex is (almost) all you need". Isso significa detecção rápida e previsível, mas o resultado é binário: ou o padrão bate, ou não. Não há verificação se o segredo encontrado ainda é válido.

TruffleHog vai além da detecção e declara quatro capacidades no README oficial: Discovery (procurar em git, chats, wikis, logs, object stores e mais), Classification (mais de 800 tipos de segredo mapeados a provedores específicos como AWS, Stripe, Cloudflare, Postgres), Validation (login ativo para confirmar se o segredo está "vivo") e Analysis (para cerca de 20 tipos de credencial, descobre quem criou o segredo e quais permissões ele tem).

Essa etapa de Validation é a diferença mais relevante na prática: ela separa "achei um padrão que parece uma chave" de "esta chave está ativa agora". Isso reduz drasticamente o trabalho de triagem manual quando o volume de findings é alto.

2. Maturidade e rumo do projeto

Aqui está o ponto que mais deveria pesar na sua decisão: o README do Gitleaks traz um aviso direto — "Gitleaks is feature complete. I'm not merging new features into Gitleaks. Future releases will be security patches only." O mantenedor está redirecionando esforço para um novo projeto, batizado "Betterleaks".

Isso não torna o Gitleaks inútil hoje (29.6k stars, uso consolidado, regex funciona), mas significa que novos tipos de segredo, novas integrações e melhorias de detecção não vão chegar por esse caminho. Se seu plano é de longo prazo, isso é um fator de risco de obsolescência a considerar.

O TruffleHog, por outro lado, tem um modelo de sustentação mais explícito: existe uma versão Enterprise paga (monitoramento contínuo de Git, Jira, Slack, Confluence, Microsoft Teams, SharePoint) cuja receita, segundo o próprio README, financia o desenvolvimento open source. Isso sugere um caminho de manutenção mais ativo, embora não haja dado quantitativo de frequência de releases nas fontes consultadas.

3. Cobertura de fontes

Gitleaks escaneia diretórios, repositórios git e stdin — é focado em código-fonte e seu histórico.

TruffleHog declara escopo mais amplo: além de git, também chats, wikis, logs, plataformas de teste de API e object stores. Se o seu problema não é só "segredo no código" mas "segredo vazado em qualquer lugar que a empresa usa", o TruffleHog cobre um perímetro maior — mas isso também significa mais configuração e, possivelmente, mais dependências de credenciais de acesso a cada fonte.

4. Instalação e integração operacional

Ambos oferecem os caminhos padrão de instalação:

# Gitleaks via Homebrew
brew install gitleaks

# Gitleaks via Docker
docker pull zricethezav/gitleaks:latest

# TruffleHog via Homebrew
brew install trufflehog

# TruffleHog via Docker, escaneando um repositório
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest \
  github --repo https://github.com/trufflesecurity/test_keys

O TruffleHog também documenta verificação de assinatura dos binários de release via Cosign:

cosign verify-blob trufflehog_checksums.txt \
  --certificate trufflehog_checksums.txt.pem \
  --signature trufflehog_checksums.txt.sig

Isso é um detalhe de cadeia de suprimentos de software que vale notar: você consegue verificar criptograficamente que o binário baixado corresponde ao release assinado pelo projeto. Não há menção equivalente de verificação por assinatura no material consultado do Gitleaks.

Para pre-commit hook, o Gitleaks documenta integração nativa via .pre-commit-config.yaml:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Com a opção de pular o hook pontualmente via SKIP=gitleaks git commit ... — útil em emergência, perigoso se virar hábito da equipe.

5. Flags e granularidade de configuração

O Gitleaks tem um conjunto de flags bem documentado para quem precisa de controle fino: --baseline-path para ignorar issues já conhecidas, --enable-rule para ativar regras específicas, --redact para mascarar segredos no output (aceita percentual), --max-archive-depth e --max-decode-depth para controlar profundidade de varredura em arquivos compactados ou codificados, e --exit-code para integrar com gates de CI.

O material consultado do TruffleHog não traz o mesmo nível de detalhamento de flags — apenas o padrão de uso via subcomandos como github --repo ou github --org. Isso não quer dizer que a ferramenta seja menos configurável, apenas que a documentação levantada nesta pesquisa não cobriu esse detalhe. Vale checar o --help da ferramenta ou a documentação completa antes de assumir limitação.

Diferenças práticas, resumidas

| Critério | Gitleaks | TruffleHog | |---|---|---| | Motor de detecção | Regex | Classificação + validação ativa | | Verifica se o segredo está ativo | Não | Sim (login real contra o provedor) | | Tipos de segredo classificados | Não especificado na fonte | 800+ | | Status do projeto | Feature-complete, só patches de segurança | Em desenvolvimento ativo, com modelo Enterprise | | Escopo de varredura | Git, diretórios, stdin | Git, chats, wikis, logs, object stores, APIs | | Verificação de release por assinatura | Não mencionada | Sim, via Cosign | | Granularidade de flags documentada | Alta | Baixa (no material consultado) |

Recomendação condicionada

Não existe resposta única — depende do que seu pipeline precisa resolver agora:

Use Gitleaks se seu objetivo é um gate rápido e leve em pre-commit ou CI, com regras bem definidas e baixa necessidade de validar se o segredo é real. Para times pequenos ou médios que só querem impedir que .env vaze no commit, a simplicidade do regex é suficiente e o setup é direto. O aviso de feature-complete é um risco de longo prazo, não um bloqueador imediato — mas acompanhe o projeto "Betterleaks" se planeja manter essa stack por anos.

Use TruffleHog se o volume de findings já é alto demais para triagem manual, ou se você precisa saber não só "existe um padrão de chave aqui" mas "essa chave ainda funciona e o que ela acessa". A capacidade de Validation reduz ruído de forma significativa quando bem configurada, e o escopo mais amplo (chats, wikis, logs) é relevante se segredos vazam fora do código-fonte na sua organização — cenário comum quando há Slack, Jira ou Confluence compartilhando credenciais informalmente.

Use os dois se seu ambiente permite: Gitleaks como gate rápido em pre-commit (baixa latência, bloqueia na origem) e TruffleHog em varredura periódica mais profunda, com validação, rodando em CI ou como job agendado. Isso evita que a velocidade do regex vire gargalo no commit e ainda aproveita a validação ativa onde ela mais importa — na auditoria de histórico e no triagem de falsos positivos.

Próximo passo

Antes de decidir, rode as duas ferramentas contra o mesmo repositório de teste (o próprio TruffleHog disponibiliza um repo de exemplo, trufflesecurity/test_keys) e compare o volume de findings e o tempo de execução no seu ambiente real. Benchmark não documentado pelas fontes oficiais é exatamente o tipo de dado que você só consegue validando localmente — e é o critério que vai pesar mais na sua decisão final.