Secret Scanning Tools: TruffleHog vs Gitleaks vs GitGuardian vs GitHub

Secret scanning is the practice of automatically finding credentials (API keys, tokens, passwords, private keys) in places they should not be: source code, git history, CI logs, container images. The four names that come up in almost every evaluation are TruffleHog, Gitleaks, GitGuardian and GitHub secret scanning. They overlap a lot, but they are not interchangeable: they differ in license, in whether they verify that a secret is actually live, and in where they run.

This guide compares them fairly, based on each project's own documentation, and then covers the part most comparisons skip: what to do when a secret has already leaked, and why deleting it from your code does not solve anything.

How secrets detection works

Almost every tool combines three techniques:

• Provider-specific patterns. Many credentials have recognizable shapes. AWS access key IDs start with AKIA, GitHub personal access tokens start with ghp_, Stripe live secret keys start with sk_live_. A detector for each format gives high-precision matches.
• Entropy and keywords. Generic secrets (a random database password, an internal token) have no fixed prefix. Tools look for high-entropy strings near words like password, secret or token. This catches more but is noisier.
• Verification. The strongest signal is testing the candidate against the provider: if an AWS key can authenticate, it is live. Verification turns "this looks like a key" into "this is an active key", which changes how urgently you respond.

Why a secret in git history persists after you delete it

Git is an append-only history of snapshots. When you remove a key in a new commit, every earlier commit still contains it, and anyone can read it with git log -p or by checking out an old revision. Reverting the commit does not help either: a revert is just another commit on top.

It gets worse once the repository has been pushed. Every clone on a teammate's laptop, every fork, every CI cache and every mirror has its own copy. On a public repository you should assume the secret was seen: automated bots watch public pushes for credentials. That is why the first rule of secret remediation is simple: a leaked secret is a compromised secret. Rotate it. Cleaning history is a secondary step, covered below.

This is also why good scanners look at the full history, not only the current files. A key removed two years ago that still works is just as dangerous as one in main today.

TruffleHog

TruffleHog, from Truffle Security, is open source under the AGPL-3.0 license. According to its repository it classifies over 800 secret types, and its defining feature is verification: for every secret type it can classify, it can also try to log in to confirm whether the secret is live. Results are labeled as verified, unverified or unknown (verification was attempted but failed, for example because of a network error).

It scans much more than git: GitHub and GitLab, Docker images, S3 and Google Cloud Storage, Jenkins, Elasticsearch, Postman and the local filesystem. It ships a GitHub Action and pre-commit hook support. A typical history scan that only reports confirmed live credentials:

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

There is also a commercial TruffleHog Enterprise that adds continuous monitoring across Git, Jira, Slack, Confluence and Microsoft Teams. Good fit when you want free, verification-first scanning and are comfortable with the AGPL license terms for how you use it.

Gitleaks

Gitleaks is open source under the MIT license. It detects secrets with regular expressions combined with Shannon entropy, and everything is configurable in a .gitleaks.toml file: custom rules, entropy thresholds, keywords, allowlists (global or per rule) and path filters. It can also decode base64, hex and percent-encoded content before matching.

Since v8.19.0 the old detect and protect commands are deprecated in favor of three clear modes:

# scan the full git history
gitleaks git -v

# scan a directory or files (no git needed)
gitleaks dir ./config

# scan piped content
cat build.log | gitleaks stdin

Reports can be written as JSON, CSV, JUnit, SARIF or a custom Go template, which makes it easy to feed results into code scanning dashboards. The trade-off is explicit in its documentation: Gitleaks does not verify whether a detected secret is active. Good fit when you want a fast, permissively licensed, highly configurable scanner and are fine triaging matches yourself.

GitGuardian

GitGuardian is a commercial secrets security platform. Its CLI, ggshield, is open source under the MIT license and, per its README, detects and validates 500+ types of hardcoded secrets. Unlike the two tools above, ggshield needs a GitGuardian account and API key, because detection runs through GitGuardian's API. The README states that only metadata such as call time, request size and scan mode is stored from ggshield scans, not your files or secrets.

ggshield auth login
ggshield secret scan repo .

ggshield also integrates with pre-commit, GitHub Actions and other CI systems, and can scan Docker images and PyPI packages. On pricing, GitGuardian offers a free Starter tier for teams of up to 25 developers; paid tiers add things like public secrets monitoring, remediation workflows and, on Enterprise, self-hosted deployment. Good fit when you want a managed platform with dashboards, incident workflows and team management rather than assembling it from CLIs.

GitHub secret scanning and push protection

If your code lives on GitHub, you already have access to its native scanner. Secret scanning checks the entire git history across all branches, and also issues, pull requests, discussions and wikis. It is free for public repositories. For private and internal repositories you need GitHub Secret Protection, sold as a standalone product since April 2025 at USD 19 per month per active committer, and available to GitHub Team and Enterprise customers.

