Central secret storage
Vault, cloud key management or SOPS, chosen for your constraints, with namespacing and access policies that mirror how your teams are actually organised.
Security & Compliance
Secrets Management
No credentials in Git, and nothing long-lived enough to be worth stealing.
The work
What this actually does
Most breaches we are called in for start with a credential somebody left somewhere convenient: a token in a config file, a database password in a private repository, a key pasted into a shared document. We find those, remove them, and build a path where the application fetches what it needs at runtime instead.
The work usually means HashiCorp Vault, a cloud key management service or SOPS depending on your size and where you run. We scope access by workload identity rather than by shared accounts, set rotation on the schedule your team can actually maintain, and add detection for secrets that escape into a repository or log.
If any of these sound familiar
- A production database password has been in the repository for three years
- Nobody can say who has access to the production credentials right now
- Rotating a key means coordinating five teams and a maintenance window
- The same password is shared by three services and four engineers
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Workload identity
Pods, functions and build agents authenticate with short-lived tokens from their platform identity, so no human has to hold a durable credential at all.
Automated rotation
Rotation jobs for database passwords, API keys and certificates, scheduled with enough overlap that a running service never notices a rotation happening.
Leak detection and response
Repository and log scanning plus provider-side alerts, so a committed token is caught in minutes and revoked rather than discovered during an incident review.
Developer access workflow
A short, documented way for engineers to fetch what they need locally with a personal identity, audit logged and time limited, instead of copying values from a chat message.
Migration of existing secrets
An inventory of where credentials live today and a sequenced plan to move them, including the awkward ones embedded in legacy code you cannot change this quarter.
What changes
What teams typically see
0Secrets stored in Git
90 daysTypical rotation interval
30 minTarget for leak revocation
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Inventory of every credential store and its owner
- Configured secret store with scoped access policies
- Rotation schedules and the jobs that enforce them
- Remediation plan for leaked and hardcoded credentials
- Runbook for rotating and revoking under pressure
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
HashiCorp Vault
AWS
Microsoft Azure
Google Cloud
Kubernetes
Terraform
GitHub
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Find where secrets live
A scan of repositories, CI configuration, container images and cloud accounts builds an inventory, so decisions are based on what is really there rather than on assumptions.
- 02
Choose the store and model
We agree on the backend, the naming scheme and who can read what, then write it down before any migration begins so the target is not invented mid-flight.
- 03
Migrate workload by workload
Applications move to short-lived credentials one at a time, each with a rollback path, starting with the ones that carry the most exposure and the least complexity.
- 04
Rotate, detect, rehearse
Once live we run the rotation jobs for real, deliberately test the leak alarm, and hand your team the runbook for revoking a credential on a bad day.
Questions
Asked before we start
Do we need Vault, or can we stay on cloud-native tooling?
AWS Secrets Manager, Azure Key Vault and Google Secret Manager are fine for many teams and we often start there. Vault earns its place when you need dynamic credentials, broad multi-cloud coverage or strict isolation, and we will tell you when that is not yet the case.
What about the secrets already committed to our history?
Removing the file is not enough, because the value sits in the git history and every clone ever made. We treat anything exposed as compromised, rotate it first, then rewrite history only where that is safe and worth the disruption.
Will rotation break running applications?
It can, if an app caches a credential at startup and never re-reads it. We test rotation in staging with the same overlap logic used in production, and where an application genuinely cannot handle it we document that limit rather than pretending otherwise.
How do you handle secrets for local development?
Developers get short-lived credentials tied to their own identity, usually through a CLI login or a token broker, so no shared development password exists. That also gives you an audit trail showing which person read which secret and when.
Security & Compliance
Often needed alongside this
Security & Compliance
DevSecOps & Compliance
Security checks wired into the pipeline, so vulnerabilities are caught in review instead of in production.
- SAST, DAST, dependency and container scanning
- Secrets management with Vault, KMS and SOPS
- Policy as code and audit-ready evidence trails
Security & Compliance
IAM, Zero Trust & Access Reviews
Least-privilege access that's provable, reviewed and revoked automatically when someone changes teams.
- Least-privilege role and policy design
- SSO, MFA and federated identity
- Scheduled access reviews and automatic revocation
Security & Compliance
Policy as Code
Guardrails expressed as code, enforced before deployment — not a wiki page nobody reads.
- Open Policy Agent and Kyverno policies
- Budget, tagging and region restrictions
- Pre-merge plan checks on every pull request
Worth a conversation about Secrets Management?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.