TruffleHog

Last reviewed Aug 26, 2026 · 840 words

Run this against every repository you own, today:

docker run --rm -it trufflesecurity/trufflehog:latest \
  git https://git.example.com/you/repo --only-verified

If it prints anything, that credential is live, someone with a clone of your history has it, and rotating it is the next 10 minutes of your day. TruffleHog's distinguishing feature among secret scanners is that word "verified": it does not just pattern-match something that looks like an AWS key, it calls the provider and asks whether the key works. That turns a scanner from a source of 400 maybes into a list of 3 certainties.

Verification is what separates it from a regex

Every secret scanner ships regexes for key formats. TruffleHog ships 800-plus detectors, and most of them know how to make an authenticated, read-only request to the service in question: a Stripe key hits Stripe's API, a Slack token hits Slack's auth.test, a Postgres URI attempts a connection. The result is labelled verified, unverified, or unknown when the check could not complete. Run with --only-verified during an audit and with --results=verified,unknown in CI, and you skip the pile of expired test keys and example strings that make up most findings on any repository older than a year.

The catalogue's "noisy on large repos" con is about the unverified pile. With verification on, the noise mostly disappears; what remains is a small number of detectors that cannot verify because the secret is internal to your network, and those are genuinely worth a human look.

Scan the forge, not just the working tree

The git source walks the full commit history, every branch, which is the point. A key you deleted in 2022 is still in the reflog of every clone. For a self-hosted Gitea or Forgejo, the practical loop is a script that lists repositories from the API and scans each:

for r in $(curl -s -H "Authorization: token $TOKEN" \
  "https://git.example.com/api/v1/user/repos?limit=50" | jq -r '.[].clone_url'); do
  trufflehog git "$r" --only-verified --json >> findings.jsonl
done

TruffleHog also has native sources for GitHub and GitLab organisations, S3 buckets, Docker images, filesystems, and a handful of others, so the same binary audits the container you are about to push and the backups directory nobody has looked at since 2019. The filesystem source on a home directory is a sobering half hour.

CI and pre-commit are the cheap wins

Scanning history once finds what leaked. Scanning every push stops the next one. In a Woodpecker or similar pipeline, a step that runs trufflehog git file://. --since-commit main --branch HEAD --fail blocks the merge when a verified secret arrives on the branch. Earlier still, a pre-commit hook using the official hook config runs on staged files in well under a second for a normal commit, and that is where I would put it for solo projects: the fix is free when the commit has not happened yet. TruffleHog is a step inside whichever CI runner you already use, not a runner itself.

It phones the provider to verify, so decide where it runs

Verification means outbound requests to Stripe, AWS, Slack, and whoever else's key it thinks it found. That is harmless in itself, since the requests are read-only checks with the key already in your possession, but it does mean an air-gapped runner will report everything as unknown, and it means scanning a client's codebase sends their keys to their own providers from your IP. Use --no-verification when that matters and accept the noise. It also means TruffleHog needs internet from CI, which some locked-down runners lack.

Gitleaks beside it, secrets managers ahead of it

Gitleaks is the other scanner people reach for: lighter, MIT-licensed, faster on huge monorepos, and with no verification. I run both, Gitleaks as the fast pre-commit gate and TruffleHog as the weekly audit, and there is no conflict. Neither solves the underlying problem, which is secrets living in files at all. The correct long-term move is a secrets manager such as Infisical injecting values at runtime, and TruffleHog becomes the check that the migration actually finished.

The catalogue flags that enterprise features are paid. That is true and mostly irrelevant for self-hosters: the paid product is a dashboard and continuous monitoring across an organisation. The AGPL CLI is the whole scanner, and the 256 MB, single Go binary footprint means it runs anywhere.

What I'd do

Scan every repository's full history once with --only-verified and rotate what it finds. Add the pre-commit hook to every project. Add a CI step on the default branch that fails on verified results. Repeat the full-history audit quarterly, with the filesystem source pointed at the backups directory too. It costs about an hour to set up and it is the highest-return hour in self-hosted security.