Secret sprawl

What it is

Secret sprawl is the gradual accumulation of credentials in every place a team's workflow touches: .env files on developer laptops, environment variables in CI configs, Kubernetes Secret resources, AWS Secrets Manager entries from a quick experiment three years ago, password manager vaults shared among different subsets of the team, Notion pages, Slack DMs, screenshots in support tickets. None of these places are inherently wrong; the problem is that they don't talk to each other, and as soon as you have a credential in more than one of them, you have a coordination problem disguised as a security problem.

The term gained traction around 2018-2020 as the secrets-management category emerged. It names a failure mode that's older than the term: every engineering team that grows past one developer rediscovers it.

How it happens

Sprawl doesn't happen because anyone made a bad decision. It happens because each individual decision was correct at the time:

• A developer puts the database URL in .env so they can run the app locally. Reasonable.
• A CI runner needs the production deployment key, so it goes in the pipeline's secret store. Reasonable.
• A new service needs the Stripe key, so the engineer who set it up copy-pastes the value from their .env into the deployment platform. Reasonable.
• A vendor change requires updating an API key, so the new one gets pasted into the same places. Mostly reasonable, except now there are two values floating around for a while.
• A new engineer joins and needs the same credentials. Someone DMs them the file. Reasonable; also irreversible.

After two years, the credentials a small team depends on exist in twelve places, and nobody has a complete inventory.

What it costs

Sprawl converts what should be a five-minute operation into an organizational problem:

• Rotation is impossible. Replacing a leaked credential means finding every copy. Missing one leaves a working backdoor.
• Audit is impossible. Nobody can answer "who has had access to value X over the last 90 days?" Every place storing the secret has its own (or no) access trail, and they don't aggregate.
• Drift is normal. Each environment's copy diverges. The credential that works in staging doesn't work in production. The investigation costs an afternoon every time.
• Offboarding is incomplete. Removing someone's access means walking every place they could have touched a secret. There's no canonical answer to "what does X have access to?"
• Blast radius is unbounded. A leaked .env file from a developer's laptop might include credentials for systems that developer didn't even know existed.

How a secrets manager ends it

Centralizing credentials into one system replaces the inventory problem with a smaller one: making sure consumers actually fetch from the central system instead of caching values locally. A secrets manager can't stop a developer from copy-pasting a value into a config file, but it can:

• Provide one canonical place where the current value lives.
• Log every read, so "who has touched this in the last 90 days" has an answer.
• Make rotation a single operation, with consumers picking up the new value on their next fetch.
• Define per-actor access, so a leak from one consumer doesn't expose every other secret.

The trade is conceptual rather than technical. Sprawl is comfortable because it never asks you to think about your entire credential surface at once. Centralizing forces that thought up-front; in exchange, every later operation is bounded.

How SikkerKey handles it

In SikkerKey, every secret lives in one place: a project inside your vault. Each secret has an explicit list of machines allowed to read it, and every read is recorded in your audit log with the requesting machine, IP, and timestamp.

When a credential needs to change, you update it once in SikkerKey, and consumers fetch the new value on their next read. For credentials backed by PostgreSQL, MySQL, MongoDB, Redis, or MSSQL, scheduled rotation generates new values automatically and pushes them to the database. The "twelve places" version of secret state becomes one place, with the operational consequences that follow.