The Keys to the Kingdom

Application secrets—API keys, database passwords, encryption keys, tokens, certificates—are the credentials that grant access to everything your systems protect. Secrets management is the practice of storing, distributing, rotating, and auditing them so that a leak is contained rather than catastrophic.

The Secret Sprawl Problem

Secrets multiply. A typical application has database credentials, cache passwords, third-party API keys, signing keys, SMTP credentials, and cloud access keys—each in development, staging, and production. Without discipline they end up in .env files, CI variables, shell history, container images, wiki pages, and Slack messages. The attack surface grows far faster than the team's awareness of it.

Store Secrets in a Dedicated System

The foundation is a secrets manager: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or Kubernetes Secrets with an external provider. These systems provide:

  • Encryption at rest and access control.
  • Audit logging of every read.
  • Dynamic secrets: the manager generates short-lived database credentials on demand, so credentials have no long life to steal.
  • Leasing and revocation: access expires automatically.

Applications should fetch secrets at runtime from the manager, not load them from files committed to disk. Inject them into the process environment or, better, hand them over through an authenticated API call that is itself audited.

Never Hardcode

The cardinal rule: no secret in source code, ever. Git history is forever, and a key committed even briefly is compromised. Use pre-commit hooks and secret-scanning tools (gitleaks, trufflehog, GitHub secret scanning) to catch leaks before they land. If a secret does reach a repository, treat it as exposed immediately—rotate it, do not just delete the commit. Deleting history does not un-leak a key that may already have been scraped.

Rotation

Secrets should expire. Rotation replaces a credential on a schedule or on demand:

  • Prefer short-lived credentials (minutes to hours) over long-lived ones.
  • Rotate keys automatically where the provider supports it, with overlapping validity so deployments do not break.
  • Design for rotation from the start; retrofitting rotation into a system that assumes static credentials is painful.

Automation is essential—manual rotation does not happen under pressure, and undocumented keys are never rotated at all.

Least Privilege and Scoping

Each secret should grant the minimum access needed and be scoped to one service or environment. A key that can read one bucket is far safer than a key that can administer the entire cloud account. Separate credentials per environment prevent a staging compromise from touching production.

CI/CD and Build Systems

Pipelines are a frequent leak point. Do not print secrets in build logs, do not pass them to untrusted pull-request builds, and use short-lived, environment-scoped credentials injected by the CI platform's own secret store. Mask secrets in logs, and review pipeline definitions for accidental exposure.

Detection and Response

Assume leaks will happen. Monitor for:

  • Secrets in public repositories (automated scanning).
  • Unusual API calls using known keys.
  • Keys used from unexpected IPs or regions.
  • Old keys still active long after they should have rotated.

When a leak is confirmed, rotate first, then investigate. Fast rotation limits the damage window, and the audit logs from your secrets manager tell you what was accessed.

Secrets management is unglamorous but foundational. The difference between a contained incident and a full breach is often whether the exposed credential had a short life and limited scope—or was a decade-old admin key sitting in a repository.