Three features stand out:

• Partner program. When GitHub detects a secret from a partner provider, it notifies that provider, which can then revoke the credential.
• Validity checks. GitHub can check with the issuer whether a detected secret is still active, so you can prioritize.
• Push protection. Pushes that contain supported secrets are blocked before they land, whether they come from the command line, the web UI, file uploads or the REST API. A contributor with write access can bypass with a reason ("used in tests", "false positive", "I'll fix it later"), and the bypass is recorded as an alert. Push protection for users is enabled by default on GitHub.com and stops you from pushing secrets to public repositories.

GitHub also supports custom patterns for organization-specific tokens and AI-detected generic secrets such as passwords. Good fit when you are all-in on GitHub and want prevention at the server, where no developer can forget to install a hook.

Comparison table

Prevention: pre-commit hooks, CI and push protection

The cheapest leak is the one that never reaches the remote. A layered setup looks like this:

1. Pre-commit hook on developer machines. With the pre-commit framework and Gitleaks, for example:

   # .pre-commit-config.yaml
   repos:
     - repo: https://github.com/gitleaks/gitleaks
       rev: vX.Y.Z  # pin the latest release tag
       hooks:
         - id: gitleaks

   Hooks are opt-in per machine, so treat them as a convenience, not a control.
2. A scan in CI on every pull request, failing the build on new findings. This catches everyone who skipped the hook.
3. Server-side push protection (GitHub push protection or equivalent) so the secret is blocked even when local tooling is missing.
4. Secrets out of code. Environment variables, a secrets manager, .env in .gitignore, and short-lived credentials such as OIDC federation in CI instead of long-lived cloud keys.

This fits the broader shift-left idea in DevSecOps, and it matters: hardcoded keys are a textbook example of the cryptographic failures covered in the OWASP Top 10.

A secret leaked: rotate first, purge second

1. Rotate or revoke the credential immediately at the provider. GitHub's own documentation puts this first: once the credential is invalidated, you may not need to rewrite history at all.
2. Check for abuse. Review the provider's access logs (CloudTrail for AWS, audit logs for GitHub, Stripe's dashboard) for activity between the leak and the rotation.
3. Move the new secret to a secrets manager and remove it from the code.
4. Optionally purge history. GitHub recommends git-filter-repo:

   # remove a file from all history
   git-filter-repo --sensitive-data-removal --invert-paths --path config/secrets.yml
   
   # or replace specific strings listed in a file
   git-filter-repo --sensitive-data-removal --replace-text ../passwords.txt
   
   git push --force --mirror origin

   Rewriting history changes commit SHAs, forks keep the old data, teammates must re-clone or rebase so they do not push the secret back, and on GitHub you need to contact GitHub Support to remove cached views and dereference affected pull requests.

How to choose

• Solo developer or small team on GitHub: turn on push protection and secret scanning where available, and add Gitleaks or TruffleHog as a pre-commit hook.
• You care most about signal: favor verification (TruffleHog, GitGuardian, GitHub validity checks) so live keys jump to the top.
• You need custom rules and a permissive license: Gitleaks and its .gitleaks.toml.
• Security team managing many repos and people: a platform (GitGuardian, GitHub Secret Protection, TruffleHog Enterprise) with dashboards and workflows.

Whatever you pick, remember that secrets are one layer. Dependencies need software composition analysis (and, for audits, an SBOM), and your own code needs static analysis such as AI SAST; see SAST vs DAST for how those fit together.

Where Nurbak fits

Nurbak is not a dedicated secrets platform; secret detection is one part of a full repository scan. When you connect GitHub and scan a repo, Nurbak detects provider credentials (AWS, GitHub, Stripe, OpenAI, Anthropic, Slack, private keys and more) in the current code and, with GitHub connected, in the most recent commits of git history. It stores only a redacted version of each secret and tells you to rotate it. The same scan runs its own self-hosted AI model over your code to find exploitable vulnerabilities with file and line (the analysis does not send your code to OpenAI or Anthropic), checks dependencies against OSV and flags GitHub Actions, Docker, Terraform and Kubernetes misconfigurations, with a 0 to 100 score. The free scan shows the three most important findings in full. Try the secret scanner or the full GitHub security scanner.

Bottom line

TruffleHog, Gitleaks, GitGuardian and GitHub secret scanning all find secrets in git history; the real differences are license, verification and where they run. Pick one for pre-commit, one for CI or the server side, and make rotation, not deletion, your default response. If you want to know what is already sitting in your repository, a secret scan is a good first step.

Related reading

• What is an SBOM
• What is DevSecOps
• SAST vs DAST
• OWASP Top 10 2025