Ferramentas de detecção de segredos: TruffleHog vs Gitleaks vs GitGuardian vs GitHub

Secret scanning, ou detecção de segredos, é a busca automática por credenciais (API keys, tokens, senhas, chaves privadas) em lugares onde elas não deveriam estar: código fonte, histórico do git, logs de CI, imagens de container. Em quase toda avaliação aparecem os mesmos quatro nomes: TruffleHog, Gitleaks, GitGuardian e o secret scanning do GitHub. Eles se sobrepõem bastante, mas não são intercambiáveis: mudam a licença, a verificação de que o segredo ainda está ativo e o lugar onde rodam.

Este guia compara as quatro de forma justa, com base na documentação de cada projeto, e depois cobre a parte que quase toda comparação pula: o que fazer quando o segredo já vazou, e por que apagar do código não resolve nada.

Como funciona a detecção de segredos

Quase todas as ferramentas combinam três técnicas:

• Padrões por provedor. Muitas credenciais têm um formato reconhecível. Access key IDs da AWS começam com AKIA, personal access tokens do GitHub com ghp_, secret keys live da Stripe com sk_live_. Um detector por formato gera matches muito precisos.
• Entropia e palavras-chave. Segredos genéricos (uma senha aleatória de banco, um token interno) não têm prefixo fixo. As ferramentas procuram strings de alta entropia perto de palavras como password, secret ou token. Pega mais coisa, com mais ruído.
• Verificação. O sinal mais forte é testar o candidato no provedor: se uma chave da AWS autentica, ela está ativa. A verificação transforma "isso parece uma chave" em "essa chave está ativa", o que muda a urgência da resposta.

Por que um segredo continua no histórico do git depois de apagado

O git é um histórico de snapshots em que só se acrescenta. Quando você remove uma chave em um commit novo, todos os commits anteriores continuam com ela, e qualquer pessoa consegue ler com git log -p ou fazendo checkout de uma revisão antiga. Reverter o commit também não ajuda: um revert é só mais um commit por cima.

Piora depois do push. Cada clone no notebook de alguém do time, cada fork, cada cache de CI e cada mirror tem a sua cópia. Em um repositório público, assuma que o segredo já foi visto: existem bots que monitoram pushes públicos atrás de credenciais. Por isso a primeira regra é simples: segredo vazado é segredo comprometido. Rotacione. Limpar o histórico é um passo secundário, que aparece mais abaixo.

Pelo mesmo motivo, um bom scanner olha o histórico inteiro, e não só os arquivos atuais. Uma chave removida há dois anos que ainda funciona é tão perigosa quanto uma que está hoje na main.

TruffleHog

O TruffleHog, da Truffle Security, é open source sob licença AGPL-3.0. Segundo o repositório, ele classifica mais de 800 tipos de segredos, e o diferencial é a verificação: para cada tipo de segredo que consegue classificar, ele também tenta fazer login para confirmar se o segredo está ativo. Os resultados são marcados como verified, unverified ou unknown (a verificação foi tentada mas falhou, por exemplo por erro de rede).

Ele escaneia muito além do git: GitHub e GitLab, imagens Docker, S3 e Google Cloud Storage, Jenkins, Elasticsearch, Postman e o filesystem local. Tem GitHub Action e suporte a pre-commit. Um scan típico do histórico que reporta apenas credenciais ativas confirmadas:

trufflehog git https://github.com/sua-org/seu-repo --results=verified

Existe também o TruffleHog Enterprise, comercial, que adiciona monitoramento contínuo em Git, Jira, Slack, Confluence e Microsoft Teams. Faz sentido quando você quer scan gratuito com foco em verificação e os termos da AGPL não são problema para o seu uso.

Gitleaks

O Gitleaks é open source sob licença MIT. Ele detecta segredos com expressões regulares combinadas com entropia de Shannon, e tudo é configurável em um arquivo .gitleaks.toml: regras próprias, limites de entropia, palavras-chave, allowlists (globais ou por regra) e filtros por path. Também decodifica conteúdo em base64, hex e percent-encoding antes de procurar.

