🔑 Secrets Scanner — Scanning for Exposed Credentials...

Scan a codebase for hardcoded secrets, leaked API keys, and credential exposure across files and git history.

Activation

When this skill activates, output:

🔑 Secrets Scanner — Scanning for Exposed Credentials...

Then execute the protocol below.

Context Guard

Protocol

Step 1: Scan for Hardcoded Secrets (Check 1)

Search all tracked files for strings matching known secret patterns:

API Key Patterns:

# Stripe
grep -rn "sk_live_[a-zA-Z0-9]\{20,\}\|sk_test_[a-zA-Z0-9]\{20,\}\|pk_live_[a-zA-Z0-9]\{20,\}" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.json" --include="*.md" --include="*.yaml" --include="*.yml" .

# Supabase
grep -rn "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9\." --include="*.ts" --include="*.tsx" --include="*.js" .

# AWS
grep -rn "AKIA[0-9A-Z]\{16\}" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.json" --include="*.env*" .

# GitHub tokens
grep -rn "ghp_[a-zA-Z0-9]\{36\}\|gho_[a-zA-Z0-9]\{36\}\|github_pat_[a-zA-Z0-9_]\{30,\}" .

# Slack tokens
grep -rn "xoxb-[0-9]\{10,\}\|xoxp-[0-9]\{10,\}\|xoxs-[0-9]\{10,\}" .

# Generic high-entropy strings assigned to obvious secret variables
grep -rn "api_key\s*=\s*['\"][a-zA-Z0-9]\{20,\}['\"]\|apiKey\s*[:=]\s*['\"][a-zA-Z0-9]\{20,\}['\"]" .

Authentication Patterns:

# Bearer tokens hardcoded
grep -rn "Bearer [a-zA-Z0-9_\-\.]\{20,\}" --include="*.ts" --include="*.tsx" --include="*.js" .

# Passwords in code
grep -rn "password\s*[:=]\s*['\"][^'\"]\{4,\}['\"]\|PASSWORD\s*=\s*['\"][^'\"]\{4,\}['\"]" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.json" .

Private Keys:

# RSA/EC/DSA/OpenSSH private keys
grep -rn "BEGIN.*PRIVATE KEY\|BEGIN RSA PRIVATE\|BEGIN EC PRIVATE\|BEGIN DSA PRIVATE\|BEGIN OPENSSH PRIVATE" \
  --include="*.ts" --include="*.tsx" --include="*.js" --include="*.json" --include="*.pem" --include="*.key" --include="*.yaml" --include="*.yml" --include="*.md" .

Flag as CRITICAL if found in any tracked file. Private keys should never be committed — use environment variables or secret managers.

Base64-Encoded Secrets:

# Look for base64-encoded strings assigned to secret-like variables
# These are often used to obfuscate secrets in source code
grep -rn "\(secret\|key\|token\|password\|credential\).*['\"][ ]*[A-Za-z0-9+/]\{40,\}=*['\"]" \
  --include="*.ts" --include="*.tsx" --include="*.js" --include="*.json" .

# Check for Buffer.from(... 'base64') with hardcoded strings
grep -rn "Buffer\.from(['\"][A-Za-z0-9+/]\{20,\}=*['\"].*base64\|atob(['\"][A-Za-z0-9+/]\{20,\}" \
  --include="*.ts" --include="*.tsx" --include="*.js" .

Flag as WARNING if a base64 string is assigned to a variable with

secret

key

token

password

Connection Strings:

# Database URLs with credentials
grep -rn "postgres://[^:]\+:[^@]\+@\|mysql://[^:]\+:[^@]\+@\|mongodb://[^:]\+:[^@]\+@\|redis://:[^@]\+@" .

# Supabase/Firebase URLs with keys inline
grep -rn "supabase\.co.*service_role\|firebaseio\.com.*AIza" --include="*.ts" --include="*.tsx" --include="*.js" .

Exclude false positives:

• Files in

  node_modules/

  ,

  .git/

  ,

  dist/

  ,

  .next/

• Test fixtures with obviously fake values (e.g.,

  sk_test_fake123

  )
• Environment variable references (

  process.env.STRIPE_SECRET_KEY

  is safe — the variable itself, not a value)
• Documentation showing example formats

Step 2: Audit .env File Security (Check 2)

Check if .env files are gitignored:

# Are .env files in .gitignore?
grep -n "\.env" .gitignore

# Are any .env files currently tracked?
git ls-files | grep -i "\.env"

