Secrets Audit — Credential Exposure and Secrets-Management Review

dependency-audit

iam-audit

owasp-audit

Part 1 — Find leaked secrets

Provider key prefixes (high-confidence patterns)

# 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*"

git ls-files

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

gitleaks detect

trufflehog git file://.

detect-secrets scan

Git history (the part people forget)

git log -p

git log -S<secret>

# 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

Build artifacts and other forgotten places

.env

• 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

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 storage (worst → best)

.env

Cloud-provider secrets managers

• AWS Secrets Manager / Parameter Store (SecureString) — integrate via IAM-scoped IRSA / task role / Lambda role
• GCP Secret Manager — bind via Workload Identity to GSA, GSA pulls secret
• Azure Key Vault — pull via managed identity
• Doppler / Infisical / 1Password Secrets Automation — cross-cloud, developer-friendly

Audit checklist

• No secrets in Git history (run gitleaks --all)
• No

  .env

  committed —

  .gitignore

  covers

  .env*

  (with care for

  .env.example

  )
• Secrets fetched at runtime, not embedded at build — image rebuild is not required to rotate
• IAM scoped to the secret — service A can read secret A, not secret B
• Rotation cadence — defined per secret class (admin: 30d, service: 90d, customer-shared: per breach response)
• Rotation is automated — if a human runs a script every 90 days, rotation will eventually drift
• Access logged — every Get / Decrypt call is in an audit trail
• No long-lived cloud keys for workloads — workload identity federation everywhere it's supported (see

  iam-audit

  )
• Break-glass procedure — when the secrets manager is down, how do critical services come up? (Usually: cached on disk encrypted, with strict re-fetch on restart)
• Cross-environment isolation — staging cannot read prod secrets, ever (different KMS keys, different IAM)

Common findings

• Rotation never tested — secret stores configured, never actually rotated; first attempt breaks prod

• .env.local

  shipped to staging — environment-specific dev secrets cross the boundary
• CI secrets accessible from PRs from forks — GitHub's default behavior was previously dangerous; verify

  pull_request_target

  and secret accessibility
• Build args used for secrets —

  --build-arg AWS_SECRET=...

  ends up in image history (use

  --secret

  /BuildKit instead)
• Logging frameworks dump

  process.env

  on unhandled exception — Sentry / Datadog / Bugsnag scrub config required
• Secret stored in K8s as plain Secret without etcd encryption — base64 is encoding, not encryption (see

  container-audit

  )
• OAuth client secrets in mobile apps — public clients can't hold secrets; PKCE is the answer

Output Format

# Secrets Audit Report
## Scope: [repos / environments / managers covered]
## Date: [date]

### Live leaked secrets found
| Provider | Location | First seen (commit / date) | Verified live? | Rotation status |
|---|---|---|---|---|

### Secrets-management posture
| Category | Status | Notes |
|---|---|---|

### Recommendations
| Priority | Item | Owner | Deadline |
|---|---|---|---|

owasp-audit

Boundaries

• Only audit repositories, CI systems, and infrastructure the user has authorization for
• Never use a found secret to access the provider — verify it's live with a minimal API call (account info, not data extraction); do not pivot
• For history rewrite operations: never proceed without explicit confirmation and a coordinated developer-notification plan
• Refuse to help collect or weaponize leaked secrets found in other people's repos
• If the audit surfaces credentials belonging to a third party (vendor, employee personal accounts), notify and rotate; don't quietly fix

References

• OWASP Cheat Sheet: Secrets Management
• NIST SP 800-57 (Recommendation for Key Management)
• GitGuardian "State of Secrets Sprawl" annual reports — useful for industry context

• gitleaks

  ,

  trufflehog

  ,

  detect-secrets

  documentation
• GitHub Secret Scanning + Push Protection documentation
• HashiCorp Vault Architecture / Best Practices
• AWS Secrets Manager Best Practices
• "Twelve-Factor App" — Config principles