Self-Hosted Secrets Scanning: Gitleaks vs TruffleHog vs Detect-Secrets 2026

Complete Guide to Self-Hosted Secrets Scanning Tools 2026

Every week brings news of another company suffering a breach caused by hardcoded credentials, leaked API keys, or exposed certificates committed to version control. The root cause is almost always the same: sensitive material made it into a git repository, and nobody caught it before it became permanent history.

Self-hosted secrets scanning tools solve this problem at the source. They analyze your codebase, commit history, and CI pipelines to detect accidentally committed credentials, tokens, passwords, and other sensitive material before they reach production. Unlike cloud-based SaaS scanners, self-hosted tools keep your source code entirely within your infrastructure, giving you full control over detection rules, alerting, and remediation workflows.

Why Self-Host Your Secrets Scanner?

There are several compelling reasons to run secrets scanning on your own infrastructure rather than relying on a cloud provider:

Data sovereignty. Many organizations handle regulated data or operate under compliance requirements (SOC 2, HIPAA, GDPR) that restrict sending source code to third-party services. Self-hosted scanners never transmit your code outside your network.

Full detection customization. Cloud scanners offer a fixed set of detectors. When you host your own scanner, you can write custom rules that match your internal API key formats, proprietary credential patterns, and company-specific secrets.

Offline scanning. Self-hosted tools can scan air-gapped repositories, internal git servers, and code that never touches the internet. This is essential for organizations working with classified or highly sensitive projects.

Cost at scale. SaaS secrets scanning services typically charge per repository or per developer. Running your own scanner costs nothing beyond the compute resources, which is often negligible for tools that complete scans in seconds.

Integration freedom. When you control the scanner, you can wire it directly into your existing CI/CD pipelines, ticketing systems, Slack channels, and incident response workflows without being limited to the integrations a vendor provides.

The Contenders: Three Leading Open-Source Scanners

The self-hosted secrets scanning landscape is dominated by three tools, each with a distinct philosophy and strength:

Gitleaks: Fast Pattern-Based Scanning

Gitleaks is the most widely adopted self-hosted secrets scanner. Written in Go, it uses a curated database of over 700 regex-based detectors for AWS keys, GitHub tokens, Slack webhooks, database connection strings, and hundreds of other credential formats. Its strength is speed and accuracy for known secret types.

Installation

1
2
3
4
5
6
7
8

# Linux / macOS
curl -sSfL https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_amd64.tar.gz | tar xz -C /usr/local/bin

# Or with Homebrew
brew install gitleaks

# Or via Go
go install github.com/gitleaks/gitleaks/v8@latest

Basic Usage

Scanning the current repository:

1

gitleaks detect --source . --verbose

Scanning from a specific commit:

1

gitleaks detect --source . --log-opts "HEAD~50..HEAD"

Generating a report for CI pipelines:

1

gitleaks detect --source . --report-path gitleaks-report.json --report-format json

Custom Rules Configuration

Gitleaks ships with excellent defaults, but you can extend them with custom rules. Create a .gitleaks.toml file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

title = "custom-secrets-config"

[[rules]]
id = "internal-api-key"
description = "Internal API Key"
regex = '''ACME_API_[a-zA-Z0-9]{32}'''
keywords = ["ACME_API"]

[[rules]]
id = "database-connection-string"
description = "Database connection string with password"
regex = '''(?:[mysql](https://www.mysql.com/)|postgres|mongodb)://\S+:\S+@[^\s]+'''
keywords = ["mysql://", "postgres://", "mongodb://"]

# Override built-in rule severity
[[rules]]
id = "aws-access-key"
regex = '''(?:A3T[A-Z0-9]|AKIA|ASIA|ABIA|ACCA)[A-Z2-7]{16}'''
keywords = ["AKIA", "ASIA"]

Run with custom config:

1

gitleaks detect --source . --config .gitleaks.toml

Allowlists and False Positive Management

Gitleaks supports both regex-based and commit-based allowlists to suppress known false positives:

1
2
3
4
5
6
7
8
9

[[rules]]
id = "generic-api-key"
regex = '''[a-zA-Z0-9]{32,}'''

[[rules.allowlist]]
regexTarget = "match"
regexes = ['''EXAMPLE_KEY_[a-z]+''']
commits = ["abc123def456"]
paths = ['''test/fixtures/.*''']

This combination of pattern matching, custom rules, and allowlists makes Gitleaks the go-to choice for teams that want fast, reliable detection with minimal configuration overhead.

TruffleHog: Deep History Analysis with Verification

