Secrets Management

Updated September 30, 20262 min read

In short

Secrets management is the practice of securely storing, distributing, rotating, and auditing sensitive credentials such as passwords, API keys, and tokens.

What is secrets management?

A secret is any value that grants access to something: a database password, an API key, a private encryption key, or an OAuth client secret. Secrets management is the set of tools and habits that keep those values out of source code, limit who and what can read them, and make them easy to change. Its goal is simple: a leaked repository, log file, or laptop should not hand an attacker the keys to production.

In a typical setup, secrets live in a dedicated secrets manager, sometimes called a vault, that encrypts them at rest and controls access with authentication and fine-grained policies. Applications fetch secrets at startup or runtime using their own workload identity, or receive them as environment variables or mounted files injected by the deployment platform. Good systems also log every access, rotate secrets on a schedule, and can issue short-lived dynamic credentials that expire automatically, so a stolen value is useful for only minutes or hours.

Think of a hotel key-card system rather than a spare key under the doormat. Cards are issued only to registered guests, work only for their room and stay, can be canceled instantly, and every door records who opened it. Secrets management brings the same control to credentials used by apps, CI/CD pipelines, and infrastructure-as-code tools.

A common confusion is between secrets and ordinary configuration. Settings like a log level or feature flag are harmless if exposed, while a secret is dangerous if leaked, so it needs encryption, access control, and rotation. Environment variables are a delivery mechanism, not secure storage by themselves: a .env file committed to Git, or a variable printed in a crash log, is still a leak.

Key takeaways

Secrets include passwords, API keys, tokens, certificates, and private keys.
Never hard-code secrets or commit them to version control.
Store secrets in an encrypted secrets manager with access policies and audit logs.
Rotate secrets regularly and prefer short-lived, automatically expiring credentials.
Use secret scanning to catch leaks in commits and CI logs early.

Example

Reading a secret at runtime instead of hard-coding ittypescript

// Bad: the secret is in source code and stays in Git history forever
// const dbPassword = "s3cr3t-p@ssw0rd";

// Good: the platform or secrets manager injects the value at runtime
const dbPassword = process.env.DB_PASSWORD;

if (!dbPassword) {
  // Fail fast, and never log the secret's value
  throw new Error("DB_PASSWORD is not set");
}

Readers ask

What should I do if I accidentally committed a secret to Git?

Treat it as compromised: revoke or rotate it immediately, then remove it from the code. Deleting the file in a new commit is not enough, because the value stays in Git history and may already have been copied by automated scanners.

Are environment variables secure enough for secrets?

They are a common and reasonable way to deliver secrets to an app, but they are not a storage system. The values should come from a secrets manager or the platform's secret store, and you should avoid printing them in logs or passing them to processes that don't need them.

What is secret rotation?

Secret rotation means replacing a secret with a new value on a schedule or after a suspected leak, then retiring the old one. Automated rotation and short-lived credentials limit how long a stolen secret remains useful.