PS Product SecurityKnowledge Base

🔎 TruffleHog and Gitleaks Deep Dive

Intro: TruffleHog and Gitleaks solve the same problem from different angles. TruffleHog leans toward verified, high-signal findings. Gitleaks leans toward fast, deterministic repo scanning with flexible rule control.

What this page includes

  • installation paths
  • local and Docker usage
  • CI integration
  • report interpretation
  • tuning recommendations

Install patterns

TruffleHog

# binary or package install path varies by OS
# Docker usage is often the easiest reproducible option
docker pull ghcr.io/trufflesecurity/trufflehog:latest

Gitleaks

brew install gitleaks

docker pull ghcr.io/zricethezav/gitleaks:latest

Use TruffleHog when you want a stricter “only verified hits block” gate.
Use Gitleaks when you want a fast scanner with a repo-local config, SARIF/JSON output, and easy pre-commit rollout.

Many teams use both:

  • Gitleaks as a broad local and CI detector;
  • TruffleHog as the “high-confidence blocker” layer.

Example local commands

TruffleHog

trufflehog git origin/main HEAD .
trufflehog filesystem . --json > trufflehog-report.json

Gitleaks

gitleaks detect --source . --report-format sarif --report-path gitleaks.sarif
gitleaks detect --source . --config .gitleaks.toml

Example GitLab CI pattern

secret_scan:
  stage: test
  image: ghcr.io/zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --report-format json --report-path gitleaks-report.json
  artifacts:
    when: always
    paths:
      - gitleaks-report.json

Tuning guidance

TruffleHog

  • start with verified results for blocking;
  • keep broad scans for visibility dashboards, not necessarily for hard fail;
  • document which detector classes are accepted as “warning only.”

Gitleaks

  • create a repo-local .gitleaks.toml;
  • tag rules by severity or ownership;
  • route generated files, fixtures, and testdata through explicit allowlists instead of broad path exclusions.

False-positive reduction

Use a triage loop:

  1. keep the finding;
  2. decide real or false;
  3. if false, create the smallest safe suppression;
  4. re-run locally and in CI;
  5. periodically review suppressions for drift.

Footer