Your secrets are in .env files, CI variables and chat
Somebody pasted the production database password into a thread two years ago so a colleague could debug something, and it is still there, still valid, and still searchable. Secret sprawl is not a tooling gap. It is the absence of one place where a secret is allowed to live.
Where secrets actually are right now
Not in one system. In six, with different access rules, no shared history and no way to answer the only question that matters: who can read production.
Nobody can list every secret, where it lives, who can read it or when it was last changed — usually discovered during an audit, an offboarding or an incident.
-
“Our cloud keys were in a code repository for six months.”
You cannot know who copied them in that window, so the remediation is rotation plus an investigation you have no data for.
-
“We just realized a former contractor still has admin access.”
Secrets shared with a person rather than granted to a role do not get revoked when that person leaves.
-
Production values live in CI variables that any maintainer can print.
Read access to production secrets is effectively granted to everyone who can edit a pipeline definition.
-
Every environment has a .env file, and none of them match.
Configuration differences between environments become incident causes that are invisible in code review.
-
Nobody knows when a secret was last rotated, or by whom.
Rotation becomes an unplanned emergency, performed under pressure, with an unknown list of consumers.
What sprawl costs
Secrets are the one part of a system where a single mistake is not a degradation. It is a compromise.
- An incident you cannot bound
- Without a single store and an access record, the honest scope of a leak is "everything that credential could reach, for as long as it existed".
- Offboarding that never completes
- Every secret a departing engineer saw remains valid until someone rotates it, and nobody has the list.
- Audit findings
- Separation of duties and key management are standard control areas. "We keep them in the pipeline settings" is a finding in every framework.
- Rotation avoidance
- When nobody knows which services consume a secret, rotating it risks an outage, so it never happens, and the value ages for years.
What we do about it
We give secrets one home: encrypted in Git, decrypted only by a key the pipeline controls, delivered to workloads automatically, and changed only through review.
-
Encrypted in the repository, reviewed like code
One encrypted file per application per stage, so a secret change is a pull request with an author, a reviewer, a reason and a history.
-
A key per stage, held in the security account
Encryption keys live outside the workload accounts, and the permission to decrypt production is separate from the permission to write code.
-
Delivered to workloads, never copied by hand
On merge, values are written into parameter storage as encrypted strings, and an operator delivers them into workloads. No engineer types a production secret into a console.
-
Separation of duties that is enforced by the key
For staging and production, a change passes through a lead, a second code owner, an environment reviewer and a dedicated writer role before a read-only consumer ever sees it.
-
A rehearsed response when something leaks
Documented playbooks for the realistic scenarios, including a plaintext commit and a compromised key, with a step-by-step rotation procedure.
The outcome: A developer with write access to the repository still cannot read or change a production secret, because the key refuses the request. Every secret has one place, one history and one access rule.
What that is, in the portfolio
-
BuiltForProd Blueprints
Opinionated, production-ready reference architectures for real workloads, deployed into your Baseline. Each one is a working system, not a diagram.
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
What you get
-
One encrypted store per application and stage
Secrets encrypted in your own repository, readable only through a key your cloud account controls, with the full change history that Git already gives you.
-
Stage-separated encryption keys
Separate keys per stage held in the security account, so sandbox, development, staging and production do not share a blast radius.
-
Automatic delivery to workloads
Values are synced to encrypted parameter storage on merge and delivered into running workloads by an operator, with no manual step in the path.
-
An enforced approval chain
A documented separation-of-duties flow for staging and production, implemented through code owners, protected environments and distinct write and read roles.
-
A guard against placeholders
A pull request check fails when a placeholder value would reach an environment, so a half-finished change cannot ship quietly.
-
Incident and rotation procedures
Playbooks for the leak scenarios teams actually hit and a step-by-step rotation procedure written before you need it.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
What is in the Blueprint
One repository, and no new infrastructure of its own to operate.
| What | Figure | Where it comes from |
|---|---|---|
| Encryption keys | One per stage | The Secrets Blueprint holds stage-separated keys in the security account, away from workload accounts. |
| Approval chain for production | 5 steps | Secrets Blueprint. Lead writes, a second code owner approves, an environment reviewer approves, a writer role syncs, a read-only role consumes. |
| Leak playbooks | 5 scenarios | Secrets Blueprint incident documentation, including plaintext committed to Git and key compromise. |
| Rotation procedure | 7 steps | A documented manual procedure in the Secrets Blueprint. Rotation is deliberate, not automatic. |
| Placeholder values reaching an environment | Blocked | A pull request check in the Secrets Blueprint fails on any placeholder. |
| Extra infrastructure to run | None | The Secrets Blueprint adds no standing infrastructure of its own. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Find every secret
Repositories, pipeline settings, chat history, laptops, configuration files and the one spreadsheet. The inventory is usually the uncomfortable part.
-
Decide the access model
Which roles may write, which may approve, which may read, and which stages need the full separation of duties. Scoped and priced before work starts.
-
Deploy and migrate
Our engineers deploy the keys, the store, the pipeline and the delivery operator, then migrate secrets in and rotate every value that has been exposed.
-
Rotate one, together
In the handover your team performs a real rotation through the full approval chain, so the procedure is practiced rather than filed.
Yes, but…
The objections we hear on the first call, answered plainly.
Why not a hosted secrets manager?
Managed stores are good at storing. The gap teams hit is process: who may change a production value, who approved it and what it was before. Keeping the encrypted value in Git makes review, history and approval the same mechanism your code already uses.
Are secrets in Git not the problem we are trying to fix?
Plaintext secrets in Git are the problem. These are encrypted with a cloud key that most engineers cannot use, so the repository holds ciphertext that is useless without a decrypt permission you control.
Does this rotate secrets automatically?
No, and we will not claim it does. Rotation is a documented, deliberate procedure with an approval chain. Automatic rotation without knowing every consumer is how rotation causes outages.
Our developers need production values to debug.
That is the habit the model ends. Debugging happens with non-production values, and production access is a reviewed, logged exception rather than a shared convenience.
Questions
What is the Secrets Blueprint?
The Secrets Blueprint is a centralized secret management design delivered as one repository. Secrets are encrypted in Git with cloud-managed keys, synced to encrypted parameter storage on merge, and delivered into workloads by an operator, with separation of duties enforced for staging and production.
Who can read a production secret?
Only the roles granted decrypt permission on the production key, which is deliberately not the set of people who can write code. A developer with write access to the repository still cannot read or change a production secret, because the key refuses the request.
What happens if a secret leaks anyway?
You follow the playbook for that scenario: contain, rotate through the documented procedure, verify every consumer, and record what was exposed and for how long. Having the procedure written before the incident is most of the value.
Does this work with our existing applications?
Yes, where the application reads configuration from the environment or from files. Delivery into containerized workloads is built in; other runtimes read from parameter storage directly.
Can it be deployed on its own?
It is designed to sit on a foundation with a security account, managed keys and a review-gated pipeline. If that exists, it can be added on its own; if not, the foundation comes first.
More answers are in the FAQ and the support center.
Give every secret one home.
Tell us where your secrets live today, honestly. We will tell you what it takes to consolidate them, rotate what has been exposed, and make production readable only by the people who should read it.