Start with Identity
Subscribe
Tools

Top 6 Open-Source Secrets Scanning and Non-Human Identity Tools

The best open-source secrets scanning tools in 2026, from TruffleHog and Gitleaks to detect-secrets, git-secrets, Kingfisher, and NHI Hound, compared on validation, coverage, and the shift from finding secrets to governing non-human identities.

By SWI Community TeamUpdated 2026-08-2914 min read
Key takeaways
  • The 2026 shift in this category is from finding strings that look like secrets to determining whether a leaked credential is still live, what it can reach, and who owns it, which turns secrets scanning into non-human identity governance.
  • The leading open-source options are TruffleHog, Gitleaks, detect-secrets, git-secrets, Kingfisher, and NHI Hound.
  • The pragmatic stack is Gitleaks at pre-commit and in CI for speed, TruffleHog for verified history scans because it checks whether a secret still works, and platform-level scanning from your code host as a backstop.

Secrets scanning used to mean pattern-matching for strings that look like API keys. In 2026 the useful question changed: is this credential still live, what can it reach, and who owns it. GitGuardian's August 2026 research on leaked n8n API tokens is the clearest illustration, finding 4,576 tokens in public commits with roughly a third of reachable instances still accepting them. A dead key is noise; a live key with broad permissions and no owner is an incident.

That shift is why this category is converging with non-human identity governance. This guide covers the six open-source tools worth running, and what each contributes to a stack. For the vaulting side of the problem see top 6 open-source secrets management tools and what is secrets management.

Evaluation Criteria

We assessed each tool against the following dimensions:

  • Detection breadth, how many credential types are recognized
  • Verification, whether the tool checks that a found secret still works
  • Speed, suitability for pre-commit and CI gates
  • History scanning, ability to search the full git history
  • False positive management, baselines, allowlists, and tuning
  • Beyond detection, permission mapping, ownership, and revocation support

The Top 6 Open-Source Secrets Scanning Tools

1. TruffleHog

Best For: Verified scans that tell you which leaked credentials are actually live.

Overview

TruffleHog is the most capable open-source scanner in the category, detecting and classifying more than 800 credential types using both pattern matching and entropy analysis. Its differentiating feature is verification: the --verified flag checks discovered credentials against the provider to determine whether they still work, which converts a long list of maybes into a short list of incidents. Recent capability extends to enumerating the identity, resources, and permission scope behind a validated credential.

Key Features

  • 800-plus credential detectors with entropy analysis
  • Live verification of discovered secrets against providers
  • Permission and scope enumeration for validated credentials
  • Scans git history, filesystems, S3, and CI systems
  • Available as CLI, GitHub Action, and pre-commit hook

License AGPL-3.0.

Pros

  • Verification is the feature that makes findings actionable
  • Broadest detector coverage available in open source
  • Scope enumeration bridges scanning and non-human identity governance

Cons

  • Slower than Gitleaks, so less suited to a pre-commit gate
  • Verification means outbound calls to providers, which needs review in some environments
  • AGPL licensing needs consideration for embedding

2. Gitleaks

Best For: Fast pre-commit and CI gates that stop most leaks before they leave the laptop.

Overview

Gitleaks is a single fast Go binary with a well-tuned default ruleset and a clean pre-commit integration. Its role in a stack is prevention: it runs in under a second on a typical commit, so developers keep it enabled, which is the property that actually determines whether a scanning tool works. It does not verify whether a secret is live and does not help with rotation, which is why it pairs with rather than replaces TruffleHog.

Key Features

  • Very fast scanning suitable for pre-commit hooks
  • Configurable TOML ruleset with sensible defaults
  • Full git history scanning
  • Baseline support for accepting existing findings
  • GitHub Action and CI integrations

License MIT.

Pros

  • Fast enough that developers leave the hook enabled
  • Simple configuration and easy CI integration
  • Permissive licence with no embedding concerns

Cons

  • No verification, so findings need manual triage
  • Regex-based detection misses credential formats it has no rule for
  • No help with rotation or ownership

3. detect-secrets

Best For: Teams that want a baseline workflow to adopt scanning on an existing codebase.

Overview

detect-secrets from Yelp is built around a baseline file: you scan once, audit the findings, and commit a baseline that records what was reviewed. Subsequent scans report only new findings. That workflow solves the practical problem of adopting scanning on a repository that already contains years of accumulated false positives, which otherwise stops adoption before it starts.

Key Features

  • Baseline file workflow for incremental adoption
  • Interactive audit mode for triaging findings
  • Plugin architecture for custom detectors
  • Pre-commit hook integration
  • Entropy and keyword-based detection

License Apache 2.0.

Pros

  • The baseline model is the most practical answer to legacy false positives
  • Interactive audit makes triage a defined task rather than a chore
  • Extensible with organization-specific detectors

Cons

  • No verification of whether secrets are live
  • Baseline can become a place where real findings are buried
  • Smaller detector library than TruffleHog

4. git-secrets

Best For: A minimal, dependency-light guard against committing cloud credentials.

Overview

git-secrets from AWS Labs is deliberately small: it installs git hooks that scan commits against configurable patterns, with built-in rules for AWS credentials. It does one thing, has almost no dependencies, and is trivially auditable, which is why it persists in environments where installing a larger tool is difficult.

