Leaked Secrets in Git History: How to Scan and Remove Them

Git History Is a Permanent Record - Including Your Mistakes

Git's core design principle is immutability: once something is committed, it exists in the object store forever unless you explicitly rewrite history. This is a feature for code - you can always go back. It's a disaster for secrets.

When a developer adds a secret to a file, realizes the mistake, removes it, and commits again, the secret still lives in the earlier commit. Anyone running git log -p, git show <commit-hash>, or browsing the repository's commit history on GitHub can see it in plain text.

GitGuardian's 2024 State of Secrets Sprawl report found that over 12.8 million secrets were detected in public GitHub repositories in 2023 - a 28% increase from the prior year. More concerning: GitGuardian found that 90% of valid secrets remained valid more than 5 days after detection, meaning developers were not rotating credentials after exposure. The time-to-exploit is far shorter: automated scanners find and attempt to use exposed AWS credentials within minutes of a public push.

How Secrets End Up in Git History

The most common paths to a secret ending up in Git history are:

• Direct commit: Developer or AI tool writes a working credential directly into a config or source file
• Committed .env file: The .env file was committed before being added to .gitignore
• Debug code: A developer temporarily hardcodes a key while debugging, then forgets to remove it before committing
• AI tool generation: Bolt, Lovable, Cursor, or v0 generates code with a working key you pasted into the prompt, embedding it in the source file
• Copy-paste from documentation: A real key is pasted in where a placeholder should go

Apiiro's 2024 research found that repositories generated or scaffolded by AI coding assistants had a significantly higher rate of hardcoded credentials than manually written code. The speed of AI generation encourages "get it working first, clean it up later" patterns - and cleanup often never happens.

Scanning Your Full History with Gitleaks

Gitleaks is the most widely used open-source tool for scanning Git repositories for secrets. Unlike a grep on your current files, it walks every commit in your history and checks every diff.

// ❌ BAD - Secret committed in a past file, then deleted
// commit a3f89c2 (2 months ago)
// src/lib/openai.ts

import OpenAI from 'openai';

// Pasted in while testing - "I'll move this to env later"
const client = new OpenAI({
  apiKey: 'sk-proj-EXAMPLE-NOT-REAL-KEY-abc123xyz'
});

// commit b7d12e1 (1 month ago) - "remove hardcoded key"
// The fix ONLY removed the line. The key still lives in commit a3f89c2.

To scan your repository with Gitleaks:

// Running Gitleaks locally (install with: brew install gitleaks)
// Scan the full git history of a repository:
// gitleaks detect --source . --log-opts="--all"

// Output example:
// ○  gitleaks
//     ○  Finding:     apiKey: 'sk-proj-T3BlbkFJQXRsY2x4NWZhZ2xhY2x4'
//     ○  Secret:      sk-proj-T3BlbkFJQXRsY2x4NWZhZ2xhY2x4
//     ○  RuleID:      openai-api-key
//     ○  Entropy:     5.30
//     ○  File:        src/lib/openai.ts
//     ○  Line:        5
//     ○  Commit:      a3f89c2d14f8a3b7e9c1d4f6a8b2e5c7d9f1a3b5
//     ○  Author:      [email protected]
//     ○  Date:        2024-01-15T10:23:41Z

Removing Secrets From Git History

Once you have identified a secret in history, you have two tools available: git filter-repo (the modern, recommended approach) or BFG Repo Cleaner (faster for large repositories). Both rewrite every commit that contained the secret, creating new commit hashes.

Important: after rewriting history, you must force-push and everyone who has cloned the repo must re-clone or re-base. This is a destructive operation. Coordinate with your team before doing it.

// ✅ GOOD - Removing a secret from entire Git history
// Step 1: Install git-filter-repo
// pip install git-filter-repo

// Step 2: Replace the secret with a placeholder in all commits
// git filter-repo --replace-text replacements.txt

// replacements.txt content:
// sk-proj-T3BlbkFJQXRsY2x4NWZhZ2xhY2x4==>REMOVED_SECRET

// Step 3: Force push all branches
// git push origin --force --all
// git push origin --force --tags

// Step 4: Delete and re-clone on all developer machines
// The old commits still exist in GitHub's cache for ~3 months.
// Contact GitHub support to expedite cache purge for critical leaks.

How to Find Leaked Secrets Across Your History

How to Fix a Leaked Secret: The Complete Workflow

Scanning is only the first step. Here is the complete remediation workflow once a secret is found in history:

1. Rotate immediately: Go to the provider's dashboard (AWS IAM, OpenAI, Stripe, GitHub) and generate a new credential. Revoke the old one. Do this before rewriting history - assume the key is already compromised.
2. Update your environment: Set the new credential in your production environment (Vercel secrets, Railway variables, AWS Secrets Manager) and in your local .env file.
3. Rewrite history: Use git filter-repo to replace every instance of the old secret across all commits.
4. Force push: Push the rewritten history to your remote and coordinate team re-clones.
5. Add prevention: Install Gitleaks as a pre-commit hook so secrets are blocked before they can be committed.

Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase and full Git history for leaked secrets using Gitleaks, flagging the specific file paths, line numbers, and commit hashes where credentials were introduced. Free to sign up.

Prevention: Pre-Commit Hooks and CI Checks

// ✅ GOOD - Gitleaks pre-commit hook (add to .git/hooks/pre-commit)
// Or use via pre-commit framework: https://pre-commit.com

// .pre-commit-config.yaml
// repos:
//   - repo: https://github.com/gitleaks/gitleaks
//     rev: v8.18.0
//     hooks:
//       - id: gitleaks

// GitHub Actions CI check (.github/workflows/secrets-scan.yml):
// - name: Scan for secrets
//   uses: gitleaks/gitleaks-action@v2
//   env:
//     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The Veracode 2024 State of Software Security report found that applications with automated security gates in CI pipelines had 5x faster mean time to remediate vulnerabilities compared to those relying on manual review. A pre-commit hook that takes 2 seconds to run can prevent months of remediation work.

FAQ