Secrets management

Leaked secrets (API keys, passwords, tokens, certificates) are one of the most common breach causes. Secrets management aims for them to never be in the code or the repo, to be stored encrypted, rotated, and audited.

The problem

- secrets hardcoded in code, configs, or accidentally committed to the repo
- a public repo (or a leaked one) with a key = immediate compromise (bots scan GitHub in minutes)
- secrets in environment variables, logs, container images, git history

Secret scanning

gitleaks / trufflehog   scan the repo and git HISTORY (a deleted secret is still in the log)
pre-commit hooks        block the commit BEFORE the secret gets in
GitHub secret scanning  detection + push protection (blocks the push with secrets)
# key: scan the HISTORY -> `git rm` isn't enough, the secret stays in old commits

What to do if a secret leaks

1. ROTATE the secret NOW (invalidate the compromised one) -> deleting it from the repo is NOT enough
2. revoke/regenerate the credential at the provider
3. review accesses with that credential (was it used?)
4. clean the history (git filter-repo/BFG) ONLY after rotating, and communicate the rewrite
# assume any secret that touched a public repo is compromised

Secrets managers (correct storage)

HashiCorp Vault           central vault, dynamic secrets, rotation, auditing
Cloud: AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
Kubernetes: Secrets (base64 != encrypted) + sealed-secrets / external-secrets / CSI driver
-> the app requests the secret at runtime; it doesn't live in the code or the image

Best practices

- secrets out of code: runtime injection (env/volume) from the manager
- automatic rotation and short-lived (dynamic) secrets where possible
- least privilege per secret; access auditing
- NEVER in logs, container images, or git history

Blue Team / AppSec

Secret scanning in pre-commit + CI + push protection; scan the history, not just HEAD.
Centralize in a manager (Vault/cloud KMS) with rotation and auditing; nothing hardcoded.
A rotate-immediately process on leak (rotate first, clean history after).
Prefer dynamic/short-lived secrets and least privilege per secret.

CVEs and real-world cases

Countless breaches from AWS keys committed to GitHub (crypto mining within minutes).
Uber (2016) and Toyota: credentials exposed in repos/code led to mass access.
Bots scanning GitHub in real time exploit leaked secrets within minutes of the push.

Testing checklist

Secret scanning in pre-commit + CI + push protection
Git HISTORY scanning (not just HEAD)
Centralized secrets manager (Vault/KMS), nothing hardcoded
Runtime injection (not in image/code)
Automatic rotation and short-lived secrets
Leak response process (rotate → clean history)
No secrets in logs or container images