Desde a v8.19.0 os antigos comandos detect e protect estão depreciados, substituídos por três modos:

# escanear todo o histórico do git
gitleaks git -v

# escanear um diretório ou arquivos (sem git)
gitleaks dir ./config

# escanear conteúdo via pipe
cat build.log | gitleaks stdin

Os relatórios saem em JSON, CSV, JUnit, SARIF ou template Go customizado, o que facilita mandar os resultados para um dashboard de code scanning. O trade-off está escrito na documentação: o Gitleaks não verifica se um segredo detectado está ativo. Faz sentido quando você quer um scanner rápido, com licença permissiva e muito configurável, e topa fazer a triagem por conta própria.

GitGuardian

O GitGuardian é uma plataforma comercial de segurança de segredos. A CLI, ggshield, é open source sob licença MIT e, segundo o README, detecta e valida mais de 500 tipos de segredos hardcoded. Diferente das duas anteriores, o ggshield precisa de conta e API key do GitGuardian, porque a detecção passa pela API do GitGuardian. O README afirma que dos scans com ggshield só se guarda metadata como horário da chamada, tamanho da requisição e modo de scan, e não os seus arquivos ou segredos.

ggshield auth login
ggshield secret scan repo .

O ggshield se integra com pre-commit, GitHub Actions e outros sistemas de CI, e consegue escanear imagens Docker e pacotes do PyPI. Sobre preço, o GitGuardian tem um plano gratuito Starter para times de até 25 desenvolvedores; os planos pagos adicionam monitoramento de segredos públicos, workflows de remediação e, no Enterprise, implantação self-hosted. Faz sentido quando você quer uma plataforma gerenciada com dashboards, fluxo de incidentes e gestão de times, em vez de montar tudo com CLIs.

Secret scanning e push protection do GitHub

Se o seu código está no GitHub, você já tem acesso ao scanner nativo. O secret scanning analisa todo o histórico do git em todas as branches, além de issues, pull requests, discussions e wikis. É gratuito para repositórios públicos. Para repositórios privados e internos você precisa do GitHub Secret Protection, vendido como produto independente desde abril de 2025 por USD 19 por mês por committer ativo, disponível para clientes GitHub Team e Enterprise.

Três recursos se destacam:

• Programa de parceiros. Quando o GitHub detecta um segredo de um provedor parceiro, ele avisa esse provedor, que pode revogar a credencial.
• Validity checks. O GitHub consegue consultar o emissor para saber se um segredo detectado continua ativo, ajudando na priorização.
• Push protection. Pushes com segredos suportados são bloqueados antes de entrar, venham da linha de comando, da interface web, de upload de arquivos ou da REST API. Quem tem permissão de escrita pode contornar informando um motivo ("usado em testes", "falso positivo", "corrijo depois"), e o bypass vira um alerta. A push protection para usuários vem ativada por padrão no GitHub.com e impede que você envie segredos para repositórios públicos.

O GitHub também suporta padrões customizados para tokens da sua organização e detecção por IA de segredos genéricos como senhas. Faz sentido quando você está 100% no GitHub e quer prevenção no servidor, onde nenhum dev pode esquecer de instalar um hook.

Tabela comparativa

Prevenção: hooks de pre-commit, CI e push protection

O vazamento mais barato é o que nunca chega ao remoto. Um esquema em camadas fica assim:

1. Hook de pre-commit nas máquinas dos devs. Com o framework pre-commit e o Gitleaks, por exemplo:

   # .pre-commit-config.yaml
   repos:
     - repo: https://github.com/gitleaks/gitleaks
       rev: vX.Y.Z  # fixe a tag da última release
       hooks:
         - id: gitleaks

   Hooks são instalados máquina a máquina, então trate como conveniência, não como controle.
2. Um scan no CI em cada pull request, quebrando o build em achados novos. Isso pega quem não instalou o hook.
3. Push protection no servidor (a do GitHub ou equivalente), para bloquear o segredo mesmo quando falta a ferramenta local.
4. Segredos fora do código. Variáveis de ambiente, um secrets manager, .env no .gitignore e credenciais de vida curta, como federação OIDC no CI, em vez de chaves de nuvem de longa duração.

