The Problem
Applications need secrets: database passwords, API keys, signing keys. The common failure is putting them where they should never live, hardcoded in source, committed to a repository, or printed in logs. Once a secret reaches version history, it is effectively public to anyone with access and hard to fully erase.
Where Secrets Should Live
- A dedicated secrets manager or vault that stores secrets encrypted and serves them at runtime over an authenticated channel.
- For simpler setups, environment variables injected at deploy time, never checked into the repository.
- Reference secrets by name in config; resolve the value only at startup.
Operating Practices
- Make secrets rotatable so a leak can be contained by replacing the value quickly.
- Grant each service least privilege access to only the secrets it needs.
- Keep secrets out of logs, error messages, and crash dumps.
- Scan commits to catch leaked secrets before they merge.
Key idea
Secrets belong in a managed store or injected environment, never in source or logs, and good practice means scoping access tightly, scanning for leaks, and rotating values so a compromise can be contained quickly.