🕵️ Stopping Secret Leaks Before They Hit Git History: Scanning the Whole Pipeline

A credential committed to Git is one of the most common ways breaches start, and one of the most painful to clean up — because once it’s in history, deleting the line does nothing. The secret still lives in every clone, every fork, and the reflog. The standard “oops, I removed it in the next commit” makes the diff look clean while leaving the credential sitting in the repo’s past, fully recoverable by anyone. The only real fixes are prevention before the commit and rapid revocation when prevention fails.

This is a distinct problem from managing secrets in a vault — it’s about keeping them out of source control in the first place. Here’s the layered approach that actually holds.

Layer one: block it at the developer’s machine

The cheapest place to catch a secret is before it’s ever committed, with a pre-commit hook. gitleaks or detect-secrets run on staged changes and refuse the commit if they spot something that looks like a key:

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

pre-commit install   # wire it into the local git hooks

Now a commit containing an AWS key, a private key block, or a high-entropy token gets rejected locally. The developer fixes it before it ever leaves their laptop, and the secret never enters history. This layer has the best ergonomics — instant feedback, no breach to clean up.

The catch: local hooks are opt-in and bypassable with --no-verify. They’re necessary but not sufficient, which is why they’re layer one of several.

Layer two: enforce it in CI

Because local hooks can be skipped, you scan again in CI where it can’t be bypassed. A pipeline step runs the same scanner against the push and fails the build on a finding:

secret-scan:
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0          # full history so the scan sees everything
    - name: gitleaks
      uses: gitleaks/gitleaks-action@v2

fetch-depth: 0 matters — a shallow checkout only scans the latest commit and misses a secret introduced three commits back in the same PR. Scan the full diff range of the PR so nothing slips through the gap between commits.

Many platforms also offer native push protection (GitHub secret scanning, GitLab equivalents) that rejects a push containing a recognized credential pattern before it’s even accepted. Turn that on — it’s a server-side backstop that no --no-verify can defeat.

Layer three: scan the history you already have

Prevention only protects you going forward. You almost certainly have secrets lurking in existing history. Run a full-history scan to find them:

gitleaks detect --source . --report-format json --report-path leaks.json

This walks every commit and flags anything that ever looked like a secret. Expect to find things — old keys, a .env someone committed in 2022, a private key in a test fixture. For each real finding, the response order matters: revoke first, scrub second. Rewriting history with git filter-repo or BFG removes the secret from the repo, but you can never be sure no one cloned it, so the credential must be rotated regardless. Treat any committed secret as compromised, full stop.

Taming false positives

Scanners flag high-entropy strings, and not every high-entropy string is a secret — test fixtures, example keys, checksums, and UUIDs all trip them. Unmanaged, the noise trains your team to ignore findings, which defeats the point. Tune it:

• Maintain an allowlist for known-safe patterns and paths (test fixtures, documentation examples), checked into the repo so the exceptions are reviewable.
• Use # gitleaks:allow inline for a specific justified line, so the exception is visible in the diff rather than hidden in config.
• Prefer verified-secret detection where available — some scanners and platform features actually test whether a detected credential is live, which cuts false positives dramatically.

The goal is a scanner the team trusts, so a finding means “stop and look,” not “click past it.”

The full-pipeline picture

Layered, the controls cover each other’s gaps:

1. Pre-commit hook — fast local feedback, catches most leaks before they exist. Bypassable, so:
2. CI scan — enforced, full-PR-diff, can’t be --no-verify’d away. Misses pushes that skip the PR flow, so:
3. Server-side push protection — platform-level backstop on every push.
4. Periodic full-history scan — finds what already leaked and what slipped through.
5. A revoke-first runbook — because the only safe assumption about a committed secret is that it’s burned.

No single layer is sufficient — local hooks get skipped, CI can be misconfigured, push protection only knows certain patterns. Stacked, a secret has to evade all of them, which is a much harder ask than slipping past any one.

The payoff is concrete: the most common breach entry point — a credential someone pasted into a config file and forgot — gets caught at the keyboard instead of discovered six months later in an attacker’s hands. Pair this with OIDC keyless auth so there are fewer long-lived secrets to leak in the first place, and the surface keeps shrinking.

More secrets and pipeline hardening lives in our security and hardening guides. When a PR touches scanner config or adds an allowlist entry, the AI code review assistant helps catch the over-broad exclusion that would quietly blind your secret scanning.

Scanner configs are illustrative. Tune allowlists and validate full-history coverage against your own repositories, and always rotate any committed credential.