Secrets management

Secrets are credentials that grant access: API keys, database passwords, signing keys, OAuth client secrets, webhook secrets. If it could let an attacker do something you don't want them to do, it's a secret.

The hierarchy of secret storage, worst to best.

1. Hardcoded in source. Catastrophic. Git history is forever.
2. .env file committed to git. Same problem.
3. .env file in .gitignore. Better, but the file still exists on every dev's machine, ends up in Docker images, leaks via CI logs.
4. Environment variables set by deploy process. Standard. Visible in /proc/<pid>/environ, in crash dumps, in subprocess inheritance.
5. Secret manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault). Pulled at runtime. Audited. Rotatable. The right answer for production.
6. Hardware Security Module (HSM) for the most sensitive keys (signing keys, root CA). Key never leaves the device.

The four practices that actually matter.

• Pull secrets at runtime from a manager. App authenticates via cloud IAM (no static credentials needed), fetches secrets, caches in memory.
• Rotate regularly. DB passwords every 90 days, signing keys yearly, OAuth client secrets when team changes. Automated rotation > manual rotation > no rotation.
• Audit access. Every secret read is logged. Alert on anomalous patterns (3am access, new IP, new principal).
• Scope by environment. Dev and prod secrets are completely separate, with separate IAM. Devs cannot read prod secrets, even by accident.

For local development.

• direnv or .envrc with .env files (gitignored). Fine for dev.
• 1Password CLI or Doppler for the secrets that match prod (Stripe test keys, etc).
• Never the production secrets on dev machines.

When a secret leaks, the only safe response is rotation. Auditing what was accessed during the leak window is second priority. Hoping it wasn't used is not a strategy.