What is secrets management?
Secrets are the credentials your service needs but must never expose: database passwords, API keys, signing keys, tokens. Secrets management is how you supply them to the app at runtime without baking them into code or leaking them into logs and version control.
Why it matters
A leaked secret is a direct breach — a database password in a public repo can be exploited within minutes by automated scanners. Secrets also need to be rotated and scoped, not set once and forgotten. Handling them correctly is a basic expectation, and getting it wrong is a resume-defining incident.
What to learn
- Why secrets never belong in source control
- Environment variables and
.envfiles kept out of git - Secret managers: cloud vaults and dedicated tools
- Rotation and short-lived credentials
- Least privilege: scoping a secret to what it needs
- Keeping secrets out of logs and error messages
- Detecting committed secrets with scanning
Common pitfall
Committing a .env file or hardcoding a key "just for now." Once a secret hits
git history it is compromised even if you delete it later, because the history
remains. Add .env to .gitignore from the first commit, and if a secret ever
leaks, rotate it immediately rather than just removing the line.
Resources
Primary (free):
- OWASP — Secrets management cheat sheet · docs
- 12-Factor — Config · docs
- GitHub — About secret scanning · docs
Practice
Move every hardcoded credential in a project into environment variables, add
.env to .gitignore, and provide a committed .env.example with blank
values. Confirm the app reads config from the environment and that no real
secret is tracked by git. Done when git log contains no secret, ever.
Outcomes
- Keep secrets out of source control from the first commit.
- Supply config through environment variables or a secret manager.
- Rotate a leaked credential instead of just deleting the line.
- Scope each secret to the least privilege it needs.