Secrets sprawl exposes the visibility gap IAM tools miss

At a glance

What this is: This session explains why secrets sprawl persists and where unmanaged credentials most often end up, creating visibility gaps that standard identity and audit controls miss.

Why it matters: It matters because IAM, PAM, NHI, and DevOps teams need the same credential visibility if they want to govern access without slowing delivery or leaving unmanaged secrets behind.

By the numbers:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read 1Password's session on solving secrets sprawl and developer credential visibility

Context

Secrets sprawl is the accumulation of API keys, SSH keys, tokens, and certificates in places that teams do not govern consistently. Once credentials are hardcoded into application code, embedded in CI/CD pipelines, or pasted into shared documents and chat tools, they escape the normal lifecycle controls that IAM and audit programmes rely on.

For identity teams, the issue is not only exposure but ownership. If a secret is created, copied, shared, and forgotten across developer workflows, then access governance has no reliable inventory, no clean offboarding path, and no practical way to prove where that credential exists at any given moment. That is why secrets sprawl becomes an NHI problem as much as a DevOps one.

Key questions

Q: How should security teams stop secrets from spreading across code, chats, and pipelines?

A: Security teams should treat secrets as governed identities, not as static text strings. That means scanning code, CI/CD systems, collaboration tools, and tickets for exposure, assigning ownership to each secret, and making revocation part of the incident workflow. The key control is reducing the number of unmanaged copy paths that let one credential multiply across the environment.

Q: Why do hardcoded secrets remain a risk after detection tools find them?

A: Detection does not remove access. A leaked secret can stay valid in scripts, clones, caches, or downstream systems long after the original finding is closed. The risk remains until the credential is revoked everywhere it was copied, which is why lifecycle control matters more than alerting alone.

Q: What do teams get wrong about secrets in private repositories?

A: They assume private repositories are safe compartments. In reality, secrets move through developer workflows, build systems, and collaboration tools, so repository visibility does not equal credential safety. Teams need governance across the delivery chain, not just controls on where code is stored.

Q: What should organisations do when a secret is found in a pipeline?

A: They should invalidate the credential, review the pipeline account that used it, and check for other copies in logs, artifacts, and environment variables before the old value can be reused. If the secret still works anywhere, the exposure is still active.

Background and context

Why secrets sprawl defeats visibility-first controls

Secrets sprawl breaks the assumption that identity teams can govern credentials by watching central directories, logs, or approved vaults. A secret can appear in source code, a pipeline variable, a document, or a chat message, and each location creates a separate exposure path. The problem is not just storage but uncontrolled replication. Once a credential is copied into multiple workflow surfaces, standard audit tooling can confirm use after the fact, but it cannot reliably tell teams where every copy lives or whether each copy is still valid.

Practical implication: inventory must extend beyond vaults into code, collaboration tools, and build systems.

How CI/CD pipelines become secret distribution systems

CI/CD pipelines often combine broad automation with high trust and wide token reuse, which makes them efficient secret amplifiers. Build agents, environment variables, artifacts, and logs can all expose credentials if teams treat the pipeline as a harmless transport layer rather than an identity surface. This is why pipeline exposure is structurally different from a simple misfiled password. The pipeline can move a secret from one system to many, quickly and invisibly, while leaving only partial traces in logs that were never designed to act as a lifecycle control.

Practical implication: treat pipeline accounts, variables, and runner access as governed identities, not just engineering plumbing.

Why rotation without revocation still leaves exploitable secrets

Rotation only helps when the old secret is actually revoked everywhere it was copied. In practice, many credentials remain valid in caches, clones, scripts, messages, and embedded config files long after the team believes they have been replaced. That creates a long tail of exposure where detection may find the leak, but the credential remains usable. For NHI governance, this is the core lifecycle failure: discovery without invalidation does not restore control, because an exposed secret is still an active identity until the system proves otherwise.

Practical implication: pair secret detection with revocation workflows that remove access, not just replace values.

NHI Mgmt Group analysis

Secrets sprawl is not a storage problem, it is a lifecycle failure. The central issue is that credentials now exist in too many places for conventional IAM inventories to see them as a single governed asset. Once a secret is pasted into code, chat, or pipelines, ownership fragments and offboarding becomes partial. The practitioner conclusion is simple: if the lifecycle is not visible, the identity is not governed.

Secret sprawl creates identity blast radius. A single leaked key can unlock more systems than the original application was meant to reach, especially when developers reuse tokens across environments or automation layers. That blast radius is what makes unmanaged secrets more dangerous than ordinary configuration drift. The practitioner conclusion is that teams must measure where a secret can travel, not just where it was first created.

