OWASP secrets guidance shows why stored credentials still create risk

At a glance

What this is: This is an analysis of OWASP secrets management guidance, with the key finding that centralised storage is not enough when reusable credentials keep spreading across pipelines, vaults, and runtime systems.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern where secrets exist, how long they remain valid, and which workloads can use them across cloud and CI/CD environments.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.
• 96% of organizations report secrets sprawl.

👉 Read Akeyless's analysis of OWASP secrets management guidance

Context

OWASP secrets management guidance is about controlling credentials as governed assets, not just storing them in a vault. The problem is that secrets rarely stay in one place, and once they move through CI/CD, cloud services, developer tooling, and runtime environments, centralisation alone no longer describes the full control problem.

For NHI governance, the real issue is lifecycle. A reusable secret can be created, copied, embedded, exposed, rotated, and revoked, but each of those steps creates another place where ownership and scope can drift. That is why secrets management has to be treated as an access governance discipline, not a storage decision.

The most useful lens is whether a workload needs a reusable secret at all. If access can be issued at runtime and expire after use, the organisation reduces standing risk instead of simply relocating it to a better-managed store.

Key questions

Q: How should security teams govern secrets across multiple vaults?

A: Security teams should govern multi-vault environments above the storage layer. That means creating one inventory of all secrets, mapping ownership and consumers, and enforcing the same rotation and expiry rules across every store. Without that cross-vault layer, each vault becomes a separate island of privilege with its own blind spots.

Q: Why do reusable secrets keep creating risk even after rotation?

A: Rotation only shortens the useful life of a leaked credential. It does not stop the secret from being copied into logs, workflows, build artefacts, or runtime configs between rotation events. If a workload can use runtime-issued access instead, the better control is to eliminate the reusable secret rather than keep renewing it.

Q: What do security teams get wrong about developer and CI secrets?

A: They often treat these secrets as operational conveniences instead of high-value identities. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.

Q: Should organisations prioritise secret rotation or access review first

A: They should do both, but access review should come first when unknown or over-privileged identities already exist. Rotation reduces exposure window, but review reduces entitlement sprawl and clarifies ownership. If a team rotates secrets without fixing who can use them, it preserves the same risk pattern with a fresher credential.

Technical breakdown

Why centralised secrets storage still fails at scale

Centralised storage solves only one part of the secrets problem. A secret can be safely placed in a vault and still be duplicated into configuration files, CI/CD variables, build logs, container images, or application memory. The governance failure is not storage itself, but the number of paths a secret can take after provisioning. Once multiple vaults, clouds, and pipelines are involved, access records and ownership become fragmented, and teams lose the ability to answer a basic question: who can still use this credential, and where?

Practical implication: treat vaults as one control point in a broader lifecycle model, not as proof that the secret estate is governed.

How CI/CD turns secrets into standing access

CI/CD systems sit close to production, so they attract broad deployment tokens and service credentials. That makes them efficient delivery mechanisms and dangerous credential warehouses. Secrets leak when job logs echo environment variables, workflow files inherit credentials across repositories, runners retain state between jobs, or deployment artifacts preserve values that were meant to be temporary. The issue is not just exposure, but reuse. A secret embedded for convenience becomes persistent access if the pipeline keeps carrying it forward.

Practical implication: separate deployment orchestration from secret values and shift runtime access to workload identity wherever possible.

Why short-lived credentials change the control model

Rotation reduces the lifespan of a stolen secret, but it still leaves a usable credential in circulation between rotation events. Short-lived credentials change the model by making access time-bounded rather than merely periodically refreshed. That is important because many workloads do not need a durable secret to operate. They need a verifiable way to ask for access at runtime, use it briefly, and then lose it automatically. In that model, the governance question changes from when to rotate to whether a reusable secret is necessary at all.

Practical implication: prioritise ephemeral credential patterns for workloads that can tolerate runtime issuance and TTL-based expiry.

NHI Mgmt Group analysis

Standing secret governance is now a weaker control assumption than most IAM programmes admit. OWASP’s guidance still assumes teams can centralise, rotate, and audit secrets fast enough to keep pace with operational drift. In practice, secrets are copied into pipelines, workload configs, logs, and external vaults faster than those controls can reassemble ownership. The implication is that the control boundary is no longer the vault; it is the entire credential path.