# Were .env files ever committed?
git log --all --diff-filter=A --name-only --pretty=format: | grep -i "\.env" | sort -u

Flag as CRITICAL if:

• .env

  or

  .env.local

  is currently tracked by git

• .env

  was previously committed (secrets in git history even if now removed)

• .gitignore

  does not contain

  .env

  patterns

Check .env.example exists:

• Should contain all required env var names with placeholder values
• Should NOT contain real secrets (scan for patterns from Check 1)

Step 3: Scan Config and Documentation Files (Check 3)

Secrets often leak into files developers don't think about:

# Check CLAUDE.md, README, docs
grep -rn "sk_\|pk_\|AKIA\|ghp_\|password\s*[:=]" *.md docs/ CLAUDE.md README.md 2>/dev/null

# Check config files
grep -rn "sk_\|pk_\|AKIA\|secret\|password\|token" \
  --include="*.json" --include="*.yaml" --include="*.yml" --include="*.toml" \
  --exclude-dir=node_modules .

# Check CI/CD config files
grep -rn "sk_\|pk_\|AKIA\|password\|token" \
  .github/workflows/*.yml .gitlab-ci.yml Dockerfile docker-compose*.yml 2>/dev/null

Flag as CRITICAL if real secrets found in any committed documentation or config.

Step 3b: Scan Deployment Platform Configs (Check 3b)

Secrets can leak into platform-specific deployment configurations:

# Netlify config
grep -rn "password\|secret\|token\|api_key\|AKIA\|sk_\|pk_" \
  netlify.toml netlify.yml 2>/dev/null

# Vercel config
grep -rn "password\|secret\|token\|api_key\|AKIA\|sk_\|pk_" \
  vercel.json .vercel/project.json 2>/dev/null

# Railway config
grep -rn "password\|secret\|token\|api_key" \
  railway.json railway.toml 2>/dev/null

# Render config
grep -rn "password\|secret\|token\|api_key" \
  render.yaml 2>/dev/null

# Fly.io config
grep -rn "password\|secret\|token\|api_key" \
  fly.toml 2>/dev/null

Flag as CRITICAL if:

• Real secret values are hardcoded in any deployment config file

• netlify.toml

  [build.environment]

  section contains secret values (these are committed to git — use Netlify UI environment variables instead)

• vercel.json

  contains environment variable values (use

  vercel env

  CLI or Dashboard instead)

Flag as WARNING if:

• Deployment configs reference environment variable names without values (usually OK, but verify the names match what's configured in the platform)

Step 4: Check Environment Variable Usage (Check 4)

Verify env vars are validated at application startup:

Search for unvalidated env var usage:

# Direct process.env usage without validation
grep -rn "process\.env\.\(.*SECRET\|.*KEY\|.*TOKEN\|.*PASSWORD\|.*DATABASE_URL\)" \
  --include="*.ts" --include="*.tsx" --include="*.js" .

Flag as WARNING if:

• process.env.SECRET_NAME

  used directly without checking if defined
• No env validation library (e.g.,

  @t3-oss/env-nextjs

  ,

  envalid

  ,

  zod

  env schema)
• Missing env vars would cause runtime errors instead of startup errors

Correct pattern:

// Good — validated at startup
import { z } from 'zod';
const env = z.object({
  DATABASE_URL: z.string().url(),
  STRIPE_SECRET_KEY: z.string().startsWith('sk_'),
}).parse(process.env);

Step 5: Check Client-Side Secret Exposure (Check 5)

Server-only secrets must never reach the browser:

Search for secrets in client code:

# In React/Next.js, only NEXT_PUBLIC_ vars are safe for client
grep -rn "process\.env\." --include="*.tsx" --include="*.jsx" \
  src/app/ src/components/ src/pages/ app/ components/ pages/ 2>/dev/null \
  | grep -v "NEXT_PUBLIC_"

Flag as CRITICAL if:

• SUPABASE_SERVICE_ROLE_KEY

  referenced in client components

• STRIPE_SECRET_KEY

  (not

  STRIPE_PUBLISHABLE_KEY

  ) in client code

• DATABASE_URL

  in client code
• Any non-

  NEXT_PUBLIC_

  env var in files under

  app/

  ,

  components/

  ,

  pages/

  (client-rendered paths)

Flag as WARNING if:

• API keys passed as props from server to client components
• Secrets embedded in client-side API calls via headers

Step 6: Scan Git History (Check 6)

Previously committed secrets remain in git history even after removal:

# Search git history for known secret patterns
git log -p --all -S "sk_live" --oneline -- "*.ts" "*.tsx" "*.js" "*.json" "*.env" 2>/dev/null | head -20
git log -p --all -S "AKIA" --oneline 2>/dev/null | head -20
git log -p --all -S "ghp_" --oneline 2>/dev/null | head -20
git log -p --all -S "password" --oneline -- "*.env" "*.env.*" 2>/dev/null | head -20

Flag as CRITICAL if:

• Any real secret pattern found in git history
• .env files appear in historical commits

Remediation for exposed history:

1. Rotate the exposed credential immediately
2. Use

   git filter-branch

   or

   BFG Repo-Cleaner

   to purge from history
3. Force-push the cleaned history (coordinate with team)

Step 7: Check Docker/Container Files (Check 7)

# Secrets in Dockerfiles
grep -rn "ENV.*SECRET\|ENV.*KEY\|ENV.*PASSWORD\|ENV.*TOKEN\|ARG.*SECRET" \
  Dockerfile* docker-compose*.yml 2>/dev/null

# Secrets passed as build args
grep -rn "build-arg.*secret\|build-arg.*key\|build-arg.*password" \
  Dockerfile* .github/workflows/*.yml 2>/dev/null

Flag as CRITICAL if:

• Secrets hardcoded in Dockerfile ENV instructions
• Secrets in docker-compose.yml without using Docker secrets or env_file

Flag as WARNING if:

• Secrets passed as Docker build args (visible in image layers)

Step 8: Generate Report

🔑 Secrets Scanner Report
Project: <project-name>
Files scanned: <count>
Git history checked: <yes/no>

## Findings

| # | File | Line | Type | Pattern | Risk | Status |
|---|------|------|------|---------|------|--------|
| 1 | src/lib/stripe.ts | 14 | Stripe Secret Key | sk_live_... | 🔴 CRIT | Hardcoded |
| 2 | .env | — | Environment File | .env tracked | 🔴 CRIT | In git |
| 3 | docker-compose.yml | 23 | Database Password | password= | ⚠️ WARN | Inline |
| 4 | src/app/page.tsx | 8 | Server Env in Client | DATABASE_URL | 🔴 CRIT | Client-exposed |
| 5 | README.md | 45 | API Key Example | sk_test_... | ℹ️ INFO | Test key |

## Critical Issues
1. **Stripe secret key hardcoded** in `src/lib/stripe.ts:14`
   → Fix: Move to `.env.local` as `STRIPE_SECRET_KEY`, reference via `process.env.STRIPE_SECRET_KEY`
   → Then: Rotate the key in Stripe Dashboard immediately — it's been committed

2. **.env file tracked in git**
   → Fix: `git rm --cached .env && echo ".env" >> .gitignore && git commit`
   → Then: Rotate ALL credentials that were in the .env file

3. **DATABASE_URL in client component**
   → Fix: Move database access to server-side API route or Server Component

## Git History
- ⚠️ Found `sk_live_` pattern in commit `a1b2c3d` (2024-03-15)
  → Credential was removed but remains in history
  → Fix: Rotate the key, then clean history with BFG Repo-Cleaner

## Environment File Audit
- .gitignore: ✅ Contains .env patterns
- .env tracked: 🔴 Yes — remove immediately
- .env.example: ⚠️ Missing — create with placeholder values
- Env validation: ⚠️ No startup validation found

## Summary
- 🔴 Critical: <count>
- ⚠️ Warning: <count>
- ℹ️ Info: <count>
- Files with secrets: <count>
- Git history exposures: <count>

Step 9: Generate .env.example

If no

.env.example

# Extract all env var names from the codebase
grep -roh "process\.env\.[A-Z_]\+" --include="*.ts" --include="*.tsx" --include="*.js" . \
  | sort -u \
  | sed 's/process\.env\.//' \
  > /tmp/env_vars.txt

Generate

.env.example

# Database
DATABASE_URL=postgresql://user:password@localhost:5432/dbname

# Supabase
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

# Stripe
STRIPE_SECRET_KEY=sk_test_your-key
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your-key
STRIPE_WEBHOOK_SECRET=whsec_your-secret

Step 10: Pre-Rotation Checklist

Before rotating any exposed credential, verify:

1. Is the secret actively used in production? Check deployment environment variables (Vercel/Netlify/Railway dashboard) to see if the exposed value matches what's currently configured. If the production value is already different, the exposure is historical only — still rotate, but priority is lower.
2. What services depend on this secret? A Stripe key rotation affects webhook verification, payment processing, and customer portal links. Map all dependencies before rotating.
3. Can you rotate without downtime? Some services (Stripe, AWS) support rolling two active keys simultaneously. Others (single JWT secret) require coordinated deployment.
4. Who else has access? If the repo is public or shared with contractors, assume the secret is fully compromised regardless of git history depth.

Rotation priority:

Step 11: Provide Recommendations

Always conclude with:

1. Rotate any exposed credentials immediately — assume they've been compromised (see pre-rotation checklist above)
2. Add

   .env

   patterns to

   .gitignore

   before any new commits
3. Create

   .env.example

   with placeholder values for onboarding
4. Use env validation (

   @t3-oss/env-nextjs

   or Zod schema) to catch missing vars at startup
5. Store secrets in CI/CD environment variables (Vercel, GitHub Actions secrets), never in code
6. Use

   NEXT_PUBLIC_

   prefix only for values safe to expose to browsers
7. Clean git history if secrets were previously committed (

   BFG Repo-Cleaner

   )

Risk Levels

Secret Pattern Reference

sk_live_*

sk_test_*

sk_live_51J...

pk_live_*

pk_test_*

pk_live_51J...

whsec_*

whsec_abc...

AKIA*

AKIAIOSFODNN7EXAMPLE

ghp_*

ghp_xxxxxxxxxxxx

gho_*

gho_xxxxxxxxxxxx

github_pat_*

github_pat_11A...

xoxb-*

xoxb-123-456-abc

xoxp-*

xoxp-123-456-abc

SG.*

SG.xxxxxxxxxx

eyJhbGci*

eyJhbGciOiJIUzI1...

sk-*

sk-abc123...

Bearer *

Bearer eyJ...

-----BEGIN RSA PRIVATE KEY-----

-----BEGIN EC PRIVATE KEY-----

-----BEGIN OPENSSH PRIVATE KEY-----

c2VjcmV0X2tleQ==

Automated Hook Coverage

The MemStack Pro hook system provides automatic, production-grade secrets detection before every commit and push — no manual invocation required.

Pre-Commit Hook — Scans all staged files before any

git commit

Pre-Push Hook — Full working-tree scan before any

git push

.env

Coverage includes:

• Cloud provider credentials (AWS, GCP, Azure, DigitalOcean, Hetzner, etc.)
• Payment platform keys (Stripe, Square, Braintree, PayPal)
• SaaS API tokens (GitHub, GitLab, Slack, Discord, Twilio, SendGrid, Mailchimp, etc.)
• Database connection strings with embedded credentials
• Private keys (RSA, EC, DSA, OpenSSH, PGP)
• JWT tokens, Bearer tokens, OAuth secrets
• Base64-encoded and obfuscated credentials
• CI/CD tokens, container registry credentials
• Custom high-entropy string detection

Fallback behavior: If the production scanner is not installed, hooks silently fall back to the built-in 5-keyword regex scan (Step 1 patterns). Scanning is never skipped — only the depth of detection changes.

This manual skill remains available for deep audits — git history analysis, client-side exposure checks, env validation, Docker inspection, and remediation planning that go beyond what automated hooks cover.

Related Skills

• api-audit — Audit API routes for auth/authz vulnerabilities
• rls-checker — Audit Supabase RLS policies
• dependency-audit — Check for vulnerable npm packages

Level History

• Lv.1 — Base: 7-check scan (hardcoded secrets, .env audit, config/docs, env validation, client exposure, git history, Docker), pattern reference for 14+ secret formats, .env.example generation, remediation guide. Derived from real credential incidents across AdminStack, EpsteinScan, and 10+ production projects. (Origin: MemStack Pro v1.0, Mar 2026)
• Lv.2 — Audit feedback: Added deployment platform config scan (Netlify, Vercel, Railway, Render, Fly.io), base64-encoded secret detection, private key block detection (RSA/EC/DSA/OpenSSH PEM), pre-rotation checklist with dependency mapping and priority matrix. (Origin: AdminStack audit, Mar 2026)
• Lv.3 — Hook integration: Documented automated pre-commit and pre-push hook coverage (700+ credential formats), fallback behavior, and relationship between manual skill audits and automated hook scanning. (Origin: MemStack Pro v3.3.3, Mar 2026)

Pro Feature

Pro: Secrets scanning hooks run automatically before every commit and push, covering 700+ credential formats across every major cloud provider and API service. Free version requires manual scanning only.