Notifications
Clear all
Topic starter
25/06/2026 2:51 pm
TL;DR: Hard-coded keys, long-lived credentials, and scattered vaults create brittle delivery pipelines and persistent attack vectors, according to Aembit’s analysis. The real shift is from treating secrets as stored assets to treating access as an identity problem, where ephemeral, policy-based credentials reduce both rework and exposure.
NHIMG editorial — based on content published by Aembit: Secrets sprawl is becoming an identity problem for DevOps teams
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams replace hard-coded secrets in CI/CD pipelines?
A: Security teams should move CI/CD pipelines to workload identity and runtime attestation so the pipeline receives short-lived credentials only when needed.
Q: Why do long-lived service account keys create more risk than they solve?
A: Long-lived service account keys create standing access that survives beyond the workload, so one leak can enable repeated use, lateral movement, or delayed abuse.
Q: What do security teams get wrong about secrets scanners?
A: Teams often treat scanning as the control, when it is only detection.
Practitioner guidance
- Replace stored pipeline secrets with attested workload identity Use identity proof at runtime to issue short-lived credentials for CI/CD jobs, services, and agents.
- Map every bootstrap path to a secret zero dependency Inventory how each workload first reaches a vault, API, or database, then identify where the initial credential still exists as a permanent key, token, or password.
- Set expiry and scope as default controls for machine access Issue tokens that are narrow in scope, tied to one workload or agent context, and automatically expire after task completion.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of replacing stored CI/CD secrets with ephemeral workload credentials across common pipeline patterns
- Practical comparison points for when secrets management still has a role versus when identity-based access should take over
- Implementation details for attestation-based access in environments that span APIs, databases, and AI agent workloads
- The article's own examples of how teams can reduce credential archaeology without slowing delivery
👉 Read Aembit's analysis of secrets sprawl, workload identity, and AI agent access →
Secrets sprawl and ephemeral credentials: what IAM teams need to know?
Explore further
25/06/2026 4:02 pm
Static secrets are now a governance liability, not just a hygiene issue. Secrets sprawl turns authentication into an uncontrolled distribution problem across code, pipelines, and tools. That means the risk is not confined to one leaked key. It is the cumulative effect of many long-lived credentials that outlast the workloads they protect. For NHI programmes, the relevant control question is lifecycle visibility, not merely secure storage.
A few things that frame the scale:
- 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, according to the State of Secrets Sprawl 2026.
- Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do AI agents change secrets governance for IAM teams?
A: AI agents increase the number of identities that need access and the frequency with which credentials are used. That makes static secrets harder to govern because the same token may be exercised across many systems at machine speed. IAM teams should treat agents like workload identities, with scoped access and short lifetimes.
👉 Read our full editorial: Secrets sprawl is becoming an identity problem for DevOps teams
