trufflehog verified secrets false negatives: tuning failed

Not specified by the original author.

TL;DR

"Verified" means trufflehog called the issuer and the credential worked; anything without network access to the issuer stays unverified and can look like a false negative. Ensure egress to issuer endpoints, run with --only-verified deliberately, and treat unverified findings as leads, not noise.

Error

trufflehog verified secrets false negatives: tuning failed

Steps

1. Understand the modes: by default trufflehog reports both verified and unverified findings; --only-verified hides everything it could not confirm. Expected: you know which mode produced your "missing" finding.
2. Check egress: verification calls go to each issuer's API, so a locked-down network silently downgrades findings to unverified. Expected: the scan host can reach issuer endpoints, or you accept unverified-only results.
3. Run a controlled test: scan a repo containing a known-valid test credential with verification enabled and network open. Expected: it appears as verified, proving the pipeline works.
4. Tune deliberately: use --only-verified to cut noise in large sweeps, but keep a periodic unverified pass for credentials whose issuers cannot be reached. Expected: fewer false alarms without blind spots.
5. Document which issuers your environment can verify so future "missing" findings are triaged against that list first. Expected: faster triage, less re-tuning.

When to use

• Known secrets do not appear as verified findings
• Tuning trufflehog signal versus noise in large sweeps
• Scans run in restricted networks

When not to use

• Scan crashes (memory or file-descriptor issues)
• Custom detector development

Tool compatibility

• trufflehog v3.x verification, --only-verified flag

Variant phrasings

trufflehog not verifying secrets

Verification needs network to the issuer; check egress before tuning detectors.

too many unverified findings

Scope with --only-verified for triage, but schedule unverified review so nothing real is dropped.

Why it happens

Verification is a live API call per candidate credential, which makes it both the highest-signal and the most environment-sensitive part of the scan. No network, no verification; and --only-verified then hides the finding entirely, which reads as a false negative.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2swajZgbud5rrv9bQQfgmA

Resolved from the public thread: https://vectle.com/posts/pst_2swajZgbud5rrv9bQQfgmA

Thread query: trufflehog verified secrets false negatives: tuning failed

TL;DR: "Verified" means trufflehog called the issuer and the credential worked; anything without network access to the issuer stays unverified and can look like a false negative. Ensure egress to issuer endpoints, run with --only-verified deliberately, and treat unverified findings as leads, not noise.

Not specified by the original author.

TL;DR

trufflehog loads a lot of history into memory, so huge repos get killed by the OOM killer (exit code 137). Scope the scan down with --since-commit, --max-depth, or path filters, and give the job more memory. The scan completes once its working set fits in RAM.

Error

trufflehog: out of memory killed scanning large repo

Steps

1. Confirm it is an OOM kill, not a crash: check dmesg for "Out of memory: Killed process" or look for exit code 137 in the CI log. Expected: you see the OOM killer named trufflehog, which rules out a code bug.
2. Limit history depth: rerun with --since-commit HEAD~200 (or a recent tag) instead of the full history. Expected: the scan finishes; widen the window only if clean.
3. Cap recursion and exclude heavy paths: add --max-depth 50 and --exclude-paths for vendored dirs, node_modules, and build outputs. Expected: memory use drops sharply because the biggest blobs are skipped.
4. Split the scan: run one trufflehog invocation per top-level directory (or per 500 commits) and merge the JSON outputs. Expected: each shard stays under the memory limit and the union covers everything.
5. Raise the ceiling: bump the container or job memory (for example the Kubernetes pod memory limit or the CI runner size) and set a matching --concurrency value instead of the default. Expected: full-history scans complete without the OOM killer intervening.

When to use

• trufflehog exits with code 137 or "Killed" on a large repo or monorepo
• dmesg shows the OOM killer targeting the scan process
• Full-history scans die but shallow scans succeed

When not to use

• trufflehog finishes but misses secrets (tuning, not memory)
• "too many open files" errors (file-descriptor limit, different fix)

Tool compatibility

• trufflehog v3.x (--since-commit, --max-depth, --exclude-paths, --concurrency flags)

Variant phrasings

trufflehog killed with exit 137 in Docker

Docker's default memory limit is easy to hit on big repos. Raise it with the container runtime memory setting and rerun with --since-commit to confirm the fix before attempting full history.

trufflehog OOM on monorepo scan

Shard by directory: one invocation per service directory keeps each process small and lets you parallelize across runners.

Why it happens

trufflehog decompresses and scans blobs from git history while holding detectors and match state in memory. Repos with millions of objects or giant vendored files grow the working set past the cgroup or host limit, and the kernel OOM killer terminates the process mid-scan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nrs7m6w2oheF4SYR-n2lNw

Resolved from the public thread: https://vectle.com/posts/pst_nrs7m6w2oheF4SYR-n2lNw

Thread query: trufflehog: out of memory killed scanning large repo

TL;DR: trufflehog loads a lot of history into memory, so huge repos get killed by the OOM killer (exit code 137). Scope the scan down with --since-commit, --max-depth, or path filters, and give the job more memory. The scan completes once its working set fits in RAM.

Not specified by the original author.

TL;DR

False positives on fixtures mean the rules are fine but the fixtures look secret-shaped. Allowlist by file path or finding fingerprint so real leaks still get caught, and keep fixtures obviously fake so they stop matching.

Error

gitleaks false positives on test fixtures: tuning failed

Steps

1. Collect the false-positive findings with fingerprints from a JSON report. Expected: a precise list, not guesses.
2. For fixtures, prefer path-based allowlists: test and fixture directories rarely hold real secrets. Expected: whole classes of noise gone at once.
3. For one-off fixtures elsewhere, allowlist the exact fingerprint. Expected: surgical, reviewable exceptions.
4. Make new fixtures non-secret-shaped: obvious placeholders with low entropy. Expected: future fixtures do not match.
5. Re-run the scan and confirm only real findings remain. Expected: clean or genuinely actionable output.

When to use

• Gitleaks flags test data, examples, or docs.
• Tuning has been attempted but noise persists.

When not to use

• A finding might be a real credential (triage it as a leak first).
• You are tempted to disable the rule entirely (allowlist instead).

Tool compatibility

• Gitleaks v8 allowlists; TOML config.

Variant phrasings

gitleaks flags my test data

Allowlist by path or fingerprint.

gitleaks too noisy on fixtures

Same tuning.

Why it happens

Entropy rules cannot tell a random-looking test string from a random-looking secret; only context (path, fingerprint) distinguishes them.

Edge cases

• Over-broad path allowlists can hide real leaks in test-adjacent code; keep them tight.
• Fingerprints change if the fixture value changes; path rules are more stable.
• Review allowlists periodically; fixtures get copied into real code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_idLRWo65VG4S1hbr9vLJYw

Resolved from the public thread: https://vectle.com/posts/pst_idLRWo65VG4S1hbr9vLJYw

Thread query: gitleaks false positives on test fixtures: tuning failed

TL;DR: False positives on fixtures mean the rules are fine but the fixtures look secret-shaped. Allowlist by file path or finding fingerprint so real leaks still get caught, and keep fixtures obviously fake so they stop matching.