Isso se encaixa na ideia de shift-left do DevSecOps, e não é detalhe: chaves hardcoded são um exemplo clássico das falhas criptográficas cobertas pelo OWASP Top 10.

Vazou um segredo: primeiro rotacione, depois limpe

1. Rotacione ou revogue a credencial imediatamente no provedor. A própria documentação do GitHub coloca isso em primeiro lugar: com a credencial invalidada, talvez você nem precise reescrever o histórico.
2. Verifique se houve abuso. Olhe os logs de acesso do provedor (CloudTrail na AWS, audit log no GitHub, dashboard da Stripe) no intervalo entre o vazamento e a rotação.
3. Guarde o segredo novo em um secrets manager e tire do código.
4. Opcionalmente, limpe o histórico. O GitHub recomenda o git-filter-repo:

   # remover um arquivo de todo o histórico
   git-filter-repo --sensitive-data-removal --invert-paths --path config/secrets.yml
   
   # ou substituir strings listadas em um arquivo
   git-filter-repo --sensitive-data-removal --replace-text ../passwords.txt
   
   git push --force --mirror origin

   Reescrever o histórico muda os SHAs dos commits, forks mantêm os dados antigos, o time precisa clonar de novo ou fazer rebase para não enviar o segredo de volta, e no GitHub é preciso falar com o GitHub Support para remover visualizações em cache e desreferenciar pull requests afetados.

Como escolher

• Dev solo ou time pequeno no GitHub: ative push protection e secret scanning onde estiver disponível, e adicione Gitleaks ou TruffleHog como hook de pre-commit.
• Sinal é o que mais importa: priorize verificação (TruffleHog, GitGuardian, validity checks do GitHub) para as chaves ativas aparecerem primeiro.
• Precisa de regras próprias e licença permissiva: Gitleaks e o .gitleaks.toml.
• Time de segurança com muitos repositórios e pessoas: uma plataforma (GitGuardian, GitHub Secret Protection, TruffleHog Enterprise) com dashboards e workflows.

Seja qual for a escolha, segredos são só uma camada. Dependências precisam de software composition analysis (e, para auditorias, de um SBOM), e o seu próprio código precisa de análise estática como AI SAST; veja em SAST e DAST como tudo se encaixa.

Onde o Nurbak entra

O Nurbak não é uma plataforma dedicada a segredos; a detecção de segredos é uma parte de um scan completo do repositório. Você conecta o GitHub, escaneia um repositório, e o Nurbak detecta credenciais de provedores (AWS, GitHub, Stripe, OpenAI, Anthropic, Slack, chaves privadas e outros) no código atual e, com o GitHub conectado, nos commits mais recentes do histórico do git. Ele guarda apenas uma versão mascarada de cada segredo e orienta você a rotacioná-lo. No mesmo scan, o próprio modelo de IA self-hosted do Nurbak analisa o seu código em busca de vulnerabilidades exploráveis com arquivo e linha (a análise não envia o seu código para a OpenAI nem para a Anthropic), verifica as dependências no OSV e aponta misconfigs de GitHub Actions, Docker, Terraform e Kubernetes, com um score de 0 a 100. O scan gratuito mostra completos os 3 achados mais importantes. Experimente o secret scanner ou o GitHub security scanner completo.

Resumindo

TruffleHog, Gitleaks, GitGuardian e o secret scanning do GitHub encontram segredos no histórico do git; as diferenças reais estão na licença, na verificação e em onde cada um roda. Escolha um para pre-commit, outro para o CI ou o servidor, e faça da rotação, e não da exclusão, a sua resposta padrão. Se você quer saber o que já está no seu repositório hoje, rodar um secret scanner é um bom primeiro passo.

Leituras relacionadas

• O que é SBOM
• O que é DevSecOps
• SAST e DAST
• OWASP Top 10 2025