A single hardcoded credential in a Git repository is a breach waiting to happen. API keys, database passwords, cloud access tokens, and private keys get committed by accident constantly — and because Git keeps history forever, deleting the line in a later commit does nothing. The secret is still one git log away for anyone who can clone the repo. This guide shows you how to find secrets in both your current files and your full history, block new ones before they land, and properly remediate a credential that has already leaked.
Prerequisites
- A local clone of the repository you want to scan (full history, not a shallow clone).
- The Safeguard CLI installed:
curl -sSfL https://get.safeguard.sh/install.sh | sh. - Ability to rotate any credential you find — finding a secret without rotating it fixes nothing.
Step 1: Scan the working tree
Start with what is on disk right now:
sg secrets scan .
The scanner combines high-confidence provider patterns (AWS, GCP, Stripe, GitHub tokens, private keys) with entropy analysis to catch generic high-randomness strings. Output names the file, line, and detector:
Scanning working tree...
HIGH AWS Access Key ID config/prod.env:14
HIGH Stripe Live Secret Key src/billing/client.ts:8
MEDIUM Generic high-entropy scripts/deploy.sh:22
3 findings
Step 2: Scan the full Git history
The working tree is only the present. Scan every commit to find secrets that were "removed" but still live in history:
sg secrets scan --history
This walks all reachable commits and reports the exact commit and blob where each secret was introduced. It is common to find far more here than in the working tree — those are the credentials that need rotating today.
Step 3: Suppress verified false positives
Test fixtures and example keys generate noise. Record intentional non-secrets in an in-repo, reviewable allowlist rather than turning detectors off:
# .safeguard/secrets-allow.yaml
rules:
- path: "test/fixtures/**"
reason: "Synthetic keys for unit tests — SEC-2041"
reviewer: "daniel@example.com"
- detector: generic-high-entropy
path: "docs/examples/**"
reason: "Illustrative placeholders in docs"
reviewer: "daniel@example.com"
Because the allowlist is committed and code-reviewed, no one can silently whitelist a real secret.
Step 4: Block new secrets at commit time
The cheapest secret to fix is the one that never gets committed. Install the pre-commit hook so staged changes are scanned before they land:
sg secrets install-hook
Now any commit containing a detected secret is rejected locally, with the offending line printed, before it ever reaches the remote.
Step 5: Add a history scan to CI
Catch anything that slips past local hooks — and cover contributors who did not install them:
- uses: safeguard-sh/gate@v2
with:
token: ${{ secrets.SAFEGUARD_TOKEN }}
secrets-scan: true
fail-on: high
Verify the result
Confirm the repo is clean and the guardrails are live:
# Working tree and history both return zero high-severity findings
sg secrets scan . --fail-on high
sg secrets scan --history --fail-on high
# The pre-commit hook is installed
cat .git/hooks/pre-commit | grep -q safeguard && echo "hook active"
If a history scan still reports a secret after you thought you removed it, remember that deleting the file in a new commit does not purge history — see the FAQ below for the correct remediation.
How Safeguard streamlines this
Detection is only half the job; the dangerous half is what happens after a leak. Safeguard's CLI runs the same secret-detection engine locally, in the pre-commit hook, and in CI, so a developer sees a finding at the earliest possible moment instead of discovering it in a failed pipeline. When a real secret is found, Griffin AI generates the remediation as a reviewable pull request — replacing the hardcoded value with an environment-variable or secret-manager reference and flagging the exact credential to rotate — so cleanup is a review-and-merge instead of a manual refactor. Because secret findings share the same policy, ignore, and reporting model as your dependency and container scans, they show up in one dashboard rather than a separate silo. If you are comparing tools, the comparison hub shows how a unified engine differs from stitching a standalone secret scanner into your stack. See plans on the pricing page.
Ready to scan your history? Connect a repository at app.safeguard.sh/register.
Frequently Asked Questions
Does deleting a secret from a file remove it from Git? No. Git retains the full history of every file, so the secret remains in earlier commits and is trivially recoverable by anyone who can clone the repo. A working-tree fix hides it from the current checkout only; the credential must still be treated as compromised.
How do I remove a secret that is already in Git history?
First rotate the credential immediately — assume it is already compromised. Then rewrite history to purge the blob using a tool such as git filter-repo, force-push the cleaned branch, and have all collaborators re-clone. Rotation is the step that actually protects you; history rewriting is cleanup.
What is the difference between pattern and entropy detection? Pattern detection matches known credential formats (like an AWS key prefix), giving high-confidence, low-noise hits. Entropy detection flags strings whose randomness looks credential-like even without a known format, catching custom or unusual secrets at the cost of more false positives. Using both maximizes coverage.
How do I handle test fixtures full of fake keys? Add them to a committed, code-reviewed allowlist scoped by path or detector, with a reason and reviewer for each entry. This suppresses the known-safe noise while keeping the decision visible in version control, so a real secret can never be quietly whitelisted.
Should secret scanning run pre-commit or in CI? Both. A pre-commit hook is the cheapest place to stop a leak because the secret never leaves the developer's machine. A CI scan is the safety net that catches anyone who has not installed the hook and enforces history scanning on the server side.
Explore the Safeguard CLI and Griffin AI, compare approaches on the comparison hub, or review plans on the pricing page. Full detector and remediation docs live in the Safeguard docs.