Secret Management: Are You Doing It All Wrong?

May 18, 2025

If you're storing API keys in plain text, leaving secrets in your source code, or relying on a homegrown vault solution - this one's for you.

What Is a "Secret" Anyway?

Before we talk about what you're doing wrong, let's align on what we mean by a "secret."

Secrets include:

  • API keys
  • OAuth tokens
  • Database credentials
  • SSH keys
  • Encryption keys
  • TLS certificates

But there are also less obvious secrets like internal service URLs, private feature flags, or tokens inside cookies. Basically, anything that can grant access or trust in your system is a secret.

The real kicker? Even a small team can accumulate dozens of secrets quickly.


The Mistakes You're Probably Making

Storing Secrets in Your Code

Let's start with the cardinal sin: committing secrets into your codebase.

I've seen this happen in startups, Fortune 500s, and everywhere in between. A developer wants to test a new API, so they drop the key right into the config file and forget about it. Then they commit it. Then it gets merged.

Even if you delete the file, it's still in your Git history. And yes, attackers scan public repos constantly.

Environment Variables Aren't Magic

Environment variables are a step in the right direction - but they aren't foolproof.

Storing secrets in .env files that get committed or poorly permissioned is just another way to leak them. Worse, in Docker and Kubernetes environments, these variables can persist across containers or be exposed via debugging tools.

Over-permissive Access

Let's say you store your secrets in a proper secret manager - awesome! But are your IAM policies giving the entire engineering team full access to everything?

Principle of least privilege isn't just a buzzword. The more access people or services have, the bigger your blast radius.

Building Your Own Solution

Some teams roll their own secret vault using encrypted YAML files, database blobs, or even spreadsheets (yikes). I get it - it feels faster at first.

But when secrets don't auto-rotate, audit logs don't exist, and keys get shared on Slack and Teams, things fall apart.


What Good Secret Management Looks Like

Use a Real Secret Store

This is your first step. Look into tools like:

  • AWS Secrets Manager
  • HashiCorp Vault
  • Azure Key Vault
  • GCP Secret Manager
  • Doppler

These tools provide secure storage, access controls, automatic rotation, and auditing.

Encrypt Everything

Use TLS in transit, encrypt at rest, and lean on Key Management Services (KMS) to keep things simple and secure. Envelope encryption is your friend here.

Access Control and Audit Logs

Use role-based access control (RBAC) to tightly scope who or what can access which secrets. Also, ensure every access is logged and that logs are immutable.

I've been on a post-incident review where we couldn't prove who accessed what - I cannot stress enough how important audit logs are.

Rotate Secrets Regularly

If your secrets last forever, you're inviting disaster. Many secret managers allow automatic rotation and notification hooks so your app can refresh them on the fly.


CI/CD and Secret Hygiene

Inject Secrets at Runtime

Use your pipeline to inject secrets just-in-time. Tools like GitHub Actions, GitLab CI/CD, and CircleCI all support secrets that are not stored in your repo.

Avoid baking secrets into Docker images or AMIs. Once they're in, they're hard to remove - and easy to steal.

Scan for Secrets

Run scanners like TruffleHog, Gitleaks, or GitGuardian during PRs. It's like having a secret-detection alarm in your CI/CD.

Rebuild After Rotation

When a secret rotates, it should trigger a new build or deploy. Treat secrets like config: they change more often than you think.


Tools and Patterns to Know

If you're using Kubernetes:

  • External Secrets Operator can sync secrets from your vault to your pods.
  • Sealed Secrets lets you encrypt secrets into Git and decrypt them only in your cluster.

For cloud environments:

  • Prefer cloud-native secret managers for tight integration and auto-rotation.
  • Avoid multi-purpose secrets (e.g., one key used for three services).

You might think your secret management setup is fine - but if you're not using a centralized store, enforcing RBAC, rotating secrets regularly, and scanning your repos, there's a good chance you're doing it wrong.

The good news? It's never been easier to get this right. The tools are mature, the patterns are proven, and the stakes are too high to ignore.

If you only take one thing away from this: Make secret hygiene a habit, not an afterthought.

Your cloud bill - and your future self - will thank you.

Johnathan Miller