Notifications
Clear all
Topic starter
17/08/2026 4:39 pm
TL;DR: Cloud-native secrets management is increasingly about automating the full lifecycle of API keys, tokens, certificates, and passwords across CI/CD, Kubernetes, and multi-cloud environments, according to Akeyless. The bigger issue is not storage alone but whether identity, rotation, and revocation are governed tightly enough to prevent secrets sprawl and standing-access drift.
NHIMG editorial — based on content published by Akeyless: Cloud-native secrets management and the limits of legacy vault models
By the numbers:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions 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.
Q: Why do static credentials create more risk in CI/CD and Kubernetes environments?
A: Static credentials are copied into many places, reused by many systems, and difficult to revoke cleanly once they spread.
Q: What do security teams get wrong about secret rotation?
A: They often treat rotation as a substitute for removing the underlying credential model.
Practitioner guidance
- Map every secret to a consuming identity Create an inventory that ties each API key, token, certificate, and password to the workload, pipeline, or service account that actually uses it.
- Replace reusable credentials with short-lived issuance Prioritise dynamic credentials for databases, cloud resources, and APIs where the access pattern supports ephemeral use.
- Bind secrets to workload identity Require verified workload identity before issuing credentials so that a stolen secret cannot be replayed outside its intended context.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- Implementation-oriented walkthroughs for cloud-native secrets workflows across AWS, Azure, GCP, Kubernetes, and on-premises systems
- Feature-level comparison details for multi-cloud deployment, secretless access, and dynamic secrets patterns in production environments
- Compliance and architecture specifics for regulated sectors that need to map secrets controls to their own control frameworks
- Practical examples of how the platform integrates with CI/CD and infrastructure-as-code pipelines
👉 Read Akeyless' analysis of cloud-native secrets management for multi-cloud environments →
Cloud-native secrets management: are legacy vault models keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:45 pm
Cloud-native secrets management has become an identity problem, not a storage problem. The article correctly frames secrets as credentials that power services, but the deeper issue is who or what is authorised to use them across CI/CD, Kubernetes, and multi-cloud runtime paths. Once a secret is embedded in an application workflow, the control challenge shifts from safekeeping to lifecycle governance, revocation, and access scope. Practitioners should treat secrets inventory as part of identity governance, not as a standalone vault exercise.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: How do organisations know whether secrets management is actually working?
A: Look for fewer exposed duplicates, faster revocation after discovery, and clear ownership for every credential. If secrets still appear in multiple locations or remain active after offboarding, the programme is producing alerts without reducing attack surface. The goal is measurable reduction in standing exposure, not just more findings.
👉 Read our full editorial: Cloud-native secrets management and the limits of legacy vault models
