CI/CD pipelines as the control point for secrets sprawl

At a glance

What this is: This is an analysis of why CI/CD pipelines are the highest-leverage place to tackle secrets sprawl and long-lived credential exposure.

Why it matters: It matters because CI/CD is where machine access, production deployment, and shared engineering trust intersect, so controls here influence NHI, autonomous, and human identity programmes alike.

By the numbers:

• The number of leaked secrets increased by 23 million (+25%) from 2023 to 2024.

👉 Read Defakto Security's analysis of CI/CD pipelines and secrets sprawl

Context

Secrets sprawl is the condition where credentials, tokens, and passwords accumulate faster than teams can inventory, rotate, or revoke them. In CI/CD environments, that problem becomes architectural because pipelines sit at the point where code becomes deployed infrastructure and where access is routinely shared across teams, tools, and environments.

The article argues that starting with CI/CD gives security teams the highest leverage because it is the access gateway to production and a natural integration point for identity-first infrastructure. That makes the topic directly relevant to NHI governance, because the same pipeline patterns that expose secrets also shape how machine identities are issued, used, and retired.

For teams working through this problem, the useful lens is not simply secret storage but control over the place where trust is first operationalised. NHIMG's Guide to the Secret Sprawl Challenge is a useful companion for understanding how leakage, detection, and remediation fit together.

Key questions

Q: How should security teams reduce secrets sprawl in CI/CD pipelines?

A: Start by mapping where pipeline credentials are created, copied, and reused, then remove the ones that exist only because the workflow was designed around static secrets. The most effective shift is to replace long-lived credentials with short-lived identity, because storage and rotation alone do not eliminate exposure.

Q: Why do CI/CD pipelines create such a large secrets risk?

A: CI/CD pipelines sit at the gateway to production, so they naturally hold the credentials needed to deploy, configure, and connect systems. When many teams depend on the same pipeline estate, one exposed secret can create broad access and a large blast radius.

Q: What do security teams get wrong about secrets managers?

A: They often treat a secrets manager as a complete fix when it is really a containment layer. It can centralise storage and improve handling, but if workloads still authenticate with long-lived secrets, the underlying risk remains and sprawl often shifts rather than disappears.

Q: What should organisations do first when a CI/CD environment relies on static credentials?

A: Prioritise the production-facing steps first, because those credentials have the highest operational reach and the greatest breach impact. Then work outward to less sensitive stages, replacing static access with runtime identity where the access path is repeated or shared across teams.

Technical breakdown

Why CI/CD becomes the highest-value secret concentration point

CI/CD systems need credentials to fetch code, provision infrastructure, deploy applications, and reach cloud APIs. That makes them a natural aggregation point for API keys, passwords, and tokens. Because multiple delivery teams often depend on the same pipeline estate, one exposed credential can create broad operational reach. The core risk is not just storage in one place, but repeated reuse across build, test, deploy, and configuration steps.

Practical implication: map every pipeline credential to the production action it enables, then remove any secret that is not tightly bound to a single deployment purpose.

Why secrets managers reduce exposure but do not remove the dependency

Secrets managers centralise storage and make discovery easier, but they do not eliminate the underlying need for a secret if the workload still authenticates with one. That means the organisation still carries leakage risk, rotation overhead, and blast-radius concerns. If teams copy secrets into multiple pipeline layers or localised vaults, the manager itself can become another sprawl layer rather than a control point.

Practical implication: treat secrets managers as containment infrastructure, not as a substitute for identity-first authentication or credential elimination.

How identity-first infrastructure changes pipeline trust

Identity-first infrastructure replaces long-lived shared secrets with dynamically attested identities and short-lived credentials. In practice, each pipeline, action, or workload proves who it is at runtime and receives only the access needed for that session or task. That shifts control from secret custody to runtime authentication, which is more compatible with automated delivery and easier to govern centrally.

Practical implication: prioritise workload identity and short-lived credentials for the specific pipeline stages that currently rely on static secrets.

Threat narrative

Attacker objective: The objective is to gain durable control over production-connected systems by abusing the trust boundary inside the delivery pipeline.

1. Entry occurs when a CI/CD pipeline stores or reuses API keys and passwords that can be exposed through code, logs, build artefacts, or misconfigured integrations.
2. Escalation happens when a compromised pipeline credential can access cloud APIs, infrastructure configuration, or deployment systems with broader reach than the original use case intended.
3. Impact follows when attackers or insiders use that access to modify production infrastructure, steal additional secrets, or push malicious changes into downstream systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

