Notifications
Clear all
Topic starter
15/08/2026 12:47 pm
TL;DR: OWASP’s Secrets Management Cheat Sheet reinforces that centralisation, rotation, revocation, and auditing matter, but the article shows why reusable credentials still leak through pipelines, vault sprawl, and runtime workflows, according to Akeyless. The real shift is from stored secrets to governed access with short-lived credentials and cross-vault control.
NHIMG editorial — based on content published by Akeyless: OWASP secrets management cheat sheet analysis
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 96% of organizations report secrets sprawl.
Questions worth separating out
Q: How should security teams govern secrets across multiple vaults?
A: Security teams should govern multi-vault environments above the storage layer.
Q: Why do reusable secrets keep creating risk even after rotation?
A: Rotation only shortens the useful life of a leaked credential.
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.
Practitioner guidance
- Map every reusable secret to a named owner and workload Start with the credentials teams are least comfortable changing.
- 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.
- 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.
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
👉 Read Akeyless's analysis of OWASP secrets management guidance →
OWASP secrets management cheat sheet: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
15/08/2026 12:47 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OWASP secrets guidance shows why stored credentials still create risk
