Notifications
Clear all
Topic starter
25/06/2026 5:15 pm
TL;DR: Secrets are the backbone of DevOps pipelines, but exposed credentials, long-lived tokens, and scattered repositories create breach, outage, and compliance risk, according to Akeyless' DevOps secrets management analysis. Static secret sprawl is now an identity governance problem, not just a DevOps hygiene issue.
NHIMG editorial — based on content published by Akeyless: What Is Secrets Management in DevOps?
Questions worth separating out
Q: How should security teams manage secrets in DevOps pipelines?
A: Security teams should centralise credential ownership, issue short-lived secrets where possible, and remove hardcoded values from code and configuration.
Q: Why do long-lived secrets increase breach risk in cloud and CI/CD environments?
A: Long-lived secrets increase breach risk because they remain useful after exposure, can be copied across tools, and often outlive the task they were meant to support.
Q: What breaks when secrets are scattered across repos, pipelines, and chat tools?
A: Visibility, auditability, and revocation break first.
Practitioner guidance
- Map every reusable secret to an owning identity and system Create a credential inventory that ties each API key, token, certificate, and password to its human owner, workload, service account, and runtime location.
- Replace long-lived secrets in automation with short-lived issuance Use dynamic credentials for pipelines, containers, and batch jobs wherever the task can complete within a bounded session.
- Separate bootstrap trust from downstream access Treat secret zero as a distinct trust anchor with tighter issuance controls, narrower scope, and stronger monitoring than ordinary runtime secrets.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step recommendations for handling API keys, tokens, passwords, and certificates across DevOps workflows
- Specific product and platform comparisons across on-prem, SaaS, cloud-native, and independent secrets tools
- Implementation detail for dynamic secrets, automated rotation, and just-in-time access in hybrid estates
- Practical guidance on integrations with Kubernetes, Jenkins, Terraform, Ansible, GitHub Actions, and Azure DevOps
👉 Read Akeyless' analysis of DevOps secrets management and secret sprawl →
Secret sprawl in DevOps: what IAM teams need to fix now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:49 pm
Secret sprawl is not a storage problem. It is an identity governance failure. The article describes credentials spread across pipelines, containers, cloud services, and human workflows, which means no single control point owns the lifecycle. That pattern breaks visibility, revocation, and accountability at the same time. The practical conclusion is that NHI governance must treat every reusable credential as an identity asset with lifecycle responsibility.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable when an exposed DevOps secret leads to unauthorised access?
A: Accountability sits with the teams that own the credential lifecycle, the systems that stored or distributed the secret, and the process that failed to revoke it in time. Frameworks like OWASP NHI and NIST CSF both point to ownership, visibility, and control enforcement as governance duties.
👉 Read our full editorial: DevOps secrets management is breaking under secret sprawl
