Secrets Management Review

---
name: secrets-management-review
description: >-
  Review how secrets are handled across code, IaC, CI/CD, containers, and config —
  hardcoding, sprawl, exposure, vaulting, rotation, and access scope. Use to assess
  secrets hygiene for a project or environment and find exposed credentials.
---

# Goal

An assessment of secrets handling: where secrets are exposed or poorly managed, and
a path to centralized, least-privilege, rotated secrets.

# What to review

1. **Hardcoded secrets** — passwords/API keys/tokens/private keys in source, IaC
   variables/state, container images, config files, or scripts. (Scan history too:
   git history, image layers.)
2. **Exposure surface** — secrets in environment variables, build logs, CI/CD
   variables, error messages, or client-side code; secrets in plaintext at rest.
3. **Storage** — is a secrets manager/vault used (HashiCorp Vault, cloud secret
   managers, k8s external secrets)? Or are secrets scattered ("sprawl")?
4. **Gitignore hygiene** — confirm sensitive paths are actually excluded, not just
   assumed: `.env`/`.env.*`, `*.pem`/`*.key`/`*.p12`/`*.pfx`, `id_rsa*`,
   `credentials.json`, `*kubeconfig*`, `terraform.tfstate*`/`.terraform/`, vendored
   cloud-CLI creds (`.aws/credentials`, `.azure/`, `.gcloud/`), and tool local-state
   dirs that can carry secrets/session data (`.claude/`, `.vscode/` settings with
   tokens, `.idea/`). Check both directions: pattern present in `.gitignore` **and**
   the inverse via `git ls-files` — a file already tracked stays tracked even after
   it's added to `.gitignore`, so gitignoring it later doesn't remove it from
   history. Flag high-severity any sensitive path that's untracked-but-not-ignored
   (next `git add .`/`-A` will commit it) or tracked-and-should-be-untracked.
5. **Access & scope** — who/what can read each secret; least privilege; per-service
   scoping vs. shared god-secrets.
6. **Rotation & lifecycle** — rotation policy, expiry, revocation on compromise,
   detection of leaked secrets.

# Steps

1. Scope the surfaces (repos, IaC, CI/CD, registries, runtime config). Run secret
   scanners where possible (gitleaks, trufflehog, detect-secrets) and review results.
   Check `.gitignore` coverage and `git ls-files` for sensitive paths as above.
2. For each finding: classify (hardcoded / exposed / unrotated / over-scoped),
   confirm it's a real secret, and assess blast radius.
3. Treat any live, committed secret as an incident: flag for **rotation/revocation**,
   not just removal (it's in history/layers).
4. Recommend: move to a vault, scope access, enable rotation, add pre-commit/CI
   secret scanning.

# Output

A findings table: location · secret type · issue · severity · action (rotate/
revoke/vault/scope/gitignore). Confirmed live secrets → `security-reporting:finding`
(rate high+; recommend rotation, not just deletion).

# Notes

Removing a committed secret does **not** make it safe — it lives in git history and
image layers, so it must be rotated/revoked. Centralize into a vault with
least-privilege access and rotation; add secret scanning to pre-commit and CI to
prevent recurrence. This skill is the manual/audit pass across any stack; for a
repo that wants this *enforced* automatically (blocked at commit/push, not just
reviewed on request), `secure-coding:secret-guard` installs the actual git hooks
(via `install-git-hooks.sh`) plus a Claude Code `PreToolUse` hook — point the
user at it when they want prevention, not just detection.