Secrets management failures are still driving breach and outage risk

At a glance

What this is: This guide argues that secrets sprawl is now a governance problem, not just a hygiene issue, because leaked credentials can create both breach exposure and service disruption.

Why it matters: It matters because IAM, NHI, and PAM teams need one operating model for hardcoded secrets, workload credentials, and access lifecycle controls before exposure turns into lateral movement or outage.

By the numbers:

• Stolen credentials were involved in 88% of basic web application attacks and appeared in roughly one-third of all confirmed breaches.
• Hardcoded secrets on GitHub roughly doubled in 2025 and more than 90% of those secrets remained valid and exploitable five days after disclosure.
• The amount of hardcoded secrets on GitHub alone roughly doubled in 2025.

👉 Read Infisical's guide to protecting API keys, credentials, and certificates

Context

Secrets management is the discipline of storing, issuing, rotating, and logging credentials so they are available when systems need them but not available everywhere else. The problem this article surfaces is that many teams still treat secrets as ad hoc configuration rather than governed identities, which leaves API keys, certificates, tokens, and cloud access material spread across code, chat, files, and pipelines.

That matters across NHI, IAM, and PAM because the same credential can become both an access-control failure and an operational dependency. Once a secret is reused, copied, or left in place too long, the organisation loses visibility into entitlement scope, revocation timing, and the true blast radius of compromise.

Key questions

Q: How should security teams handle leaked secrets in cloud and CI/CD environments?

A: Treat every leaked secret as a live identity problem, not just a code cleanup task. Revoke the credential, verify downstream propagation, rotate any dependent tokens, and check whether the secret had broader permissions than the workload actually needed. If you cannot prove the blast radius is contained, assume lateral movement is possible.

Q: Why do long-lived service credentials increase breach risk?

A: Long-lived credentials create standing privilege, which gives attackers time to find, reuse, and move through systems after a leak. The longer a secret stays valid, the more likely it is to survive code review, contractor turnover, and incident response delays. Short-lived credentials reduce the window in which exposure can be exploited.

Q: What do teams get wrong about secret rotation?

A: Many teams rotate secrets but leave the surrounding entitlement model unchanged. If the new credential still has broad access, the organisation has only changed the token value, not the risk. Rotation works best when it is paired with least privilege, audit logging, and validation that the old credential is truly unusable.

Q: How do identity teams know whether secrets management is actually working?

A: Look for fewer static credentials, faster revocation after exposure, clear ownership for each secret, and audit logs that show who or what accessed each value. If teams still rely on spreadsheets, shared .env files, or manual handoffs, the programme is not controlling secrets lifecycle risk yet.

Technical breakdown

Why secret sprawl breaks the control plane

Secret sprawl happens when credentials multiply faster than the organisation can inventory, classify, and govern them. At that point, the control plane is no longer the vault or the IAM policy set, but the informal sharing behaviour around plaintext files, CI variables, chat messages, and embedded configuration. A secret is not just a value; it is an entitlement with operational reach, often across cloud, code, and service boundaries. The technical failure is that discovery and lifecycle management lag behind issuance, so the organisation cannot reliably answer where a credential exists, who can use it, or whether it is still valid.

Practical implication: Map every credential class to an owner, an expiry rule, and a revocation path before it enters production.

Dynamic secrets versus static secrets in modern pipelines

Static credentials persist until someone rotates them, while dynamic secrets are minted on demand and expire after a short lease. That difference matters because a leaked static secret remains exploitable until the organisation notices and replaces it, whereas a dynamic secret sharply limits the useful window for an attacker. In pipeline-heavy environments, the goal is to remove long-lived secrets from build and deployment flows entirely, then use workload identity or short-lived tokens where possible. Overlapping validity windows matter too, because rotation that breaks production creates pressure to reintroduce insecure shortcuts.

Practical implication: Prefer short-lived credentials for build and runtime paths, and reserve static secrets only where no alternative exists.

Blast radius and lateral movement after a secret leak

A compromised secret exposes every system and action tied to that credential’s permissions, which is why blast radius is the central concept in secrets governance. If a token can read storage, invoke workloads, or mint additional credentials, a single leak can become a broader compromise through lateral movement. The article’s examples show that attackers do not need novel exploits when old credentials remain active. The technical issue is overprovisioning plus persistence: the credential is still trusted long after the business process that justified it has changed.

Practical implication: Constrain each secret to the narrowest possible scope and verify that no leaked credential can reach unrelated systems.

Threat narrative

Attacker objective: The attacker wants durable access to systems and data through credentials the organisation failed to revoke, scope, or contain.

1. Entry occurs when attackers find exposed API keys, OAuth grants, or cloud credentials in repositories, chat tools, or contractor handoffs.
2. Escalation follows when the leaked secret still has standing privileges and can reach infrastructure, storage, or additional credentials.
3. Impact is data theft, environment compromise, or operational disruption once the credential’s blast radius is exercised at scale.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret sprawl is no longer a secrets hygiene issue, it is an identity governance failure. Once credentials are scattered across code, chat, contractors, and cloud services, no team can reliably prove ownership, scope, or revocation state. That is an NHI control problem because every secret behaves like an identity with a lifecycle, not like inert configuration. Practitioners should treat credential inventory and entitlement tracking as part of identity governance, not an adjacent DevOps task.