Validation without revocation is governance theatre. The article's problem statement shows why detection-only programmes keep failing: a credential can remain usable long after a tool flags it. GitGuardian's research that 64% of valid secrets leaked in 2022 are still exploitable today demonstrates the gap between awareness and control. The practitioner conclusion is to treat revocation as the real control objective, not leak detection alone.

Private repositories are not safe compartments. The assumption that internal code stores are inherently lower risk is contradicted by the volume of secrets still appearing in private development environments. Secrets move with developers, bots, and build systems, so the trust boundary is the workflow, not the repository label. The practitioner conclusion is to govern secrets across the delivery chain, not by repository visibility alone.

Policy has to follow the developer path, not sit above it. Teams that block developers lose adoption, but teams that ignore developer workflow lose control. The practical pattern is to combine centralized visibility with low-friction storage, sharing, and provisioning so the governed path is the easiest path. The practitioner conclusion is that secrets governance succeeds only when it is usable inside the delivery process.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories and are 13% more likely to be categorised as critical than code-based leaks.
• That is why the Guide to the Secret Sprawl Challenge is the natural next resource for teams building detection and revocation workflows.

What this signals

Secret sprawl is becoming a workflow problem, not a repository problem. As developer tooling spreads credentials across code, chat, tickets, and pipelines, the security team needs visibility that matches how work actually happens. The programme implication is that inventory, ownership, and revocation need to move upstream into the delivery chain, not remain stuck in periodic review cycles.

Identity programmes need to treat secrets as living credentials with a short enforcement half-life. A secret that is still valid after exposure is an active governance failure, not a historical incident. The practical signal for practitioners is whether they can invalidate credentials automatically enough to make exposure non-exploitable before the next deployment or handoff.

Internal tooling should reduce copy-and-paste identity behaviour. The more often engineers have to move credentials between systems manually, the more likely they are to create hidden exposures. Teams that want better outcomes should make the secure path easier than the ad hoc one, which means stronger workflow integration and less credential duplication.

For practitioners

• Extend secret discovery beyond repositories. Scan code, CI/CD variables, build logs, shared documents, ticketing systems, and chat platforms because the highest-risk secrets often live outside source control. Map each location to an owner and a revocation path so discovery produces action, not just alert volume.
• Make revocation part of the response flow. When a secret is detected, invalidate the credential, rotate any dependent values, and verify that downstream systems no longer accept the old token. A finding is not closed until the exposed secret is demonstrably unusable.
• Treat pipelines as governed identities. Assign ownership to build runners, service accounts, and deployment tokens, then review their scopes, lifetimes, and reuse patterns as part of access governance. The control gap is not the pipeline itself but the assumption that automation does not need lifecycle management.
• Reduce copy paths for developers. Provide a secure central place for storing, sharing, and provisioning credentials so teams do not need to paste secrets into ad hoc tools. The goal is to remove unmanaged copy points without adding workflow friction.

Key takeaways

• Secrets sprawl is a lifecycle problem because unmanaged credentials spread across code, pipelines, and collaboration tools faster than identity teams can see them.
• The scale is already material, with leaked secrets often remaining valid long after detection, which means exposure can persist unless revocation is automated.
• Practitioners should move governance into the delivery chain by extending discovery, ownership, and invalidation to every place a secret can be copied.

Key terms

• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials such as API keys, tokens, SSH keys, and certificates across code, pipelines, documents, and chat tools. It becomes a governance problem when no team can confidently inventory, revoke, or prove ownership of every copy.
• Credential revocation: Credential revocation is the process of making an exposed or no-longer-needed secret unusable everywhere it can authenticate. In practice, it must reach all copies and dependent systems, not just the original secret value, or the exposure remains active.
• Identity blast radius: Identity blast radius is the amount of access a single credential can unlock if it is stolen or leaked. It reflects scope, reuse, and propagation across systems, which is why a small secret can create a disproportionately large security incident.
• CI/CD pipeline identity: CI/CD pipeline identity is the collection of service accounts, tokens, variables, and runner permissions that let automation build, test, and deploy software. It is a governed identity surface because any exposed secret in the pipeline can be copied, reused, or embedded downstream.

What to expect at the briefing

1Password's full session covers the operational detail this post intentionally leaves for the source:

• Where secrets most commonly end up in developer and IT workflows, including the specific places teams miss when inventorying exposure.
• How 1Password Developer Tools centralise storage, sharing, and provisioning for teams that need governed access without ad hoc copying.
• What IT gains from policy controls and automated provisioning and deprovisioning at the workflow level.
• How developers can keep working quickly while reducing the number of unmanaged credential handoffs.

👉 The full 1Password session covers the visibility gaps, policy controls, and provisioning workflow in more detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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 lifecycle governance in your organisation, it is worth exploring.