Secrets sprawl in multi-cloud environments widens credential risk

At a glance

What this is: Akeyless argues that secrets sprawl across multi-cloud and CI/CD environments leaves credentials exposed long enough to be stolen and reused.

Why it matters: IAM, PAM, and NHI teams need to treat secrets as governed runtime access objects, because unmanaged credential spread creates blind spots that defeat central policy.

By the numbers:

• More than one in three breaches over the last 10 years can be linked to stolen credentials.

👉 Read Akeyless's analysis of secrets sprawl and cloud secrets management

Context

Secrets management is the discipline of storing, governing, and auditing non-human credentials such as API keys, certificates, and database passwords. In multi-cloud and CI/CD-heavy environments, those credentials tend to spread beyond the places security teams expect, which turns inventory gaps into access risk.

The governance problem is not just where secrets are stored, but how long they remain valid and who can reuse them. Once secrets are embedded in scripts, configuration files, or per-cloud vaults, the control challenge becomes lifecycle management across fragmented environments rather than simple vaulting.

Key questions

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: Why do stolen credentials remain such an effective attack path?

A: Stolen credentials work because many systems still treat a successful login as enough evidence of legitimacy. Once an attacker has valid access, they inherit the subject’s trust context and can often blend in with normal activity. That makes credential theft far more efficient than direct exploitation in many environments.

Q: How do security teams know whether secret management is actually reducing risk?

A: Look for fewer reusable credentials, shorter credential lifetimes, and a lower number of systems that still depend on manually rotated secrets. If the environment still depends on stored tokens for routine workload access, the programme is managing exposure, not removing it.

Q: Should teams prioritise rotation or centralisation first?

A: Centralisation usually comes first because teams cannot govern what they cannot inventory. But rotation becomes the risk-reduction lever once secrets are visible, because long-lived credentials remain useful to attackers even inside a well-managed vault. The right sequence is discover, centralise, then shorten lifetime.

Technical breakdown

Secrets sprawl across multi-cloud and CI/CD pipelines

Secrets sprawl occurs when credentials are duplicated across cloud services, pipelines, scripts, and configuration files instead of being governed from one policy layer. In that model, each environment becomes a separate trust silo, so visibility, revocation, and auditing fracture as the estate grows. Cloud-native vaults can protect local storage, but they do not by themselves create consistent governance across providers. The result is that a credential may still exist in places where security teams are not looking, even when a central secrets tool is in place.

Practical implication: build a unified inventory of secrets locations before treating any vault as a complete control.

Why standing secrets increase exposure window

A standing secret is dangerous because it can be reused for as long as it remains valid, regardless of whether the original business need still exists. That creates an exposure window attackers can exploit with legitimate authentication, which is often easier than breaking into the environment directly. Time-limited access and automated expiry reduce the opportunity for reuse, but only if the credential lifecycle is enforced consistently across all environments. Static passwords, long-lived tokens, and manually rotated secrets all extend attacker dwell time.

Practical implication: shorten credential lifetime wherever the application and platform allow it.

Dynamic secrets and just-in-time access change the trust model

Dynamic secrets are generated on demand and expire after a defined time-to-live, which means the credential is tied to a specific task rather than a permanent identity state. Just-in-time access applies the same logic to human or service access by limiting when a secret can be used. Together, these controls reduce the usefulness of stolen credentials because the secret is either short-lived or no longer active when an attacker tries to replay it. This is a governance shift from storing secrets safely to making them disappear quickly after use.

Practical implication: prioritise dynamic issuance and time-bound access for credentials that support high-risk operations.

Threat narrative

Attacker objective: The attacker wants to use a valid but stolen secret to enter cloud or application environments without triggering obvious authentication alarms.

