TL;DR: Akeyless shows that OWASP’s Secrets Management Cheat Sheet still leaves teams exposed when reusable credentials leak through pipelines, vault sprawl, and runtime workflows. The stronger shift is from stored secrets to governed access with short-lived credentials and cross-vault control.
At a glance
What this is: This is an analysis of OWASP secrets management guidance and the main finding is that central storage alone does not remove risk when reusable credentials still move through pipelines, vaults, and runtime environments.
Why it matters: It matters because IAM, PAM, NHI, and platform teams still have to govern where secrets live, how they are used, and when they expire if they want to shrink standing access risk.
By the numbers:
- 96% of organisations report secrets sprawl, creating uneven governance across vaults and environments.
👉 Read Akeyless's analysis of OWASP secrets management guidance and stored credential risk
Context
OWASP’s secrets management guidance starts from a simple premise: secrets are not just configuration values, they are governed credentials that need ownership, access control, rotation, revocation, and auditing. The problem is that most real environments are not a single vault with one lifecycle. They are a mix of CI/CD pipelines, cloud services, Kubernetes, developer tooling, and legacy systems.
That is where secrets sprawl becomes an identity governance issue, not just a storage issue. Once a reusable secret is copied into multiple systems, the organisation loses a clean view of who can use it, when it is still needed, and which workload actually depends on it. Centralisation helps, but only if governance stays consistent across the estate.
The article is typical of modern secrets-management guidance in one important respect: it treats storage as the starting point, not the finish line. The operational question is whether a workload needs a reusable secret at all, or whether runtime-issued, short-lived access can replace it.
Key questions
Q: What breaks when secrets are duplicated across multiple tools and vaults?
A: Revocation becomes unreliable, rotation states diverge, and audit evidence no longer tells a complete story. A credential may be disabled in one place while still active in another, which means exposure can persist even after the security team believes the secret has been remediated.
Q: Why do reusable credentials increase risk even when they are centrally stored?
A: Central storage controls location, not lifetime. If the same secret is reused by multiple workloads or copied into CI/CD and runtime systems, one compromise can create broad access. The risk comes from persistence and reuse, which are identity governance problems, not storage problems.
Q: How should teams decide between rotation and short-lived identity for integrations?
A: Use rotation as a containment step, not as the design goal. If an integration depends on permanent secrets to keep working, the safer choice is to move to short-lived, scoped identity so the credential cannot outlive the task it was created for. That changes the trust model instead of just refreshing it.
Q: How should security teams govern cloud secrets across DevOps and runtime systems?
A: Treat secrets as lifecycle-managed NHI credentials, not static configuration values. Assign ownership, scope every credential to a purpose, rotate it on exposure or expiry, and remove standing access wherever possible. The governance goal is to shrink the time and scope of usable access, especially in pipelines and cloud workloads.
Technical breakdown
Why centralised secrets storage still leaves governance gaps
Centralised storage reduces fragmentation, but it does not by itself solve credential lifecycle risk. A secret can sit in a vault and still be reused across workloads, copied into pipeline variables, or referenced by legacy scripts that no one wants to touch. In practice, the control problem is not only where the secret is stored. It is whether ownership, dependency mapping, rotation, and revocation stay accurate as the environment changes. That is why vault-centric programs often look controlled on paper while still carrying standing access risk in execution.
Practical implication: Treat vaulting as a storage control, not a full governance model, and map every secret to a current workload owner and dependency.
How CI/CD turns secrets into standing operational access
CI/CD systems are especially risky because they sit close to production access and are designed to move quickly. Credentials often appear in workflow files, job logs, runner state, deployment tokens, or build artifacts, which means the pipeline becomes both a delivery mechanism and a secret transport path. The technical issue is that the pipeline frequently needs to authenticate on behalf of multiple systems, so teams reuse broad credentials to avoid breakage. That reuse is what turns a deployment helper into a standing access path.
Practical implication: Separate deployment orchestration from secret value handling so pipelines reference credentials instead of carrying them.
Why short-lived credentials outperform rotation for many workflows
Rotation reduces the useful life of a stolen secret, but it still leaves a valid credential in circulation between events. Short-lived credentials change the trust model by issuing access only when the workload needs it and ending that access automatically after use. Technically, that moves the control point from post-issuance cleanup to issuance-time governance. The difference matters because a credential that expires after execution cannot become a long-standing reusable secret in the same way a password or static token can.
Practical implication: Prefer runtime-issued credentials for workloads that do not truly need persistent secrets and reserve rotation for legacy exceptions.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Stored secrets are a governance outcome, not a security end state: Centralising credentials improves visibility, but it does not eliminate reuse, drift, or dependency sprawl. The article’s core lesson is that a secret can be well stored and still poorly governed if it remains reusable across pipelines, clouds, and runtime systems. Practitioner conclusion: the control objective is governed access, not vault occupancy.
Secrets sprawl is really control-plane fragmentation: When secrets live across multiple vaults and cloud-native stores, each system records only part of the access story. That breaks the organisation’s ability to answer simple lifecycle questions about ownership, last use, and revocation scope. Practitioner conclusion: teams need one governance view over distributed secret stores, not isolated administrative islands.
Runtime-issued access changes the risk equation: Rotation assumes a credential will exist long enough to be reused and then cleaned up. Short-lived access removes that assumption by shrinking the window in which a secret can become standing risk. Practitioner conclusion: workflows that can operate without reusable secrets should be redesigned to do so.
Ephemeral credential trust debt: The real debt in modern secrets management is not just secret count, it is the amount of trust accumulated in credentials that outlive their original purpose. The article shows that every extra system holding or reusing a secret compounds that debt across governance, audit, and incident response. Practitioner conclusion: reduce the number of credentials that must be trusted over time, not just the number that are stored.
Cross-vault governance is now a baseline requirement: Organisations rarely run a single secrets estate, so governance must extend across cloud vaults, Kubernetes secrets, CI/CD variables, and legacy stores. The challenge is less about where a secret resides and more about whether the access path can be reconstructed and controlled end to end. Practitioner conclusion: if you cannot trace the secret path, you cannot govern the secret lifecycle.
From our research library:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Ephemeral credential trust debt: The longer a reusable secret survives across pipelines, vaults, and runtime environments, the more trust it accumulates and the harder it becomes to govern. Teams should read that as a signal to reduce credential persistence, not just improve storage hygiene.
Short-lived credentials shift the control point from cleanup to issuance, which is where NHI governance becomes more precise. Once access expires with the task, the organisation removes an entire class of standing secret risk from the workflow.
For practitioners
- Map every reusable secret to an owner and dependency Start with credentials that feed production workloads, then document the current workload, business owner, and upstream consumers so rotation or revocation does not break unknown dependencies.
- Separate pipeline orchestration from secret value handling Review workflow files, job logs, runner behaviour, and build artifacts so CI/CD systems pass references or workload identity instead of carrying secret values.
- Replace persistent access with short-lived credentials For workloads that only need access during execution, issue runtime credentials with a narrow scope and automatic expiry rather than leaving a reusable secret in circulation.
- Unify governance across external vaults Build one control view across cloud vaults, Kubernetes secrets, and legacy stores so access, audit, and revocation decisions are based on the full secret path.
Key takeaways
- OWASP’s guidance is still directionally correct, but the main problem is not storage alone, it is whether reusable secrets continue to circulate across systems after they should have disappeared.
- The article shows why secrets sprawl and pipeline exposure remain hard to govern in practice, especially when one credential is shared by multiple services or copied into delivery workflows.
- The decisive control change is to replace persistent reuse with runtime-issued access wherever the workload allows it, then reserve rotation for legacy exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on reusable secrets leaking through pipelines, logs, and distributed vaults. |
| NHI-07 — Long-Lived Secrets | Rotation limits and static credentials are the main governance problem discussed in the article. | |
| NHI-01 — Improper Offboarding | Stale credentials and leftover access are part of the article's lifecycle risk story. | |
| Recommendation — Scan for exposed secrets and remove reuse paths that let a single leak affect multiple systems. Shorten secret lifetime wherever workflows can support runtime-issued credentials. Revoke secrets that no longer map to an active workload or owner. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Secret leakage and reuse create pathways for credential access and downstream movement. |
| Recommendation — Hunt for credential exposure paths that can enable reuse across adjacent systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation, revocation, and lifecycle control are directly covered by authenticator management. |
| Recommendation — Apply authenticator management controls to enforce rotation, revocation, and expiry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling who and what can use credentials across environments. |
| Recommendation — Align credential issuance with least-privilege entitlements and explicit authorizations. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cross-vault governance and lifecycle control are cloud IAM issues across multiple stores. |
| Recommendation — Unify access governance across cloud vaults, CI/CD systems, and workloads. | ||
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.
- Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
- 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.
- 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.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step review areas for leftover secrets, including ownership, dependency mapping, and rotation paralysis
- CI/CD exposure patterns across workflow files, runner behaviour, job logs, and build artifacts
- Operational differences between rotation, just-in-time access, and secretless access for workloads
- How Multi-Vault Governance and the Universal Secrets Connector handle external secrets across multiple stores
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org