How can teams reduce secret sprawl in cloud workloads?

Why This Matters for Security Teams

Secret sprawl is rarely just a storage problem. It is a control failure that turns every build server, container image, function, and sidecar into a potential credential depot. Once secrets are copied into code, pipelines, logs, and environment variables, revocation becomes slow, ownership becomes unclear, and offboarding depends on perfect cleanup. That is why guidance increasingly shifts toward workload identity and runtime authorization, as reflected in the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge.

NHIMG’s 2024 Non-Human Identity Security Report found that 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, a signal that distribution paths are often easier to create than to govern. The practical risk is not only theft, but also persistence: the more places a secret exists, the more likely one copy survives rotation, rollback, or incident response. In practice, many security teams discover secret sprawl only after a pipeline compromise or leaked repository has already exposed multiple downstream systems.

How It Works in Practice

Reducing secret sprawl starts by removing the need for long-lived shared credentials. Instead of issuing a static API key to every workload, teams should make each workload prove what it is at runtime and receive only the access it needs for that task. The strongest pattern is workload identity backed by short-lived credentials, as described in the SPIFFE workload identity specification and NHIMG’s Guide to SPIFFE and SPIRE.

Operationally, this means three things:

• Delete default credential distribution paths such as baked-in secrets, shared config files, and pipeline variables.
• Issue ephemeral tokens per workload or per session, with automatic expiration and revocation on task completion.
• Evaluate access at request time using policy rather than relying on pre-issued entitlements alone.

That approach reduces both exposure and cleanup burden because a compromised workload has less value outside its narrow context. It also improves auditability, since each access decision can be tied to an authenticated workload identity rather than an opaque shared secret. Current best practice is evolving toward dynamic secret and runtime attestation, but there is no universal standard for every cloud pattern yet; teams still need to align the mechanism with the workload type, such as containers, serverless functions, or CI/CD runners. NHIMG’s CI/CD pipeline exploitation case study shows why pipeline-held secrets are especially dangerous when build systems can touch many downstream targets. These controls tend to break down when legacy applications require persistent connection strings because the application architecture itself expects long-lived shared credentials.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance reduced exposure against deployment friction and legacy compatibility. That tradeoff is most visible in hybrid estates, where some services can adopt workload identity quickly while others still depend on static credentials, certificates, or embedded connection strings.

In those environments, the right answer is usually not a blanket ban without transition planning. Teams may need to segment by risk: remove secrets first from CI/CD, then from ephemeral compute, then from long-lived application services. Where static secret remain unavoidable, best practice is to minimise blast radius with scoped permissions, aggressive rotation, and ownership tied to a named system rather than a team inbox. The industry has not fully converged on one implementation model for every platform, so current guidance suggests prioritising runtime identity and short TTLs where integration support exists, then phasing out remaining secrets on a defined retirement schedule. Secret sprawl is hardest to control in environments with unmanaged scripts, shared admin tooling, and multi-cloud duplication because each additional platform introduces another place for credentials to be copied, cached, or forgotten.

Related resources from NHI Mgmt Group

• What do teams get wrong about securing AI workloads in the cloud?
• How should teams secure cloud workloads without overloading operations?
• How can teams reduce the blast radius of a leaked repository secret?
• How should teams secure non-human identities across cloud and SaaS?