Secret sprawl is a lifecycle failure, not a storage failure. A secret that exists in one place is manageable. A secret duplicated across cloud vaults, CI/CD variables, and runtime systems creates multiple authority points and multiple recovery paths. That is why cross-vault governance matters: security teams need one view of entitlement, exposure, and revocation across the whole estate, not separate local truths.

Rotation remains necessary, but it is not the end state for NHI governance. The cheat sheet correctly treats rotation as baseline hygiene, yet many workflows are now better served by runtime issuance and expiration. That shift matters because governance should reduce the number of reusable credentials that ever exist. Practitioners should treat every static secret as a candidate for elimination, not just renewal.

CI/CD secret handling has become a proxy for broader identity maturity. If teams still allow deployment systems to carry reusable credentials end to end, they are preserving standing risk inside their most automated workflows. The stronger pattern is to separate orchestration from authorisation, so the pipeline moves work, not secret values. That is where secrets management starts to look like identity architecture rather than configuration management.

From our research:

• 96% of organizations report secrets sprawl, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• If you are rebuilding your secrets programme, start with NHI Lifecycle Management Guide to connect provisioning, rotation, and offboarding in one model.

What this signals

Secret sprawl is now the structural problem, not an edge case. With 96% of organisations reporting secrets sprawl, the programme risk is no longer whether a single vault is configured correctly. The issue is whether IAM, PAM, and NHI governance can still trace ownership and expiry across cloud vaults, CI/CD variables, and runtime systems.

Guide to the Secret Sprawl Challenge is the right internal reference point when teams need to move from storage-first thinking to lifecycle control. The practical challenge is not building another repository for credentials; it is reducing the number of reusable secrets that exist in the first place and linking each one to revocation authority.

The governance signal to watch is whether your environment still depends on secrets that survive deployment. When workloads, pipelines, and runtime services all need persistent credentials, the organisation is carrying standing risk inside its automation layer. That is where secrets management stops being a tool choice and becomes identity architecture.

For practitioners

• Map every reusable secret to a named owner and workload Start with the credentials teams are least comfortable changing. Tie each secret to a current owner, a specific workload, and a recent access record before deciding whether it should be rotated, narrowed, or removed. This is the fastest way to expose rotation paralysis.
• Remove secret values from CI/CD paths where possible Review job logs, workflow inheritance, runner state, deployment tokens, and build artifacts to find where secrets are still being carried through delivery systems. Use workload retrieval or runtime issuance instead of passing the secret value through the pipeline unless the build truly requires it.
• Prioritise short-lived credentials over periodic rotation Where a workload only needs access during execution, replace durable credentials with runtime-issued access that expires after use. That reduces the number of standing secrets and narrows the window in which a stolen credential remains useful.
• Establish cross-vault governance for distributed secrets estates Build one control view across cloud vaults, Kubernetes secrets, CI/CD variables, and legacy stores so security teams can trace the full access path before revoking or renewing anything. Without that view, revocation decisions are always incomplete.

Key takeaways

• OWASP’s secrets guidance is useful, but the post shows that centralised storage alone does not solve secrets sprawl across pipelines, vaults, and runtime systems.
• The evidence points to a governance problem that is broader than rotation, because reusable credentials still leak and remain active long enough to matter.
• The practical shift is from storing secrets more carefully to removing reusable secrets from workflows wherever runtime-issued access is possible.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Cross-Vault Governance: Cross-vault governance is the practice of applying one identity and access model across multiple secrets stores and related tooling. It is needed when organisations use cloud vaults, Kubernetes secrets, CI/CD variables, and legacy repositories that all influence the same access path.
• Rotation Paralysis: Rotation paralysis happens when a secret is known to be risky but remains untouched because teams cannot predict the impact of changing it. The credential may still work in production, but its current dependency chain is unclear, so the organisation preserves exposure instead of controlling it.

What's in the full article

Akeyless's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for tracing leftover access back to a named owner and workload
• Operational detail on separating deployment-time access from runtime access in CI/CD
• Examples of how Dynamic Secrets and Multi-Vault Governance fit into existing secrets estates
• Specific review areas for job logs, workflow inheritance, runner state, and build artefacts

👉 Akeyless's full post covers leftover access, CI/CD exposure, rotation limits, and cross-vault governance in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.