Stop Putting Secrets in .env Files: A Practical Vault Primer

Nearly every breach post-mortem contains the same sentence: 'the attacker found credentials.' In a .env file, in a repo, in a CI log, in a Slack message. Secrets sprawl is not a tooling failure — it is the default outcome of not deciding where secrets live.

The minimum discipline

One: secrets live in exactly one place — an encrypted store (the Vault AI service exists for precisely this), never in code, never in tickets. Two: applications receive secrets at runtime, injected into the environment or fetched over an authenticated channel, so a copy of the codebase is worthless. Three: every secret has an owner and a rotation date; a credential nobody remembers issuing is a credential nobody will remember revoking.

Encryption at rest is table stakes

A vault that stores secrets encrypted with a key kept next to the ciphertext is a filing cabinet with the key taped to it. Use envelope encryption: data keys encrypt secrets, a master key encrypts data keys, and the master key lives somewhere with real access control.

Rotation without tears

Rotation fails when it requires coordination. Design for two valid versions of every secret during a rollover window: issue the new one, deploy consumers, revoke the old one. If your systems read secrets at startup only, a rolling restart completes the rotation with zero downtime.

None of this requires an enterprise contract. It requires deciding, once, that plaintext credentials are an incident — and giving them exactly one encrypted home.

Where secrets leak in real life

It is worth listing the usual leak points, because each one suggests a specific control. Source code repositories are the classic case: a key committed once remains in the history even after the file is changed. Continuous-integration logs are another, when a script prints its environment or a command echoes a token. Chat tools and tickets collect credentials pasted "just for a minute". Developer laptops hold copies of production configuration. Container images sometimes bake secrets into a layer that anyone who pulls the image can read. And backups of configuration files carry secrets into places with weaker access controls.

The common thread is copying. Every time a secret is copied to a new place, the number of people and systems that can expose it grows. A vault reduces copying by giving every consumer a way to fetch the secret when needed instead of keeping its own copy.

Choosing a secrets store

Several kinds of tools can play the role of the central store: dedicated secrets managers, the key-management and secrets services of cloud providers, encrypted stores built into deployment platforms and self-hosted vaults. The right choice depends on where your workloads run and what your team can operate, but the essential properties are the same. Secrets must be encrypted at rest, access must be granted per application and per person with the least privilege needed, every read and change must be logged, and secrets must be retrievable programmatically so that applications never need a human to hand them a copy.

Prefer a tool that your deployments can reach reliably. A sophisticated vault that applications cannot contact during an outage simply moves the failure elsewhere.

Envelope encryption, explained simply

Envelope encryption sounds complex but follows a simple idea. Each secret is encrypted with its own data key. The data keys are then encrypted with a master key, and only the encrypted data keys are stored next to the secrets. To read a secret, the system asks the master key holder to decrypt the data key, uses it in memory and discards it. The master key itself never leaves a protected boundary — a hardware security module, a cloud key service or a separate, tightly controlled host.

The benefit is twofold. Stealing the database of encrypted secrets is useless without access to the master key. And rotating the master key does not require re-encrypting every secret, only the data keys, which makes regular rotation practical.

Scanning and prevention

Prevention is cheaper than clean-up. Add secret scanning to the places where leaks begin: a pre-commit hook on developer machines, a check in the code-review pipeline and periodic scans of existing repositories and their history. Many code-hosting platforms offer built-in scanning that recognizes common key formats and can even alert the issuing provider. Configure CI systems to mask secrets in logs, and review build scripts for commands that print the environment.

When a scan finds something, treat it as an incident regardless of how briefly the secret was exposed. Revoke and replace the credential first, then clean up the history. Removing a key from a repository without revoking it leaves the key valid for anyone who already copied it.

Secrets in containers and CI

Containers and pipelines need special care because they are built and copied automatically. Never pass secrets as build arguments that end up in image layers, and never copy configuration files containing credentials into an image. Instead, inject secrets at runtime through the orchestrator's secret mechanism or fetch them from the vault when the container starts. In CI, prefer short-lived credentials obtained through identity federation over long-lived keys stored as pipeline variables, and scope each pipeline's access to what that pipeline needs.

When a secret leaks: a response plan

Prepare the steps before you need them. First, revoke or rotate the exposed credential immediately and confirm that the old value no longer works. Second, review the logs of the affected service for any use of the credential since the exposure began. Third, identify how the leak happened and close that path, whether it was a commit, a log or a shared message. Fourth, record what happened, how long the secret was exposed and what was done. A credential with a known owner and a documented rotation procedure can be replaced in minutes; an orphaned one can take days to untangle.

Access reviews and ownership

Secrets accumulate quietly. A quarterly review keeps them under control: list every secret, confirm its owner, check which applications and people can read it and remove access that is no longer needed. Secrets without an owner should be investigated and, if nobody claims them, rotated or retired. Tie access to roles rather than individuals where possible, so that people joining and leaving the team does not require editing dozens of permissions.

A starter plan for small teams

A small team can reach a solid baseline in a few steps. Choose one secrets store and announce that it is the only acceptable home for credentials. Move the most sensitive secrets first: production databases, payment providers, cloud administrator keys. Change applications to read secrets at startup from that store. Turn on secret scanning for repositories and CI. Give every secret an owner and a rotation date, and rotate anything that has ever lived in a repository or a chat. None of this requires a large budget — only the decision to stop copying credentials around.

Short-lived credentials beat long-lived ones

The safest secret is one that expires before anyone can misuse it. Wherever your platforms support it, replace static keys with credentials issued on demand for a short period: database passwords generated per application session, cloud access tokens obtained through workload identity, signed URLs that expire in minutes. Short-lived credentials make leaks far less damaging, because a stolen value stops working on its own, and they remove much of the burden of manual rotation. Static secrets will not disappear entirely, but each one replaced by a short-lived alternative is one less long-term risk to manage.

Developer experience matters

Secrets discipline fails when the secure path is slower than the insecure one. If developers must open a ticket and wait a day to obtain a test credential, they will copy production values into their laptops instead. Make the right way the easy way: provide a simple command or plugin that loads development secrets from the vault into a local session, separate development and production values clearly, and document the process in one short page. People follow good practice readily when it saves them time.

A note on recovery keys and break-glass access

Every secrets system needs a plan for the day it is unavailable or its administrators are locked out. Keep recovery material — master key backups, unseal keys, emergency administrator credentials — split between trusted people or stored in separate secure locations, and test the recovery procedure periodically. Break-glass accounts should be monitored closely, used only in genuine emergencies and rotated after every use.

The payoff

Teams that adopt this discipline notice the benefits quickly. Onboarding becomes faster because new members request access instead of collecting files. Offboarding becomes safer because access can be revoked in one place. And when a credential does leak — as eventually one will — the response is a calm, rehearsed rotation rather than a frantic search through repositories, laptops and chat histories.

Secrets management is never finished, but it does become routine: a short list of owned credentials, rotated on schedule, read by applications from one encrypted home and visible in one audit log.