# trufflehog: encontrando e verificando credenciais vazadas

> Como instalar e executar o trufflehog, por que o modo verified-only importa, e como o Tandera transforma um segredo verificado em um finding com severidade real.

O `trufflehog` varre conteúdo em busca de credenciais e — é isto que o separa de todo scanner de segredos baseado em regex — tenta verificá-las contra o serviço emissor. Um match não verificado é uma string que parece uma chave. Um match verificado é uma chave que funciona.

## Instalação

```bash
# macOS
brew install trufflehog

# Linux
curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh \
  | sh -s -- -b /usr/local/bin

# Docker
docker run --rm -it trufflesecurity/trufflehog:latest github --repo https://github.com/example/repo
```

## Comandos principais

```bash
# um repo git, histórico completo
trufflehog git https://github.com/example/repo --only-verified

# um checkout local
trufflehog filesystem ./src --only-verified

# uma organização inteira do GitHub
trufflehog github --org=example --only-verified

# JSON para importar
trufflehog git file://./repo --only-verified --json > secrets.jsonl

# S3, com um perfil de credencial específico
trufflehog s3 --bucket=example-assets --only-verified
```

O `--only-verified` é a flag que torna a saída reportável. Sem ela você recebe milhares de strings candidatas; com ela você recebe credenciais que autenticaram com sucesso.

## Saída

```json
{"SourceMetadata":{"Data":{"Git":{"commit":"a3f9...","file":"config/settings.py",
 "line":42,"repository":"https://github.com/example/repo"}}},
 "DetectorName":"AWS","Verified":true,"Raw":"AKIA..."}
```

## Onde ele entra no Tandera

O trufflehog roda na fase de **analyze** do `recon_web_lite` e do `recon_web_full`, contra os bundles JavaScript e assets que `katana` e `linkfinder` recuperaram. O uso voltado para web é mais estreito que o uso em histórico git pelo qual a maioria o conhece: ele procura chaves enviadas ao navegador.

Resultados verificados mapeiam para o catálogo de findings `secrets.yaml`, que é o que lhes dá uma severidade e remediação canônicas em vez de um nome bruto de detector.

## Usando em um pentest

**Verificado muda a severidade, e a conversa.** "Encontramos uma string que combina com o formato de uma chave AWS" convida ao debate. "Encontramos uma chave AWS que autentica" encerra. Reporte as duas categorias separadamente e nunca as misture.

**Não use a credencial além da verificação.** Confirmar que uma chave é válida está no escopo. Enumerar a conta que ela abre é outra autorização, e frequentemente outro contrato. Verifique, capture evidência, pare, escale para o cliente.

**O histórico git é onde elas vivem.** Uma chave deletada do `HEAD` ainda está no commit que a adicionou. Varrer a working tree em vez do histórico do repositório é o jeito mais comum de usar esta ferramenta errado.

**Rotacionar é a remediação, não deletar.** Uma chave removida do repo mas nunca rotacionada continua sendo uma chave válida. Diga isso explicitamente no finding.

---

Canonical: https://tandera.io/pt-br/tools/trufflehog
This page as markdown: https://tandera.io/pt-br/tools/trufflehog.md
Index for agents: https://tandera.io/llms.txt

Every page here is also available as markdown: append `.md` to the path (e.g. `/recon.md`, `/index.md` for this homepage, `/blog/<slug>.md`), or request the canonical path with `Accept: text/markdown`.