A leaked secret is not a bug you fix. It is a working credential somebody else now holds, and deleting the line of code changes nothing.
The short answer
Secrets management is how an organisation creates, stores, distributes, rotates and revokes the credentials that systems use to authenticate to each other. API keys, database passwords, private keys and tokens all qualify. The discipline exists because these values are needed by running code, which makes storing them safely genuinely awkward, and because a single exposed one is frequently the whole breach.
Most secrets management ends after the first two stages, and the risk concentrates in the three that follow.
On this page
What secrets management covers
Secrets management covers more than the values a developer would name if asked.
| Type | Why it matters |
|---|---|
| API keys and tokens | Often long lived and broadly scoped, so one key can reach far more of a third-party service than the feature that needed it |
| Database credentials | Direct access to production data, usually bypassing every application-layer control you built |
| Cloud access keys | The highest-value target. A key with broad permissions is equivalent to an administrator account |
| Private keys and certificates | Allow an attacker to impersonate your service or decrypt intercepted traffic |
| Encryption keys | Storing the key beside the encrypted data makes the encryption decorative |
| Webhook and connection URLs | Frequently overlooked because they look like configuration rather than credentials, while carrying an embedded token |
Where secrets leak
Secrets management fails at the edges rather than in the obvious places.
| Location | How it happens |
|---|---|
| Source code | Hard-coded during development and never removed. Public repositories are scanned continuously by automated tooling |
| Commit history | Removed from the current file but still present in an earlier commit, which most people believe counts as deleted |
| Container images | Baked in at build time and readable by anyone who can pull the image, including from earlier layers |
| Pipeline configuration | Sitting in build files or printed by a verbose step into logs that are retained and widely readable |
| Application logs and errors | A connection string in a stack trace, forwarded to a monitoring service and stored for months |
| Chat and tickets | Pasted into a message or attached to a ticket during troubleshooting, then indexed and searchable forever |
The last three surprise people. A team can enforce clean repositories and still leak credentials daily through a logging pipeline or a support thread.
The five secrets management stages
| Stage | What good looks like |
|---|---|
| Create | Scoped to the narrowest permission the task needs, and issued per service rather than shared across several |
| Store | In a dedicated encrypted store with access control and an audit trail, not in environment files copied between laptops |
| Distribute | Injected at run time from that store, so the value never enters the repository, the image or the pipeline configuration |
| Rotate | Automatically and on a schedule, which caps the useful life of anything that leaked without your knowledge |
| Revoke | Immediately when a service is decommissioned or a person leaves, with someone able to confirm it actually happened |
Short-lived credentials beat careful storage
The strongest version of secrets management is needing less secrets management. Credentials generated on demand and valid for minutes are worth far less to an attacker than a key issued at launch and still valid two years later, because the window to use them barely exists. Where a cloud provider or platform can issue temporary credentials to a workload directly, that removes the secret from the equation rather than protecting it, which is a better outcome than any vault provides.
Rotate, do not delete
This is the secrets management rule that saves the most damage, and the one most often got wrong under pressure.
When a secret is found somewhere it should not be, the instinct is to remove it and commit the fix. That resolves nothing. The credential still works, and the exposed copy persists in places you do not control.
| Where the old value survives | Why removal does not reach it |
|---|---|
| Commit history | Every earlier commit still contains it, and rewriting history does not affect clones anyone already made |
| Forks and mirrors | Copies exist outside your account entirely, and you cannot edit them |
| Caches and archives | Search engines, code indexes and archive services may hold a snapshot taken before the fix |
| Build artefacts | Images and packages already published still carry the original value inside them |
| Automated collection | Public repositories are scanned continuously. A key pushed publicly should be treated as captured within minutes |
The correct sequence is to rotate first so the exposed value stops working, then check logs for any use of it, then clean up the code. Treat the old credential as compromised regardless of how briefly it was visible.
Where Osto fits
Osto does not sell a secrets vault, and a dedicated store is the right tool for that part of secrets management. What the platform addresses is the two things that decide whether a leaked secret becomes an incident: how much it can reach, and how quickly its use is noticed.
Scope is handled through identity. Identity and access management keeps service permissions narrow so a captured key reaches one function rather than an account, privileged access management governs the credentials worth the most, and zero trust access means a stolen credential alone does not reach infrastructure that requires a managed device. Cloud posture management flags over-permissioned roles and keys that were never scoped down after launch.
Detection is the second half. Because identity, cloud and application events land in one SIEM, a credential suddenly used from an unfamiliar location or calling operations it has never called reads as a pattern rather than a normal authenticated request. VAPT also surfaces exposed credentials in applications and infrastructure during testing. Together with documented rotation, that satisfies what SOC 2, ISO 27001 Annex A and PCI DSS expect around credential handling, and PCI is explicit about it.
The practical read for a small team is that secrets management is worth doing properly at the storage layer, and worth assuming will fail anyway. Both halves are cheaper than the incident.
Platform walkthrough
Shrink what a leaked key can reach
Narrow identity scope, zero trust access to infrastructure, cloud posture on over-permissioned roles, and credential misuse visible in one SIEM.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is secrets management?
The practice of creating, storing, distributing, rotating and revoking the credentials that systems use to authenticate to each other, including API keys, database passwords, tokens and private keys.
What should you do when a secret is committed to a repository?
Rotate it first so the exposed value stops working, then review logs for any use of it, then clean the code. Deleting the line does not help, because the value remains in history, in forks and in anything already cloned.
Is secrets management just environment variables?
Environment variables are better than hard-coding, and not sufficient on their own. Environment files get copied between machines, committed by accident and printed into logs by verbose error handling. They also provide no audit trail and no rotation.
How often should secrets be rotated?
Frequently enough that an undetected leak expires before it is useful, and automatically, because manual rotation stops happening within a few months. The stronger approach is short-lived credentials issued on demand, which reduces the number of standing secrets to rotate at all.
Is secrets management required for compliance?
PCI DSS is explicit about credential handling and rotation. SOC 2 and ISO 27001 Annex A address it through access control and key management expectations rather than naming a tool.