What is Secrets Management?

What counts as a secret

Anything whose exposure would let someone impersonate the system or read data they should not. The Stripe live key. The Postgres connection string. The signing key for your JWTs. The AWS access key for the deploy role. The SSH private key for the bastion host. The OAuth client secret for the SaaS integration. The TLS private key for the certificate. The webhook signing secret. Each of these is a credential whose leak is a security incident, and the discipline of secrets management is treating every one of them with the seriousness that implies.

Why a .env file is not enough

Local development with .env files is fine. Production is not. A production system needs four things that .env files do not provide. Storage that is encrypted at rest and accessible only to authenticated workloads. Distribution that gets the secret into the running process without a human ever seeing it. Rotation that can change the value across every consumer without a coordinated deploy. Auditing that records every access so a forensics team can answer "who saw what, when." A secrets manager is the system that does all four.

The vendor landscape

Cloud-native: AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. These integrate tightly with the cloud's own IAM and are the right default for workloads inside that cloud. Self-hosted: HashiCorp Vault is the dominant choice and supports a much richer set of features (dynamic secrets, PKI as a service, encryption-as-a-service) at the cost of operational complexity. Cross-cloud / developer-friendly: Doppler, Infisical, 1Password Secrets Automation, and Akeyless target teams that want a polished UX and multi-cloud support. For most early-stage SaaS, the cloud-native option is sufficient; the case for a heavier solution grows with the team and the variety of clouds.

Where leaks come from

The same three places, every year. Secrets committed to git — usually in a private repo that later becomes public, or in a public repo when someone forgot the file was there. Secrets baked into container images uploaded to a registry, where the layer history preserves them even if the latest Dockerfile does not. Secrets pasted into chat or ticket systems and forgotten about. Tools like GitGuardian, TruffleHog, and GitHub's own secret scanning find tens of thousands of exposed credentials every day. The single highest-leverage habit is to make it impossible for secrets to reach git: pre-commit hooks, CI scanning, and a culture where the answer to "where is the API key" is always "in the secrets manager."

At QUANT LAB

Every cloud infrastructure build we deliver wires up a secrets manager on day one — AWS Secrets Manager or GCP Secret Manager for the workload secrets, with workload identity (IAM roles, service accounts) so that the running process can fetch its secrets without any long-lived credential of its own. Pre-commit hooks and CI checks scan every diff for accidentally-committed secrets.

For SaaS products we also rotate the secrets that face external vendors (Stripe, SendGrid, third-party integrations) on a schedule, and on every personnel change. Our pen-testing team regularly finds environments where one expired credential never got cleaned up; the cleanest fix is automation, not vigilance. Read our piece on Stripe webhook security for a specific case study, or book a call if your .env files have been accreting since 2020.