/secrets-audit

name: secrets-audit
description: "Find leaked secrets in source code, Git history, build artifacts, and infrastructure — and audit the secrets-management posture preventing future leaks. Use when the user mentions 'secrets audit,' 'secret scanning,' 'leaked credentials,' 'API key in code,' 'gitleaks,' 'trufflehog,' 'git history scan,' 'secrets management,' 'vault audit,' 'rotation policy,' 'AWS Secrets Manager,' 'HashiCorp Vault,' 'Doppler,' '1Password Secrets Automation,' 'sealed-secrets,' 'External Secrets Operator,' or needs to find or prevent credential exposure."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch

Secrets Audit — Credential Exposure and Secrets-Management Review

Two halves: (1) find secrets that have already leaked into source, history, or artifacts, and (2) audit the secrets-management posture that determines whether future leaks happen.

Most secret leaks aren't "we forgot to redact" — they're "we never had a system, so every developer made up their own approach." This skill covers both the cleanup and the prevention.

Cross-references: `dependency-audit` (CI-related secrets risk in build-time exposure), `iam-audit` (workload identity federation as the alternative to long-lived keys), `owasp-audit` A02 (in-source secret patterns).

Part 1 — Find leaked secrets

Provider key prefixes (high-confidence patterns)

The most useful first sweep is grep against known provider key prefixes. False positives are low and matches are almost always real.

# Stripe
grep -rE "(sk_live_|sk_test_|rk_live_|whsec_)[A-Za-z0-9]{20,}" . \
  --include="*.{js,ts,jsx,tsx,py,rb,go,java,php,sh,env,yml,yaml,json}"

# AWS access keys
grep -rE "(AKIA|ASIA)[A-Z0-9]{16}" .

# AWS secret keys (40 chars, base64-y) — high FP rate, use with caution
grep -rE "[A-Za-z0-9/+=]{40}" . --include="*.env*" --include="*.json"

# GitHub
grep -rE "gh[pousr]_[A-Za-z0-9]{36}" .

# Google Cloud API key + service-account JSON
grep -rE "AIza[A-Za-z0-9_-]{35}" .
grep -rln '"type": "service_account"' . --include="*.json"

# Slack
grep -rE "xox[baprs]-[A-Za-z0-9-]+" .

# OpenAI / Anthropic
grep -rE "sk-[A-Za-z0-9]{32,}" .
grep -rE "sk-ant-[A-Za-z0-9_-]{90,}" .

# Generic high-entropy strings in env files
grep -rE "^[A-Z_]+=[A-Za-z0-9/+=]{32,}$" . --include="*.env*"

For full repo coverage, use `git ls-files` to scope to tracked files and avoid `node_modules`:

git ls-files | xargs grep -lE 'sk_live_|ghp_|AKIA[A-Z0-9]{16}|sk-ant-|AIza[A-Za-z0-9_-]{35}' 2>/dev/null

Tooling

| Tool | Use | |---|---| | `gitleaks detect` | Fast, low FP, run as pre-commit and in CI; supports custom rules | | `trufflehog git file://.` | Verifies findings against the real API (high confidence) | | `detect-secrets scan` | Yelp's tool; good baseline file workflow | | GitHub Secret Scanning | Free for public repos; covers most providers automatically; pushes get blocked at push time when enabled with push protection | | GitLab Secret Detection | Similar, built-in to CI | | GitGuardian / Doppler / Spectral | Commercial; add organizational dashboards and historical analysis |

Git history (the part people forget)

A secret deleted in the latest commit is still in history — `git log -p`, `git log -S<secret>`, and any fork or local clone all have it.

# Search every commit for a pattern
git log -p -S "sk_live_" --all

# Search only deleted lines
git log -p --all | grep -E "^-.*sk_live_"

# Trufflehog historical scan
trufflehog git file://. --since-commit=<first-commit>

# Git history rewrite — destructive, coordinate first
git filter-repo --invert-paths --path config/secrets.yml
# or
bfg --delete-files secrets.yml

**Critical caveat:** rewriting history requires every developer to re-clone, every fork is still exposed, and the secret should be considered compromised regardless. Always rotate first, history-rewrite second.

Build artifacts and other forgotten places

Secrets leak in places that aren't `.env` files:

• **Docker images** — `docker history <image>` shows every `ENV` line; `--build-arg SECRET=...` ends up in layers
• **CI environment** — secrets logged by `set -x`, `console.log(process.env)`, error stack traces, debug output
• **Frontend bundles** — `NEXT_PUBLIC_*` / `VITE_*` / `REACT_APP_*` env vars are shipped to the browser; grep the bundled JS
• **Crash reports** — Sentry / Datadog / Bugsnag capturing `process.env` snapshots
• **Logs** — application logs shipped to a SIEM that has weaker access controls than the app
• **Backups** — `pg_dump` of a table that includes user-stored API keys
• **Public S3 / blob storage** — `.env` accidentally uploaded
• **Documentation** — README.md examples with real keys instead of placeholders
• **Slack / Notion / Linear** — pasted in a DM "to test," never rotated
• **Browser localStorage / cookies** — captured in shared screenshots or session replays

Triaging a found secret

When you find a leaked secret:

1. **Verify it's live** — use the provider's verification (`aws sts get-caller-identity`, `stripe balance retrieve`, `curl -H "Authorization: Bearer $TOKEN" ...`) — don't assume; some leaked keys are already revoked or were sandbox-only 2. **Determine exposure window** — first commit it appeared in, when the repo went public, when CI logs were retained from 3. **Determine blast radius** — what does this key access? What can be done with it? IAM permissions, Stripe live vs test, GitHub `repo` vs `admin:org` 4. **Rotate immediately** — generate a new key, deploy it, then revoke the old one (revoke-first breaks prod) 5. **Audit for use** — provider audit logs (CloudTrail, GitHub audit log, Stripe events) for any activity from the leaked credential 6. **Then clean** — remove from current code, then optionally history-rewrite (low priority once rotated) 7. **Document** — incident report, even if rotation was clean; recurrence patterns surface trends

Part 2 — Audit secrets-management posture

The hierarchy of secret stora