Secrets Management Audit

A secret's lifetime of exposure, not its strength, determines the breach. A perfectly random key committed to git is worthless. Audit the full lifecycle: creation, storage, distribution, use, rotation, and revocation.

Find where secrets live (and where they leak)

1. At rest: source code, config files, environment variables, container images/layers, IaC templates, CI/CD variables, and backups. Each is a place a secret gets copied and forgotten.
2. In transit: how does a secret get to the service that needs it? Hardcoded, baked into the image, injected at runtime from a vault? Every hop is an exposure point.
3. In flight / in use: secrets in process memory, in logs, in error messages, in URLs (query strings get logged everywhere), in client-side code (anything shipped to the browser is public).

The lifecycle controls

• Generation: high-entropy, generated by the secret manager, never human-chosen for service credentials.
• Storage: a dedicated secrets manager/vault with access control and audit logging — not env files checked into repos, not plaintext config.
• Distribution: injected at runtime via short-lived credentials or workload identity, not baked into artifacts.
• Rotation: routine and automated; the system must tolerate rotation without downtime. A secret that can't be rotated easily won't be after a leak.
• Revocation: a leaked secret must be killable immediately. Long-lived static keys with no revocation path are the worst case.

Adversarial validation

• Git history: secrets are often removed from HEAD but live forever in history (and in every clone/fork). Removing from the latest commit is not remediation — the secret is compromised and must be rotated.
• The blast radius of one leak: if this single credential leaks, what does it unlock? Over-scoped, shared, and long-lived secrets turn one leak into total compromise. Prefer least-privilege, per-service, short-lived.
• Logs and telemetry: search logs/APM/error trackers for tokens, passwords, and auth headers — they leak into observability constantly.
• Client-side exposure: any secret in a mobile app, SPA bundle, or browser is already public; treat API keys shipped to clients as identifiers, not secrets.
• CI/CD: build logs, PR-triggered workflows from forks, and over-broad pipeline tokens are a top leak vector.

Non-obvious risks

• Encryption keys protecting secrets are themselves secrets — the chain bottoms out at a root of trust (HSM/KMS); a key encrypting keys stored next to them protects nothing.
• Rotation without revoking the old value just adds a valid credential; old must be invalidated.
• "It's only internal" secrets become external the moment one internal component is breached.

Output structure

Deliver: the inventory of where each secret class lives at rest/in transit/in use, the lifecycle gaps (generation, storage, rotation, revocation), the git-history and log/telemetry leak check, the blast radius per secret with least-privilege/short-lived recommendations, and an ordered remediation list (rotate-now items first).