CI/CD is not just a delivery system, it is the control plane where secret sprawl becomes operational policy. The article is right to frame pipelines as a strategic control point because they concentrate the credentials that make production access possible. That concentration is why pipeline governance has outsize influence over the rest of the engineering estate, including machine identities and shared service access. Practitioners should treat pipeline access as an identity architecture decision, not a tooling detail.

Secret managers contain exposure, but they preserve the wrong operating assumption. They assume credentials will remain the normal way systems authenticate, only with better storage and rotation. That assumption fails when the environment scales across many teams and services because the number of secret touchpoints grows faster than the control model. The implication is that teams need to stop measuring success by how many secrets are stored and start measuring how much secret dependence has been removed.

Identity-first infrastructure creates a more governable trust model for CI/CD than static credential reuse. Dynamic attestation ties access to runtime identity instead of copied values that live beyond their intended use. That aligns better with NHI governance because the credential is no longer the thing to protect, but the runtime proof of identity is. Practitioners should see this as a shift from secret custody to access design.

Secrets sprawl is a lifecycle failure as much as a technical one. Credentials that are created for one pipeline phase often survive long after the need for them has ended, especially when ownership is split across platform and application teams. The result is an identity estate where access persists by habit, not by necessity. That means lifecycle governance, not just secret inventory, determines how quickly exposure can be reduced.

Guide to the Secret Sprawl Challenge: This article points to a broader control pattern where secret discovery, concentration, and remediation have to be managed together rather than as separate tasks. In NHIMG terms, the field needs to think in terms of identity blast radius, not just leak detection. The practitioner conclusion is straightforward: the more central the pipeline, the more urgent it becomes to remove long-lived credentials from it.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• GitGuardian also reported 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
• If you are working through the architectural side of this problem, Guide to the Secret Sprawl Challenge helps connect discovery, containment, and removal into one control model.

What this signals

The programme signal here is that teams cannot keep treating CI/CD as a downstream engineering concern. As pipeline access becomes the practical entry point for production, identity teams need to align secrets governance, workload identity, and access lifecycle review around the same control surface.

Identity blast radius: when a single pipeline credential can affect multiple teams and environments, the real risk is not one leaked secret but the number of systems it can still reach. That is why secret reduction work should be prioritised where privilege concentration is highest, not where inventory is easiest.

NHIMG's wider research on secrets sprawl shows that organisations often underinvest in the control points where leakage is easiest to exploit. The practical lesson is to move from periodic cleanup to continuous elimination of static credentials, especially in delivery pipelines that already shape how the rest of the estate authenticates.

For practitioners

• Inventory pipeline-exposed credentials Map every API key, password, and token used by CI/CD systems to the exact deployment step, owner, and downstream system it enables. Remove any credential that does not have a clear runtime purpose.
• Replace shared secrets with workload identity Move build and deployment steps to short-lived, attested identities so the pipeline authenticates without copying long-lived credentials into repositories, runners, or environment files.
• Consolidate pipeline governance centrally Use the CI/CD platform as a single enforcement point for secret discovery, rotation policy, and access review so multiple engineering teams inherit the same control baseline.
• Phase out static secret dependencies by stage Prioritise the pipeline stages that touch production APIs first, then work backwards through build, test, and release steps to eliminate static credential reuse where it is least justified.

Key takeaways

• CI/CD pipelines matter because they concentrate the credentials that make production access possible, so secrets governance here has disproportionate security impact.
• The persistence of leaked secrets shows that detection and storage are insufficient on their own, because exposed credentials often remain exploitable long after discovery.
• The best long-term response is to reduce static secret dependence by shifting pipeline authentication toward short-lived identity and centrally governed lifecycle controls.

Key terms

• Secrets Sprawl: The uncontrolled spread of credentials across code, pipelines, tools, and teams. It creates hidden attack paths because secrets are duplicated, reused, and forgotten faster than security teams can inventory or revoke them.
• Identity-First Infrastructure: An approach that replaces long-lived shared secrets with runtime identity and short-lived credentials. For CI/CD, it means systems authenticate through attested identity instead of copied values that can leak, linger, or be reused outside their intended purpose.
• Workload Identity: A machine identity used by software, pipelines, or services to authenticate to other systems without relying on static secrets. In delivery environments, it gives each workload a narrower and more auditable trust relationship than shared credentials do.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Defakto Security: CI/CD Want Control Over Secrets? Start with Your Strategic Control Point: CI/CD. Read the original.