Ask an engineer where the production database password lives and you will get an honest, uncomfortable answer: in a lot of places. It is in a .env file on three laptops, in a CI/CD variable someone set two years ago, in a deployment script, in a Slack thread from an incident, and — if the team is unlucky — in a commit that was "removed" but still sits in git history.
None of this happened because anyone was careless. It happened because shipping software requires secrets, and every tool in the pipeline offers its own convenient place to put them. That convenience has a name: secrets sprawl. And it is one of the most reliable ways a company gets breached.
How sprawl happens to good teams
Secrets do not leak because engineers are reckless. They leak because the path of least resistance scatters them:
- Environment files multiply. A
.envfile starts as a local convenience, then gets copied to a teammate, attached to an onboarding doc, and zipped into a backup. Each copy is a credential store nobody audits. - CI/CD variables become a shadow vault. Pipeline settings quietly accumulate cloud keys, registry tokens, and signing credentials. Anyone with permission to edit a pipeline can usually read — or exfiltrate — everything the pipeline can.
- Dotfiles and shell history remember everything. A token exported "just for this session" lands in
.bashrc,.zsh_history, or a personal notes file, and stays there long after the session ended. - Shared documents become the team vault. A wiki page or spreadsheet titled "credentials" is searchable, forkable, and permissioned like every other document — which is to say, badly, and forever.
- Keys get committed. Even with pre-commit hooks and scanners, keys land in repositories. Once pushed, a secret must be treated as public: history rewrites do not un-leak it, and automated scrapers find exposed keys in public repos within minutes.
Each location made sense in the moment. Together they form an attack surface with no inventory, no expiry, and no owner.
Why breaches keep starting here
Leaked credentials are consistently among the most common initial access vectors in real-world breaches. The reason is simple economics: a stolen credential is not an exploit, it is a login. The attacker who finds a valid cloud key does not need to break anything — they authenticate, exactly like the automation that key was created for, and the activity looks legitimate in every log.
Sprawled secrets make this worse in a specific way: they are long-lived and static. A password pasted into a CI variable in 2023 is very likely still valid today. Rotation is painful precisely because the secret lives in many places — rotating it means finding every copy, so teams rotate rarely, so a single old leak stays exploitable for years. Sprawl and stale credentials are the same problem wearing two coats.
The toolbox answer: one vault, short leases, machine identity
The way out is not another policy memo asking people to be careful. It is making the secure path the convenient one, through centralized secrets management:
One vault, organized the way teams work. Secrets live in projects and environments — payments / production, payments / staging — with access granted per team and per environment instead of per heroic memory of who knows which password. Applications and pipelines fetch secrets at runtime; nothing needs a local copy.
Dynamic secrets that expire on their own. The strongest secret is one that stops existing. Dynamic secrets are generated on demand — a database credential, a cloud access key — with a lease: a defined lifetime after which the credential is automatically revoked. A leaked dynamic credential is a problem for minutes, not years, and rotation stops being a project because it is the default behavior.
Machine identities instead of stored keys for CI/CD. The pipeline itself should not hold a long-lived API key to the vault — that just recreates the problem one level up. Instead, the pipeline authenticates with its own machine identity using OIDC-bound claims: the vault verifies a signed token proving this workflow, in this repository, on this branch is running, and issues short-lived access scoped to exactly that context. No stored secret, nothing to leak from pipeline settings.
Sync where teams need it, truth in one place. Real stacks use cloud-native secret stores — AWS Secrets Manager, Azure Key Vault, Kubernetes secrets. The answer is not to fight them but to feed them: the central vault stays the source of truth and syncs secrets outward, so applications keep their native integrations while rotation, access policy, and audit happen in one place.
Why inside the PAM, not another point tool
You can buy a standalone secrets manager. But secrets management is privileged access management for machines — the same question of who may use which credential, when, and with what trail that PAM already answers for humans.
Doing it inside the PAM means one audit trail: the engineer who checked out a server password and the pipeline that pulled a database credential appear in the same log, correlated, reviewable in one place. It means one policy surface: the approval rules, access windows, and least-privilege scoping you defined for human privileged access apply to machine access too, instead of being reimplemented — slightly differently — in a second product. And it is one less tool to integrate, license, and secure, because every additional store of secrets is itself a target.
The engineers on your team already know where the secrets are; that is exactly the problem. Consolidating them is unglamorous work with an outsized payoff — see how Monopam secrets management handles projects, leases, and OIDC-bound machine identities, and how it fits the broader DevOps privileged access picture.