Key Features

  • Git hooks for commit, commit message, and merge
  • Built-in AWS credential patterns
  • Configurable custom patterns and allowlists
  • Minimal dependencies, shell-based
  • Scans history on demand

License Apache 2.0.

Pros

  • Tiny and auditable, which matters in restricted environments
  • Zero-friction installation
  • Effective for the specific case of cloud keys

Cons

  • Narrow detection compared with modern tools
  • Maintenance has slowed considerably
  • No verification, baseline workflow, or reporting

5. Kingfisher

Best For: Validation-first scanning with credential revocation from the command line.

Overview

Kingfisher is a newer entrant focused on the validation problem: rather than reporting everything that matches a pattern, it prioritizes confirming whether a credential is live, and can invalidate leaked tokens directly from the CLI for supported providers. That last capability closes the loop that every other tool leaves open, since finding a leaked secret and rotating it are usually separate manual processes.

Key Features

  • Validation-first detection to reduce false positives
  • Direct revocation of leaked tokens for supported providers
  • Fast scanning suitable for CI
  • Git history and filesystem scanning
  • Structured output for pipelines

License Open source (Apache 2.0).

Pros

  • Revocation from the tool removes the slowest step in remediation
  • Validation-first design keeps output small and credible
  • Actively developed against current provider APIs

Cons

  • Younger project with a shorter production track record
  • Revocation support varies by provider
  • Smaller detector library than TruffleHog

6. NHI Hound

Best For: Mapping dormant non-human identities and the trust paths they create.

Overview

NHI Hound approaches the problem from the identity side rather than the string side: instead of scanning for secrets in code, it maps the non-human identities that exist and the trust relationships between them, surfacing dormant service accounts and the paths they open. That is the governance question underneath secrets scanning, and it is the one that determines whether a leaked credential matters.

Key Features

  • Discovery of non-human identities and their trust relationships
  • Identifies dormant identities that retain access
  • Trust path analysis across connected systems
  • Graph-oriented output for investigation
  • Complements rather than duplicates secrets scanners

License Open source.

Pros

  • Answers the "what can this reach and who owns it" question directly
  • Surfaces dormant identities that scanners never see because their credentials never leaked
  • Fills a real gap between scanning and governance

Cons

  • New project with a limited track record
  • Coverage depends on the systems it can enumerate
  • Discovery output still needs an ownership process behind it

The stack that works

Layer these rather than choosing one.

Pre-commit: Gitleaks or detect-secrets, because speed determines whether the hook stays enabled.

CI: Gitleaks as a gate on the diff, plus TruffleHog with verification on a schedule against full history. Verification is what separates a backlog from an incident queue.

Platform: Your code host's own secret scanning and push protection as a backstop for everything that bypasses local hooks.

Governance: the part most programmes never reach. Every verified finding should produce four answers: rotate it, identify what it could reach, name an owner, and set an expiry. Without that, you rotate the same class of credential every quarter. See non-human identity and secrets rotation.

Two rules worth stating plainly. A secret found in git history is compromised regardless of whether the commit is removed, because it was published; rotate it. And the durable fix is not better scanning, it is having fewer long-lived secrets to leak: dynamic credentials from a vault, and platform-attested workload identity where the runtime can vouch for the caller.

The open-source identity landscape

This is one of a series covering open-source tooling across every identity category:

Frequently asked questions

What are the best open-source secrets scanning tools in 2026?
The leading open-source secrets scanning tools are TruffleHog, Gitleaks, detect-secrets, git-secrets, Kingfisher, and NHI Hound. TruffleHog leads on verification because it checks whether a discovered credential is still live, Gitleaks is the fastest option for pre-commit and CI, detect-secrets from Yelp is built around a baseline workflow, and NHI Hound maps dormant non-human identity trust paths.
What is the difference between TruffleHog and Gitleaks?
Speed versus validation. Gitleaks is a fast single binary with a solid default ruleset and a clean pre-commit hook, which stops most leaks before they leave the developer's machine, but it does not check whether a found secret still works. TruffleHog detects a much wider range of credential types and can verify them against the provider, which is what separates a real incident from a false positive. Most teams run both.
Does finding a secret in git history mean rotating it?
Yes, always, and this is the step teams most often skip. Removing the commit does not help: the credential was published and must be assumed compromised. Rotate it, then check the provider's audit log for use you cannot attribute. Verification tooling helps prioritize the order, not the decision.
Why is secrets scanning now framed as non-human identity management?
Because a leaked credential is only interesting in terms of what it can reach. Knowing that a token is live, what permissions it carries, which systems it can access, and who owns it turns a finding into a decision. That is the same set of questions non-human identity governance asks, which is why the tooling is converging: scanning finds the credential, NHI governance decides what to do about it.
Can these tools stop secrets reaching the repository at all?
Partly. Pre-commit hooks with Gitleaks or detect-secrets catch most accidental commits, and server-side push protection from your code host catches more. Neither is complete, because developers bypass hooks and secrets arrive through other paths such as CI logs and configuration files. Treat prevention as reducing volume, and keep detection and rotation as the reliable control.
Last reviewed By SWI Community TeamSuggest a correctionHow we research

Related on Start with Identity

Independent editorial review, no sponsorship. See more in our articles and rankings.