Secrets Management
A leaked credential is one of the fastest ways to get breached.
Passwords, API keys, tokens, certificates — secrets are the keys to your kingdom. A single one committed to a repository has caused countless real breaches. Managing secrets properly is one of the highest-impact security practices you can adopt.
🎯 Learning Objectives
By the end of this lesson you will:
- Understand why hard-coded secrets are so dangerous
- Scan for secrets before they’re committed
- Use a secrets manager / vault
- Apply rotation and least-privilege to secrets
The Danger of Hard-Coded Secrets
Putting a secret in code feels convenient. It’s a disaster:
⚠ Git never forgets
Committing a secret and then deleting it does NOT remove it — it stays in the Git history forever, readable by anyone with repo access. Once a secret hits a remote repo, treat it as compromised and rotate it immediately. Automated bots scan public GitHub for leaked keys within seconds.
# NEVER do this
const dbPassword = "SuperSecret123";
const apiKey = "sk_live_abc123...";
# Do this — read from the environment / a secret store
const dbPassword = process.env.DB_PASSWORD;Catch Secrets Before They’re Committed
Prevention beats cleanup. Two layers:
1. Pre-commit hooks stop a secret from ever being committed:
# Using gitleaks as a pre-commit hook
gitleaks protect --staged --verbose2. CI scanning catches anything that slips through:
💡 Defence in depth
Run secret scanning both locally (pre-commit) and in CI. The pre-commit hook is your first line; the CI scan is the safety net for developers who bypass or lack the hook.
Secrets Managers / Vaults
Instead of scattering secrets in env files, store them in a dedicated secrets manager that provides encryption, access control, and auditing:
| Tool | Where it lives |
|---|---|
| HashiCorp Vault | Self-hosted, cloud-agnostic |
| AWS Secrets Manager | AWS |
| Azure Key Vault | Azure |
| GCP Secret Manager | Google Cloud |
Apps fetch secrets at runtime, authenticated by their identity:
# App requests a secret at startup, using its own identity
vault kv get -field=password secret/prod/db
# It's never stored on disk — fetched into memory when neededBenefits over env files: central control, encryption at rest, audit logs of who accessed what, and easy rotation.
Rotation and Least Privilege
Two principles limit the damage if a secret does leak:
- Rotation — change secrets regularly and automatically. A leaked secret that’s already been rotated is worthless. Short-lived, dynamically generated credentials are the gold standard.
- Least privilege — each secret grants the minimum access needed. A read-only database credential can’t be used to delete data even if stolen.
💡 Scope every credential tightly
Never use one all-powerful admin key everywhere. Give each service its own narrowly scoped credential. If one leaks, the blast radius is small and contained.
🧪 Hands-on Lab
Design a Secrets Strategy
- Add a secret-scanning step (gitleaks) to a pre-commit hook and to CI
- Move a hard-coded credential into an environment variable sourced from a vault
- Define a rotation policy and least-privilege scope for a database credential
🧠 Knowledge Check
You accidentally committed an API key and pushed it. What should you do?
What is the main advantage of a secrets manager over storing secrets in .env files?
💼 Interview Preparation
How do you manage secrets securely across the development lifecycle?
Summary
You now know why hard-coded secrets are so dangerous, how to scan for them, how vaults centralise and protect them, and how rotation plus least privilege limit the damage of a leak. Next, we secure the containers you ship.