1. Entry typically begins when an attacker finds a legitimate secret in code, configuration, CI/CD variables, or another exposed storage location.
2. Credential reuse then allows access through normal authentication paths, which bypasses many perimeter controls because the login appears valid.
3. Escalation follows when the stolen credential reaches a broader cloud, data, or administrative scope than the original task required.
4. Impact comes from using that access to reach sensitive systems or data while the organisation still believes the secret is governed.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets sprawl is a governance failure, not just a storage problem: once credentials exist in code, CI/CD variables, config files, and per-cloud vaults, the organisation no longer has one control plane for non-human identity. Central policy can only govern what it can find, so discovery becomes the prerequisite for any meaningful lifecycle control. The practitioner conclusion is that inventory and governance must precede vault selection.

Standing credential exposure window is the real weakness here: a secret that remains valid for weeks or months gives attackers a legitimate path that is structurally hard to distinguish from normal use. This is why basic storage controls do not solve the problem on their own. The practitioner conclusion is that expiry, rotation, and issuance timing matter more than where the secret sits.

Dynamic secrets are a better fit for the modern NHI trust model: when credentials are created for a task and expire at the end of that task, the control objective shifts from protecting a static asset to managing a short-lived entitlement. That aligns more closely with OWASP-NHI and zero standing privilege thinking than with legacy vault-first approaches. The practitioner conclusion is that ephemeral credentials should be the default for high-risk machine access.

Cloud-native vault fragmentation creates islands of identity: when each provider manages secrets differently, the organisation inherits inconsistent policy enforcement, incomplete audit trails, and different failure modes for revocation. That makes multi-cloud secrets governance harder than single-cloud deployment, even when the tools are individually sound. The practitioner conclusion is to treat cross-cloud policy consistency as a design requirement, not an optimisation.

Identity blast radius should become the metric that matters: the key question is no longer how many secrets exist, but how far a stolen secret can travel before it expires or is revoked. That reframes secrets management as containment engineering, not credential storage. The practitioner conclusion is to measure how much damage a single credential can do across clouds, pipelines, and workloads.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius now defines secrets governance: the important question is how far a credential can travel before it expires or is revoked, not simply whether it is stored in a vault. That shifts programme design toward discovery, containment, and lifecycle control across every environment where secrets can hide.

Multi-cloud vault fragmentation creates control gaps: when each provider enforces its own secret model, policy consistency and audit completeness break down. Security teams should expect to manage cross-cloud governance explicitly rather than assuming local vaulting equals enterprise control.

For practitioners

• Centralise secrets discovery Map where secrets actually live across code repositories, CI/CD systems, configuration stores, cloud vaults, and runtime variables before changing tooling.
• Replace standing credentials with time-bound issuance Use short-lived secrets and just-in-time access for workloads and administrative tasks so a credential cannot be replayed for long after issuance.
• Enforce rotation and expiry policies Automate rotation for static passwords, API keys, and certificates, and set clear expiry thresholds for any credential that cannot be made dynamic.
• Unify policy across cloud silos Apply one governance layer for access control, audit logging, and revocation so each cloud vault does not become an isolated trust boundary.
• Scan for secrets outside approved managers Continuously search source code, build logs, configuration files, and CI/CD variables for credentials that have drifted outside governed storage.

Key takeaways

• Secrets management fails when credentials are allowed to sprawl across code, CI/CD, and multiple cloud environments without a single governance view.
• The article links more than one in three breaches over the last 10 years to stolen credentials, which underscores how often valid secrets become the attacker’s easiest route.
• The strongest control response is to centralise discovery, shorten credential lifetime, and reduce the blast radius of any secret that is reused or exposed.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• Specific comparisons between cloud-native managers, traditional vaulting, and SaaS-native managers for multi-environment deployments
• Tactical guidance on how to centralise policy while preserving developer usability in CI/CD-heavy workflows
• Operational considerations for automated rotation, dynamic secrets, and just-in-time access across multiple clouds
• Evaluation questions for deciding whether a secrets platform requires agents, custom scripts, or managed infrastructure

👉 The full Akeyless article covers centralised policy, time-bound access, and rotation strategies for multi-cloud secrets.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.