How to Scan Your Codebase for Hardcoded Secrets

Quick answer

• Secret scanners like Gitleaks and TruffleHog find API keys and tokens committed to your repository, including in git history.
• The most important fix is rotation: a leaked secret that still works is the real danger.
• Add scanning to CI so new leaks are blocked before merge.

Why scan

AI-assisted commits leak secrets at a notably higher rate than hand-written ones, because the assistant has no awareness of your secret-hygiene conventions and will happily hardcode a key or commit a .env file. A leaked secret that still validates is a live door into your systems — and many leaked credentials remain unrevoked for a long time. Scanning finds them before an attacker does.

Step 1 — Run a local scan

Install Gitleaks and scan your repository, including history:

gitleaks git --repo-path . --redact

How to verify it worked: the command reports any secrets it finds, with the values redacted. No output means no findings.

Step 2 — Scan full git history

Secrets committed and then deleted are still in history:

gitleaks git --repo-path . --log-opts="--all"

A secret removed from the working tree but present in an old commit is still exposed to anyone with repo access.

Step 3 — Block new leaks in CI

Add a Gitleaks job to your GitHub Actions pipeline so any new secret fails the build. This is the same secret-scanning step covered in Add Security Scanning to Your CI/CD Pipeline.

Step 4 — Rotate what you find

Finding is not fixing. Every detected secret must be rotated (revoked and replaced), because you must assume it was already copied. Then remove it from the repo and history.

Step 5 — Prevent recurrence

Move secrets to a manager or environment variables, and add a .gitignore rule for .env files. See How to Manage Secrets and Environment Variables Properly.

Where this bites vibecoders

The assistant doesn’t know your repo is public, or that the key you pasted into the prompt is production. It will place it in code because that’s the shortest path to “working.” Treat every generated commit as potentially containing secrets until a scanner says otherwise — the scanner is your convention, enforced automatically.

Where AI coding assistants get this wrong

• Committing .env files and real keys because nothing told it not to.
• Hardcoding credentials in config or code instead of referencing environment variables.
• Writing “example” config files that contain live-looking values that later get copied verbatim.

Checklist

• Scan locally before committing, and in CI before merging.
• Scan full git history, not just the working tree.
• Rotate every secret the scanner finds — assume it’s already leaked.
• Add .env and key files to .gitignore.
• Store secrets in a manager or environment, never in the repo.

FAQ

What is the difference between Gitleaks and TruffleHog?

Both are open-source secret scanners. Gitleaks is regex and entropy based, fast, and CI-friendly; TruffleHog also verifies found secrets against live APIs to reduce false positives. Many teams use both or pick one and add it to CI.

Do I need to rewrite git history?

If a real secret was ever committed, rewriting history (git filter-repo or similar) removes it from future clones, but rotation is the priority — anyone who already cloned it has the secret. Rotate first, clean history second.

Is scanning for secrets enough?

No. Scanning finds leaked secrets; it doesn’t stop them from being created. Pair it with secret managers and rotation so that even a leak is a contained event. See How to Automate API Key Rotation.

Related topics

• Why Do .env Files Keep Leaking Secrets?
• How to Manage Secrets and Environment Variables Properly
• How to Automate API Key Rotation

Sources

• Gitleaks
• TruffleHog