Gitleaks and TruffleHog for Bug Bounty Secrets Hunting

Gitleaks and TruffleHog for Bug Bounty Secrets Hunting

Secrets scanners are excellent lead generators and terrible judges. A 40-character token in an old commit might be a live production credential, a revoked test key, or random fixture data. Your job is to identify which one without turning verification into unauthorized access.

Only scan repositories and artifacts that are in scope. Public GitHub does not automatically mean the program accepts every employee fork, package, or leaked archive.

Gitleaks: fast rule-based coverage

Clone the approved repository with full history, then run Gitleaks against Git rather than only the working tree:

gitleaks git . --report-format json --report-path gitleaks-report.json

Rules cover recognizable providers, private keys, generic high-entropy assignments, and common config formats. Baselines help large projects suppress known false positives, but read baseline entries too—teams sometimes baseline a real credential instead of revoking it.

Useful places beyond .env include CI workflows, Terraform state references, Docker build arguments, mobile configuration, example scripts, deleted JSON files, and release tags. Search commit history around each finding. The surrounding diff often explains whether a key was rotated or merely moved.

TruffleHog: verification-aware discovery

TruffleHog combines detectors with provider verification for supported secret types:

trufflehog git file://$PWD --results=verified,unknown --json

“Verified” is powerful evidence, but understand what the detector did. A read-only identity endpoint may be safe; a cloud API call might create logs or touch resources. Follow program rules, disable verification if active checks are not allowed, and never use a token to list customer data.

Run both tools because their detector sets and history traversal differ. Deduplicate by secret fingerprint, file, and commit. Do not paste raw live values into your normal notes or ticket screenshots.

Triage like a hunter

Ask four questions:

1. Is it syntactically valid for the named provider?
2. Is there evidence it belongs to the target, such as account ID or hostname?
3. Is it still active, based on a permitted non-destructive check?
4. What privilege and environment does it reach?

A revoked Stripe test key is usually Informational. A production cloud key with write access can be Critical. If validation would expose data or alter state, stop after identity-level proof and ask the program to verify privileges internally.

For private keys, match the public key or certificate instead of attempting login. For database strings, DNS resolution and product ownership may establish relevance without opening a connection. Redact all but the first and last few characters in the report, and use the platform's secret-handling channel if available.

Reporting and cleanup

Include repository URL, commit hash, file path, introduction date, deletion date if any, detector output, and the least-invasive evidence of validity. Explain that deleting the current file does not erase Git history. Recommend immediate revocation, log review, history rewriting where appropriate, secret-manager migration, pre-commit scanning, and CI blocking for new leaks.

OWASP describes exposed pipeline credentials under Insufficient Credential Hygiene. CWE-798 fits hard-coded credentials, while CWE-200 may fit accidental disclosure. PortSwigger's web-security material is useful once a discovered key unlocks an in-scope web surface, but the scanner result itself is not an exploit. Treat every candidate as sensitive from the moment it appears on your terminal.