Secrets detection

When it applies

Any source you can read: an in-scope repo, an exposed .git/ on a web server, public GitHub repos of the org, or CI/CD config. Live secrets are direct, high-impact findings.

Why it works

Secrets get committed and then "removed" — but git keeps history, so they persist in old commits, branches, and stashes. Config/CI files and client bundles also embed keys that ship to users.

Method

1. Scan history, not just HEAD: trufflehog git file://. --only-verified or gitleaks detect --source . -v — these walk every commit and (trufflehog) verify keys live.
2. Exposed .git on a target: git-dumper http://target/.git/ out/ then scan the recovered repo.
3. Org-wide OSINT: GitHub dorks / trufflehog github --org=<org> for public leaks (in scope only).
4. Client-side & config: grep JS bundles, mobile apps, .env, Dockerfiles, k8s manifests, CI YAML for keys and tokens.
5. Validate & scope impact: confirm the key works with a read-only call (e.g. aws sts get-caller-identity) — a live, privileged key is the report; a dead one is informational.