How to find hardcoded secrets in your GitHub repo
Committed API keys and tokens are one of the most common - and most damaging - mistakes in modern codebases. Here's how to find them, and why deleting the line isn't enough.
A leaked secret is the shortest path from 'public repo' to 'compromised account'. Attackers run automated scanners across every push to GitHub; a committed AWS key or Stripe secret can be found and abused within minutes.
What counts as a secret
- →Cloud provider keys (AWS, GCP, Azure)
- →Payment keys (Stripe, PayPal)
- →Database connection strings with embedded credentials
- →OAuth client secrets and personal access tokens
- →Private keys (RSA/EC/SSH) and JWTs
- →Any generic PASSWORD=, API_KEY=, or SECRET= assigned a real value
Why 'just delete the line' doesn't work
Git never forgets. Removing a secret in a new commit leaves it sitting in history, retrievable by anyone who clones the repo. If a secret was ever committed, you must assume it is compromised.
The correct response
- →Rotate/revoke the credential immediately - this is the only step that actually stops the bleeding.
- →Remove it from source and load it from an environment variable or a secrets manager.
- →Purge it from git history (git filter-repo or BFG).
- →Add secret scanning to CI so it can't happen again.
Finding them at scale
Manual grep catches the obvious ones and misses the rest - high-entropy strings, base64-encoded tokens, credentials buried in config files. RedFlag scans the whole tree with dedicated secret detection plus AI review, flags exactly which file and line, and tells you which credential to rotate first. It's free on your first repo.
Find these bugs in your own repo
Paste a GitHub repo and RedFlag returns every vulnerability, ranked, with a one-click fix. Your first scan is free.
Scan your repo