Ephemeral credential trust debt is the new governance burden. Dynamic secrets reduce exposure time, but they also make teams dependent on precise lease handling, renewal logic, and service integration. The organisation is borrowing trust from a short window of validity, and every exception that reintroduces static credentials creates debt that compounds in audits, outages, and incident response. Practitioners should measure where static credentials remain the default rather than the exception.

Standing privilege is the real failure mode behind many secret leaks. Leaked credentials become breaches when the original entitlement remains broad, reusable, and valid long after issuance. That is why blast radius, not just detection speed, determines whether an exposure becomes an incident. Practitioners should re-evaluate whether any credential can still reach more systems than the workload that uses it actually needs.

Secrets management now sits at the intersection of NHI, PAM, and platform engineering. The governance model must cover issuance, storage, use, review, and offboarding for service accounts, workload identities, and human-shared access paths. When those functions are split across teams without a shared control model, the organisation gets both brittle operations and weak containment. Practitioners should align ownership before they align tooling.

Analyst concept: identity blast radius. The article reinforces a simple but important idea: every secret carries a potential reach profile, and that reach profile is what attackers exploit. Once teams understand credentials as identities with blast radius, they can stop treating leak prevention as the only goal and start governing the permissions that make a leak exploitable. Practitioners should design for containment, not just discovery.

From our research:

• Hardcoded secrets on GitHub roughly doubled in 2025 and more than 90% of those secrets remained valid and exploitable five days after disclosure, according to The State of Secrets Sprawl 2026.
• GitGuardian also found: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly new AI-connected surfaces become credential leakage points.
• For the broader control picture: Use 52 NHI Breaches Analysis to compare how leaked secrets translate into real compromise patterns across identity lifecycles.

What this signals

Identity teams should expect secrets management to be judged as an access-control capability, not a vaulting feature. The programme that wins here is the one that can prove ownership, propagation, revocation, and auditability across workloads and human workflows. That means platform engineering, IAM, and security operations need shared control boundaries rather than separate spreadsheets and assumptions.

Secret sprawl will increasingly surface as a lifecycle problem across service accounts and human handoffs. The practical risk is not just exposure but stale access that survives role changes, contractor exits, and pipeline refactors. Teams that cannot tie each secret to a current business owner will keep carrying dormant risk into audits and incidents.

Dynamic secrets create a measurable governance edge only when the surrounding identity model is mature. If the organisation still relies on ad hoc sharing, the lease model just hides the weakness for a shorter time. The next phase for mature programmes is tighter linkage between workload identity, PAM, and secrets lifecycle evidence, using resources like the Top 10 NHI Issues as a checklist for where blind spots persist.

For practitioners

• Inventory every secret class Build a single inventory for API keys, tokens, certificates, cloud access keys, and signing material. Assign an owner, expiry rule, and revocation path to each credential so you can answer who can use it and where it is valid.
• Replace static secrets with short-lived credentials Use workload identity or dynamic secrets wherever the platform supports them, especially for CI/CD jobs and service-to-service access. Keep static credentials only where a technical dependency prevents elimination, then time-box and monitor them aggressively.
• Reduce blast radius through least privilege Give each workload only the specific secret scope it requires, and separate production from development and staging. Recheck whether any token can read unrelated systems, mint new credentials, or access higher-risk environments.
• Automate rotation and revocation checks Tie rotation events to validation that the replacement secret has propagated before the old one is invalidated. Then verify that leaked or stale credentials are not still valid in downstream systems or contractor handoffs.
• Track secret usage with audit evidence Log each read, write, rotation, and revoke event with the workload identity, source, and secret path. Use those logs to prove access history during audits and to reconstruct exposure after a leak.

Key takeaways

• Secret sprawl is an identity governance problem because each credential carries ownership, scope, and revocation obligations.
• Exposure becomes a breach when standing privilege remains valid long enough for attackers to reuse it.
• The practical control objective is containment through inventory, least privilege, rotation, and audit evidence.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, chat, pipelines, devices, and environments. It becomes a governance problem when no team can reliably inventory what exists, who can use it, or how quickly it can be revoked after exposure.
• Blast Radius: Blast radius is the amount of access, data, and action an attacker gains from a single compromised credential. In identity security, it is the practical measure of how badly one leaked secret can hurt the organisation, especially when permissions are broad or long-lived.
• Dynamic Secret: A dynamic secret is a credential created on demand and issued for a short lease rather than stored indefinitely. It reduces the usefulness of a leak by shrinking the time window in which an attacker can reuse the credential, but it still requires lifecycle control and auditability.
• Workload Identity: Workload identity is the method of proving a service, job, or application is allowed to access resources without embedding a reusable secret. It shifts trust from static tokens to verifiable runtime identity, which is usually easier to govern and revoke at scale.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Concrete rotation patterns for database, cloud, API, and certificate secrets across development and production.
• Implementation detail for vault-backed workflows, including access policies, lease handling, and audit logging.
• Product-specific guidance on CI/CD integrations, secrets scanning, and developer handoff flows.
• Decision criteria for when to use dynamic secrets, workload identity, or short-lived tokens in practice.

👉 The full Infisical post covers vault architecture, rotation patterns, and secrets management best practices in depth.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.