TruffleHog takes a different approach. Beyond regex patterns, it uses Shannon entropy analysis to detect high-entropy strings that look like secrets even when they do not match a known pattern. Its standout feature is optional secret verification, where it actively tests discovered credentials against the target API to confirm they are live, not expired.

Installation

1
2
3
4
5
6
7
8

# Linux / macOS
curl -sSfL https://github.com/trufflesecurity/trufflehog/releases/latest/download/trufflehog_$(uname -s)_x86_64.tar.gz | tar xz -C /usr/local/bin

# Or with Homebrew
brew install trufflehog

# Or via Go
go install github.com/trufflesecurity/trufflehog/v3@latest

Scanning Git History

TruffleHog excels at deep repository forensics:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Scan entire git history
trufflehog git file:///path/to/repo --only-verified

# Scan with verification (actively tests found secrets)
trufflehog git file:///path/to/repo --verify

# Scan a specific branch
trufflehog git file:///path/to/repo --branch main

# Scan with JSON output for CI
trufflehog git file:///path/to/repo --json > results.json

Scanning docker Images and S3 Buckets

TruffleHog goes beyond git. It can scan container images and cloud storage for leaked credentials:

1
2
3
4
5
6
7
8

# Scan a Docker image
trufflehog docker image --image myapp:latest --only-verified

# Scan an S3 bucket (requires AWS credentials)
trufflehog s3 --bucket my-bucket --only-verified

# Scan a GitHub organization
trufflehog github --org my-org --token ghp_xxxx

Writing Custom Detectors

TruffleHog supports custom detectors defined in YAML:

1
2
3
4
5
6
7

detectors:
  - name: "MyApp Secret Key"
    keywords:
      - "myapp"
      - "secret"
    regex:
      myapp_key: '[Mm][Yy][Aa][Pp][Pp]_SECRET_[A-Za-z0-9]{40}'

Load custom detectors at runtime:

1

trufflehog git file:///path/to/repo --custom-detectors my-detectors.yaml

Entropy Detection in Action

The entropy scanner catches secrets that regex alone would miss. For example, a randomly generated token like xR7kP2mQ9vL4nW8jT3yF6sA1cD5eG0hB has high Shannon entropy and will be flagged even without a matching pattern. This is powerful but generates more false positives, which is why TruffleHog pairs it with the --only-verified flag to filter results down to confirmed-live credentials.

TruffleHog is the best choice when you need thorough forensic analysis of repository history, want to verify that discovered secrets are actually active, or need to scan beyond git repositories into infrastructure artifacts like container images.

Detect-Secrets: Baseline-Driven Detection for Enterprise Teams

Detect-Secrets by Yelp takes a fundamentally different approach from the other two tools. Rather than scanning every file against a pattern database, it establishes a baseline of your repository’s current state and flags only new secrets that appear after the baseline was created. This baseline-driven workflow dramatically reduces false positives and makes it ideal for large codebases with many historically committed (but already rotated) credentials.

Installation

1
2
3
4
5
6
7

# Via pip
pip install detect-secrets

# Or clone and install
git clone https://github.com/Yelp/detect-secrets.git
cd detect-secrets
pip install -e .

Baseline Workflow

The baseline workflow is the core concept. First, initialize the baseline:

1
2
3
4
5
6
7
8
9

# Create a baseline of the current repository
detect-secrets scan > .secrets.baseline

# Review and audit findings interactively
detect-secrets audit .secrets.baseline

# Commit the baseline (not the secrets themselves)
git add .secrets.baseline
git commit -m "Add secrets baseline"

After the baseline exists, every future scan compares against it:

1
2

# Scan and show only new secrets (not in baseline)
detect-secrets scan --baseline .secrets.baseline

Custom Plugins

Detect-Secrets supports Python-based plugins for custom detection logic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# my_custom_plugin.py
from detect_secrets.core.potential_secret import PotentialSecret
from detect_secrets.plugins.base import BasePlugin

class MyAppSecretDetector(BasePlugin):
    """Detect MyApp proprietary API keys."""

    secret_type = "MyApp API Key"
    secret_pattern = r"MYAPP_API_KEY\s*[:=]\s*['\"]([A-Za-z0-9]{32})['\"]"

    @classmethod
    def analyze(cls, line, filename, **kwargs):
        import re
        match = re.search(cls.secret_pattern, line)
        if match:
            yield PotentialSecret(
                cls.secret_type,
                filename,
                match.group(1),
                line_number=0
            )

Register the plugin:

1

