Secrets Management — Don't Commit Production

• Never in source. Not in config files, not in .env.example, not in tests. Once it lands in Git history it must be considered leaked forever.
• Never in client code. Anything shipped to a browser or app is public.
• Never in logs. Scrub at the logging layer; don't rely on developers remembering.
• Least privilege per identity. The CI deploy role doesn't need read access to user data.
• Short-lived over long-lived. An hour-long token is far less dangerous than one with no expiry.
• Rotate on a schedule and on incidents. If you can't rotate quickly, you can't respond to a leak.
• Auditable access. Who read what secret, when. You need this after an incident.
• Encrypt at rest and in transit. Default behavior of vetted tools — don't roll your own.

Default for small teams: your cloud's secret manager. Default for a self-hosted stack: Vault.

• Environment variables at process start — simple, 12-factor, works everywhere. Watch for: env leaking via crash dumps, child processes, error pages.
• Mounted files (Kubernetes-style) — secret rotates, file updates; app re-reads on a SIGHUP or watch. Less leaky than env.
• Vault SDK at runtime — the app fetches secrets directly using a workload identity. Most flexible; supports leases and dynamic secrets.
• Sidecar / agent — Vault Agent or Secrets Store CSI Driver renews and rotates without the app caring.

Whichever method, the principle is the same: the secret enters the process at runtime, not at build time. Never bake a secret into a container image.

The single biggest improvement in secrets hygiene over the last few years: workload identity federation. Instead of giving CI a static AWS access key, the CI provider issues a short-lived OIDC token that the cloud trades for a temporary role.

• GitHub Actions → AWS / GCP / Azure via OIDC: no long-lived keys, automatic per-job credentials, scoped to specific repos/branches.
• Kubernetes Service Accounts map to cloud IAM via IRSA (AWS), Workload Identity (GCP), or Pod Identity (Azure).
• Effect: a leaked CI log is no longer a leaked production credential.

If you still have static cloud keys in CI in 2026, that's the highest-impact thing to fix this quarter.

• Pre-commit hooks: gitleaks, detect-secrets, trufflehog. Stop the commit at the developer's machine.
• Pre-push / CI scan: same tools, run server-side. Catches what hooks missed.
• GitHub / GitLab secret scanning: built-in for many platforms. Free real-time monitoring on the entire history.
• Provider notifications: AWS, Stripe, Slack, GitHub all monitor leaked-token feeds and notify (or auto-revoke). Don't disable these.
• Canary tokens: deliberately plant a fake AWS key in source — if it's used, you know exactly when and from where.
• SBOM & image scanning for secrets baked into containers (it happens more than you'd think).

1. Revoke the secret immediately. Don't try to "rewrite Git history" first — by the time you've thought of it, the secret is on a hundred forks.
2. Rotate the underlying credential. New key, new token, new password. Update the vault.
3. Invalidate sessions / tokens that used it. Force re-auth where it matters.
4. Audit access logs for use between leak and revocation. This is where short-lived credentials and good logging save you.
5. Postmortem. How did it land in source? Add a control that prevents a repeat.

Rotation isn't only for incidents — schedule it. If your secret hasn't been rotated in years, the only honest thing to assume is that it's been leaked at some point.

Notice: nothing in source, nothing baked in the image, the highest-blast-radius secret (DB) is dynamic and short-lived, and the JWT key never leaves Vault — the app asks Vault to sign on its behalf.