Topic starter
15/08/2026 12:47 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “OWASP Secrets Management Cheat Sheet: Reducing Static Secrets in Practice”.
By the numbers:
- 96% of organisations report secrets sprawl, creating uneven governance across vaults and environments.
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.
Q: Why do reusable credentials increase risk even when they are centrally stored?
A: Central storage controls location, not lifetime.
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.
Practitioner guidance
- 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.
Bottom line: 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.
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
👉 Read Akeyless's analysis of OWASP secrets management guidance and stored credential risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 12:47 pm
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.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: OWASP secrets guidance shows why stored credentials still create risk