detect-secrets scan --plugin my_custom_plugin.py --baseline .secrets.baseline

Why Baseline Detection Matters

The baseline approach solves a real problem in enterprise environments. Many codebases contain credentials that were committed years ago, rotated since, and are no longer active. Pattern-based scanners flag every historical occurrence, creating alert fatigue. Detect-Secrets acknowledges reality: you cannot rewrite git history easily, so instead it focuses on preventing new leaks.

The workflow also integrates naturally with code review. When a developer adds a new secret, the baseline scan fails in CI, and the PR is blocked until the secret is removed or explicitly approved through the audit process.

Setting Up CI/CD Integration

All three tools integrate with CI/CD pipelines, but the setup differs. Here are practical configurations for GitHub Actions and GitLab CI.

GitHub Actions: Gitleaks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

name: Secrets Scan
on: [push, pull_request]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history for thorough scanning

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}
        with:
          config-path: .gitleaks.toml

GitHub Actions: TruffleHog

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

name: TruffleHog Scan
on: [push, pull_request]

jobs:
  trufflehog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: TruffleHog OSS
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified --results=verified

GitLab CI: Gitleaks

1
2
3
4
5
6
7
8
9

secrets-scan:
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --report-path gitleaks-report.json --report-format json --config .gitleaks.toml
    - cat gitleaks-report.json
  artifacts:
    reports:
      secret_detection: gitleaks-report.json
  allow_failure: false

Pre-Commit Hook (All Tools)

For developers, a pre-commit hook catches secrets before they leave the workstation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.0
    hooks:
      - id: gitleaks

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: [--baseline, .secrets.baseline]

Install once:

1
2

pip install pre-commit
pre-commit install

Choosing the Right Tool for Your Team

The three tools are not mutually exclusive. Many organizations run multiple scanners in parallel, each serving a different purpose:

Use Gitleaks if: You want fast, reliable, zero-maintenance scanning with excellent coverage of known secret types. It is the simplest to set up and the fastest to run. Most teams should start here.

Use TruffleHog if: You need deep forensic analysis of git history, want to verify that discovered secrets are actually live, or need to scan beyond repositories into Docker images, S3 buckets, and other infrastructure. The verification feature is uniquely powerful for incident response.

Use Detect-Secrets if: You manage a large codebase with historically committed credentials and need to focus on preventing new leaks rather than cataloging old ones. The baseline workflow fits naturally into enterprise code review processes.

A practical production setup often combines all three:

1
2
3
4
5
6
7
8
9

# Phase 1: Baseline with detect-secrets (one-time audit)
detect-secrets scan > .secrets.baseline
detect-secrets audit .secrets.baseline

# Phase 2: Pre-commit with gitleaks (fast blocking)
gitleaks protect --source . --staged --verbose

# Phase 3: Nightly deep scan with trufflehog (verification)
trufflehog git file:///path/to/repo --verify --only-verified

This layered approach catches secrets at every stage of the development lifecycle while keeping false positives manageable and developer friction minimal.

Conclusion

Secrets scanning is no longer optional. Whether you choose Gitleaks for its speed and breadth of pattern detection, TruffleHog for its deep analysis and credential verification, or Detect-Secrets for its pragmatic baseline-driven workflow, running a self-hosted scanner gives you complete control over your security posture.

The best strategy is not to pick one tool but to layer them: block obvious leaks at commit time with a fast pattern scanner, audit the full baseline with a comparison tool, and run periodic deep scans with verification to catch what the others miss. All three tools are open-source, free to run, and integrate seamlessly into existing CI/CD pipelines. Start with one, add the others as your needs grow, and ensure no credential ever slips into version control unnoticed.

Frequently Asked Questions (FAQ)

Which one should I choose in 2026?

The best choice depends on your specific requirements:

• For beginners: Start with the simplest option that covers your core use case
• For production: Choose the solution with the most active community and documentation
• For teams: Look for collaboration features and user management
• For privacy: Prefer fully open-source, self-hosted options with no telemetry

Refer to the comparison table above for detailed feature breakdowns.

Can I migrate between these tools?

Most tools support data import/export. Always:

1. Backup your current data
2. Test the migration on a staging environment
3. Check official migration guides in the documentation

Are there free versions available?

All tools in this guide offer free, open-source editions. Some also provide paid plans with additional features, priority support, or managed hosting.

How do I get started?

1. Review the comparison table to identify your requirements
2. Visit the official documentation (links provided above)
3. Start with a Docker Compose setup for easy testing
4. Join the community forums for troubleshooting