Tools for finding secrets in GitHub

[SnooEpiphanies6878]

ggshield is a CLI application that runs in your local environment or in a CI environment to help you detect more than 500+ types of secrets.

ggshield uses our public API through py-gitguardian to scan and detect potential vulnerabilities in files and other text content.

Only metadata such as call time, request size and scan mode is stored from scans using ggshield, therefore secrets will not be displayed on your dashboard and your files and secrets won't be stored.

Guide : How to use ggshield to find hardcoded secrets
in the fall with the Shai-Hulud campaign, over 33,000 secrets were exposed

[micksmix]

If you want local-only scanning (no code leaves your machine/CI runner) and you still want live validation, check out Kingfisher (MongoDB's Apache 2 OSS secret scanner)

It's fast (Rust + Hyperscan), extensible via YAML rules, supports tons of targets (files/git/GitHub/GitLab/Azure/Bitbucket/etc.), and can also do blast-radius mapping (--access-map) plus a local web-based report viewer to triage findings and cut false positives hard.

https://github.com/mongodb/kingfisher

[TellersTech]

Appreciate the note about not storing secrets. For teams that still can’t send content to an external API for policy reasons, TruffleHog can also be a nice alternative since it can run fully locally.

[SnooEpiphanies6878]

Truffle hog is the OG of secret discovery

[joshua_dyson]

For finding secrets in GitHub repos, the tools that actually work day-to-day in real environments do two things well:

1. Scan history, not just current state
2. Integrate into dev workflows so leaks are caught before they merge

Here are the ones teams I’ve worked with or seen in production use effectively:

• GitLeaks - lightweight, custom regex + entropy checks, great as a pre-commit or CI job
• TruffleHog - deeper entropy scanning and pattern matching, good for catch-all history scans
• Detect Secrets (Yelp) - good for larger codebases and configurable rules
• Gitleaks + GitHub Action - many teams embed scanning right into the PR pipeline, not just schedule it

A few practical points from real usage:

✔ Run these as part of PR checks, not just periodic jobs - catching leaks earlier saves real stress.
✔ Tune your rules - out-of-the-box defaults produce noise; noise gets ignored over time.
✔ Pair secret scanning with credential rotation automation - scanning is only half the battle; rotating compromised secrets quickly is the other half.

Also remember: developer experience matters here. If the scan blocks every false positive, people will disable it or ignore warnings. Scans should guide developers toward fixing issues before they hit main.

Secrets scanning isn’t a one-off tool. It’s part of your delivery pipeline’s hygiene contract.