repo-secret-scan

name

repo-secret-scan

description

Scans a git repo for hardcoded secrets, personal info, and sensitive data before it gets published. Checks both current files AND the full git commit history (because secrets in old commits are still exposed on push). Finds API keys, passwords, tokens, home directory paths with usernames, email addresses, private keys, database connection strings, and more. Reports findings by severity with exact file and line locations, and gives actionable remediation steps. Use this skill whenever the user asks to: check if a repo is safe to publish/push/open-source, scan for secrets or credentials, check for personal info, audit before making a repo public, "is this ready to push?", "anything private in here?", or similar pre-publish safety checks. Also use it proactively when the user is about to push or publish a repo and hasn't explicitly asked for a security check — it's better to catch issues early.

Repo Secret Scan

Scan a repo for secrets and personal info before publishing. The golden rule: if someone else can read your repo (even the git history), they can read everything that was ever committed.

Step 1: Run the scanner

Run the bundled scan script on the target repo:

python /path/to/skill/scripts/scan.py --path /path/to/repo

The script scans:

• All text files in the working tree (skips binary files, lock files, node_modules, .git)
• Full git commit history (all commits, all branches) — added lines only

It reports findings grouped by severity:

• critical — API keys, passwords, tokens, private keys (block publishing immediately)
• high — home directory paths with usernames (/home/alice/), email addresses
• medium — private IP addresses, database connection strings

Flags:

• --no-history — skip git history (use only if the repo has no git history yet)
• --json — machine-readable output
• --path . — default, scans current directory

Step 2: Triage the findings

Not every finding is a real problem. After running the scan:

Critical findings — always investigate. Even if the secret is now in a .env file that's gitignored, if it was ever committed, it's in the history. Ask: "Was this ever committed?"

High findings (paths like /home/alice/) — personal username in a path is a privacy leak. Replace with a relative path, an env var, or a placeholder before publishing.

Email addresses — check if it's intentional (author contact in README is fine) or accidental (personal email in a config file is not).

False positives are common — the scanner can't know if password = "changeme" is a real credential or a test fixture. Use judgment and tell the user what you found and why it matters.

Step 3: Fix the issues

Fix in working files

For secrets in current files, the fix is usually:

• Move to environment variables: API_KEY = os.environ["ANTHROPIC_API_KEY"]
• Move to a .env file and add .env to .gitignore
• Replace personal paths with relative paths or ~ or an env var

Fix in git history

This is the harder part. If a secret was committed (even in an old commit that was later deleted), it's still in the git history and will be pushed to GitHub.

Option A — git filter-repo (recommended)

# Install
pip install git-filter-repo

# Remove a specific file from all history
git filter-repo --path secrets.txt --invert-paths

# Replace a string everywhere in history
git filter-repo --replace-text <(echo "sk-ant-actual-key==>REDACTED")

# After this, force-push is required:
git push --force-with-lease

Option B — BFG Repo Cleaner (simpler for removing specific strings)

# Download BFG: https://rtyley.github.io/bfg-repo-cleaner/
java -jar bfg.jar --replace-text passwords.txt my-repo.git

Option C — Start fresh

If the history is messy and the project hasn't been published yet, the cleanest fix is:

# Collapse all history into one clean commit
git update-ref -d HEAD        # erase history (only works before first push)
git add -A
git commit -m "initial commit"

Prevent future leaks

After cleaning, suggest adding to the repo:

1. A .gitignore entry for any secrets files (.env, *.pem, *_rsa, config.local.*)
2. A .env.example file with placeholder values showing what variables are needed
3. Optionally: a pre-commit hook using detect-secrets or gitleaks for ongoing protection

Step 4: Re-scan to confirm

After fixes are applied, run the scan again to confirm no issues remain:

python /path/to/skill/scripts/scan.py --path /path/to/repo

A clean scan exits with code 0. A scan with critical findings exits with code 1.

Step 5: Tell the user the verdict

Give a clear, direct answer:

• How many files/commits were scanned
• What was found (by category and count)
• What needs to be fixed before publishing (if anything)
• What looks fine

If everything is clean, say so plainly. If there are blockers, be specific: "You have 2 critical findings — an Anthropic API key at config.py:14 and a hardcoded path at scripts/run.sh:8. These need to be fixed before pushing."