Most credential leaks are not the result of a sophisticated attack. They come from an API key committed to a public repository, a production database password pasted into a Slack channel to unblock a colleague, or a `.env` file that made it into a Docker image nobody thought to check. By the time anyone notices, the key has usually been scraped and used within hours. None of this requires negligence — it is what happens by default when secrets management is treated as a detail rather than a decision.
For a small engineering team, the question is not whether to take secrets management seriously — it is how much infrastructure that seriousness actually requires. Over-engineering this is as common as under-engineering it: a five-person team running a self-hosted Vault cluster is often solving a problem it does not have yet, at the cost of a problem it now does. The right answer depends on team size, what you are storing, and who needs access.
Where secrets actually leak from
Before choosing a tool, it helps to be precise about the failure modes it needs to close.
- Git history. A key removed from the latest commit is still in every earlier one. `git log -p` finds it in seconds, and so does anyone who clones the repository before the fix lands.
- CI/CD logs. Build pipelines routinely print environment variables during debugging, and those logs are often kept for months and readable by anyone with access to the CI project.
- Container images. A secret baked into a Docker image at build time travels with every copy of that image, including the ones sitting in a registry nobody has pruned.
- Shared documents and chat. Credentials pasted into a spreadsheet, a wiki page, or a direct message are outside any access control the rest of the system has, and nobody remembers to delete them later.
- Long-lived, over-scoped tokens. A key issued once and never rotated, with permissions wider than the task needs, turns a small mistake into a large one.
Almost every leak we see in the wild is one of these five, not a novel attack. Fixing them is mostly a matter of removing the places where a secret can sit still in plain text.
Three tiers of secrets management, and when each one fits
Environment variables and a local .env file
This is where every project starts, and for a solo developer or an early prototype it is often the right place to stay. The failure mode is not the approach itself — it is `.env` files ending up in version control, in support tickets, or copied between machines over channels with no audit trail. If you stay at this tier, the minimum discipline is: `.env` in `.gitignore` from the first commit, no secret ever pasted into chat or a ticket, and different values for local, staging and production so a mistake in one environment cannot touch another.
A cloud-native secrets manager
Once you have more than one or two engineers, more than one environment, or a compliance requirement to point to, this is usually the right tier. AWS Secrets Manager, Azure Key Vault and Google Secret Manager all do the same core job: they store the secret centrally, control who and what can read it through the same identity and access system you already use for the rest of the cloud account, and log every access. Your application fetches the secret at start-up or runtime instead of having it baked into an image or a config file. The cost is small, the integration effort is a day or two if you are already on that cloud, and it removes most of the failure modes above without adding a new system to operate.
A dedicated secrets platform
Tools such as HashiCorp Vault or Doppler earn their keep when secrets need to move across more than one cloud provider, when you need dynamic credentials that are generated on demand and expire automatically, or when the audit and compliance requirements go beyond what a single cloud vendor’s tool provides. This is genuinely more capable, and genuinely more to run and maintain — Vault in particular is its own piece of infrastructure with its own unlock and backup procedures. For most teams under twenty engineers on a single cloud provider, this tier is not yet necessary; it becomes worth the overhead when the multi-cloud or compliance need is real, not hypothetical.
Rotation matters more than storage
A secrets manager that holds a database password unchanged for three years has solved storage and left the harder problem untouched. Rotation is what limits the damage when a leak happens anyway, because it did, at some point, at nearly every organisation that has been running long enough. The practical version of this for a small team is not a fully automated rotation pipeline on day one — it is knowing, for each credential, who can rotate it and how long that takes, and actually rehearsing it once. Cloud secrets managers can automate rotation for their own services (an RDS database password, for instance); third-party API keys usually still need a manual process, so that process should exist before it is needed under pressure.
If you are commissioning software, not just running it
When you are evaluating a vendor to build or maintain a system for you, secrets management is one of the more revealing things to ask about, because the answer is hard to fake convincingly. Worth asking directly: where do production credentials live, and who at the vendor can read them in plain text? Are staging and production using different keys, or the same ones with different data behind them? What happens to access when someone leaves the project? And, for anything handling customer data, is there a written incident process for what happens if a key is exposed — not a promise that it will not happen, but a plan for when it does.
A vendor who answers these with specifics — tool names, who holds access, how rotation works — is telling you something real about how the rest of the system is likely to be built. A vague answer is telling you something too.
A working checklist
- No secret has ever been committed to version control, including in an old commit — check with a scanning tool if you are not certain, not by memory.
- Production and non-production environments use different credentials, never the same key with an environment flag.
- Access to each secret is scoped to what actually needs it, not granted account-wide because it was easier at the time.
- There is a named owner for each credential who knows how to rotate it, and it has been rotated at least once outside an emergency.
- Offboarding a team member includes a step to revoke or rotate what they had access to, and that step is actually followed.
None of this requires the most sophisticated tool available. It requires picking the tier that matches your team’s actual shape, and being disciplined about the handful of places secrets tend to go to die.