Your secret is still in git history (and shallow clones won't find it)

Here's a scenario that plays out constantly. A developer commits an API key by accident. Someone notices, they delete the line, push a "remove secret" commit, and everyone feels better.

The secret is still there. It's in the commit that *added* it. Git never forgets — that's the whole point of git.

Why most secret scans miss it

A lot of tooling clones repositories with --depth 1 to save time and bandwidth. A shallow clone only pulls the latest snapshot, so it sees the file *after* the secret was removed. The scan comes back clean. Everyone's happy. The key is live.

We learned this the hard way and changed how we scan. When our platform checks a repository for secrets, it pulls the full history so Gitleaks can walk every commit, not just the current tip. We proved it against a purpose-built test repo where a secret was added and then removed in a later commit — the shallow scan found nothing; the full-history scan found it immediately.

What to actually do about a leaked secret

Deleting the line is step three, not step one:

• Rotate first. Assume the moment a secret hits a remote, it's compromised. Revoke and reissue it.
• Then remove it from history if you must (git filter-repo), but understand forks and clones may still have it.
• Add a pre-commit hook so the next one never lands.
• Scan history, not just `HEAD`.

The uncomfortable truth: "we removed the secret" and "the secret is safe" are two very different statements. Only one of them involves rotating the key.