trufflehog for discovering and verifying leaked credentials across your code estate

trufflehog is a Go-based secret scanning engine that discovers, classifies, and validates leaked API keys across git history, cloud buckets, Docker images, and filesystems for authorized security teams.

Tool	trufflesecurity/trufflehog — open-source secrets discovery, classification, validation, and analysis engine written in Go
Category	Secret scanning / credential hygiene / DevSecOps
Primary Use	Continuously scanning git repositories, S3/GCS buckets, Docker images, and filesystems for leaked API keys and passwords during authorized security assessments and CI pipelines
Safe Use	Explicitly designed for defenders: use on repositories, cloud storage, and CI systems you own or are contractually authorized to assess, to remediate leaked credentials before attackers find them
Telemetry Note	Validation works by actively authenticating found secrets against their providers, which generates login events in provider audit logs (e.g., CloudTrail); blue teams can watch for unexpected verification-attempt patterns from scanner infrastructure

trufflehog from trufflesecurity has become one of the reference implementations in the secret-scanning niche, and the repository's roughly 28,000 stars plus AGPL-3.0 license reflect a mature, actively maintained project written in Go. The tool positions itself around a four-stage pipeline: Discovery, Classification, Validation, and Analysis. That framing matters, because most competing scanners stop at pattern matching, whereas trufflehog attempts to close the loop by determining whether a found credential is actually live. For a blue team or a penetration tester doing credential-hygiene review, that distinction is the whole point — a regex hit on a Postgres password string is noise until someone confirms the credential authenticates.

Discovery covers a broad set of sources. Beyond full git history scanning — including via ssh:// authentication inside Docker — the engine ingests chats, wikis, logs, API testing platforms, object stores, and plain filesystems. The README's quick-start section demonstrates source subcommands including git, github (org and repo level, with --issue-comments and --pr-comments for comment threads), s3, gcs, docker, and filesystem. The docker scanner is notably flexible in accepting remote registry images, docker:// URIs against the local daemon, and file:// tarballs, which makes it practical for scanning images already pulled into a build pipeline.

Classification is where the detector architecture shows through. The README claims over 800 secret types, each mapped back to the specific identity it belongs to — distinguishing an AWS access key from a Stripe key, a Cloudflare token, a database password, or an SSL private key. The badge tracking total detectors points at the pkg/detectors directory, which is the structural heart of the codebase: each detector encapsulates the regex/heuristic logic for recognizing a credential format and, critically, the verification routine for that provider. This per-provider plugin model is why adding coverage for a new SaaS is a contained contribution rather than a rewrite.

Validation is the capability that defines the tool. For every classifiable secret, trufflehog attempts to log in to confirm whether the credential is live, and the --results=verified flag filters output to only confirmed-active secrets. The sample output in the README shows the payoff: a verified AWS finding includes not just the raw key and commit metadata, but ExtraData with the account ID, arn, and user_id. That enriched attribution is what turns a scan result into a remediation ticket — you know which account and which principal to revoke. From a defensive telemetry standpoint, note that these validations are real authentication attempts against providers, so expect corresponding entries in provider audit logs.

Analysis extends validation for roughly the twenty most commonly leaked credential types. Instead of a single login probe, the tool issues many requests to enumerate what the credential can do: who created it, which resources it can access, and what permissions it holds on those resources. This is effectively automated scope assessment. For incident responders triaging a leaked key, that distinction between a read-only token and an administrator credential drives prioritization, and having it automated inside the scanner removes a tedious manual enumeration step from authorized investigations.

Output handling is well thought out for pipeline integration. The --json flag emits structured records with fields like SourceMetadata, DetectorName, DecoderName, Verified, Raw, and Redacted, suitable for feeding into downstream tooling. There is also native SARIF output via --sarif, which GitHub code scanning understands out of the box — findings appear inline on pull request diffs and in the repository's Security tab, and GitHub tracks them as new or fixed across runs rather than re-reporting stale issues. The README candidly notes that SARIF output is buffered fully in memory because the format requires a single JSON document, so very large result sets scale memory consumption proportionally. That is the kind of operational caveat that tells you the documentation is written by people who run the tool at scale.

CI integration is a first-class use case. The README recommends --since-commit pointed at the default branch, --branch set to the PR branch (or --branch HEAD when the target branch is already checked out), and the --fail flag, which returns exit code 183 when valid credentials are found — a clean gating mechanism for breaking builds. Environment variables like CIRCLE_BRANCH or TRAVIS_PULL_REQUEST_BRANCH can supply branch names dynamically. Combined with the --exclude-archived flag for org-wide sweeps, this covers both the pre-merge feedback loop and the periodic hygiene audit of an entire GitHub organization.

Installation paths are numerous: brew install trufflehog on macOS, official Docker images including an linux/arm64 variant for M1/M2 Macs, binary releases, a go install build from source, and a curl-pipe install script with an optional -v flag for signature verification. The supply-chain posture is worth calling out — all release artifacts get checksums signed with cosign under Sigstore's keyless model, pinned to the repository's GitHub Actions workflow identity. A secrets scanner that ships verifiable, signed artifacts is practicing what it preaches, and the README documents the full cosign verify-blob and sha256sum -c verification sequence.

A security detail that deserves attention: following CVE-2025-41390, trufflehog clones local git repositories to a temporary directory before scanning them, in line with Git's own security guidance about malicious .git configs. The --clone-path flag lets you control the destination, and --trust-local-git-config skips the defensive clone entirely — the README explicitly warns to only do that for trusted repos. This is a subtle but real attack vector when scanning third-party repositories, and the team's handling of it signals a project that takes scanner-side security seriously.

The commercial context is transparent: TruffleHog Enterprise extends the open-source core into continuous monitoring across Git, Jira, Slack, Confluence, Microsoft Teams, and Sharepoint, and the company states that revenue funds further open-source work. The open-source tool remains fully functional standalone. For S3 scanning, --role-arn support for IAM role assumption and --results=verified,unknown filtering show sensible cloud-native ergonomics; the unknown category is important because not every credential type can be safely validated, and untested findings shouldn't silently disappear.

In an authorized workflow, trufflehog fits naturally into several slots: pre-commit and CI gating to stop secrets before merge, post-incident scanning of a compromised repository's full history (a plain git rm of a key file leaves it in every prior commit, and trufflehog will find it there), cloud posture review of buckets and container images, and organizational audit sweeps. Run it against repositories and infrastructure you own or are contracted to assess; the validation step performs real authentications, so treating a scan like any other authorized test is the correct posture. As a defensive instrument, it is one of the few tools in this space that answers the question that actually matters — not just what leaked, but whether it still works and what it can reach.

Official project repository for trufflesecurity/trufflehog.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.