Why do CI/CD pipelines increase lateral movement risk?

Why This Matters for Security Teams

CI/CD pipelines are not just delivery automation. They are privileged execution environments that can authenticate to source control, package registries, cloud APIs, and production systems in one run. That makes them attractive for attackers seeking a fast path from a single foothold to multiple downstream assets. The CI/CD pipeline exploitation case study shows why this matters in practice: once a pipeline runner or its secrets are compromised, lateral movement can happen across build, test, and deployment boundaries with very little friction. NIST’s NIST Cybersecurity Framework 2.0 still points teams toward least privilege and continuous risk management, but pipelines often violate both when credentials are reused or over-scoped. GitGuardian’s State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which underlines how attractive these systems have become. In practice, many security teams discover pipeline lateral movement only after a deployment token has already been abused, rather than through intentional detection design.

How It Works in Practice

Pipelines increase lateral movement risk because they collapse multiple trust boundaries into a single automation path. A runner may be trusted to fetch code, build artifacts, sign packages, push images, and deploy to production. If one of those permissions is granted with broad RBAC, the attacker can pivot from one service to the next without needing a new identity challenge at each step. The core problem is not only secret storage, but secret reach. A token that can read a repository, push to a registry, and call a cloud control plane gives an intruder several places to move once execution is achieved. Operationally, the safer pattern is to reduce standing access and issue narrowly scoped, short-lived credentials only when a job needs them. That is where JIT credential provisioning, workload identity, and runtime policy checks matter. Rather than placing long-lived API keys on the runner, teams should bind the job to a workload identity and exchange that identity for ephemeral access that expires after the task completes. Current guidance suggests pairing this with intent-based authorisation so the policy engine evaluates what the pipeline is trying to do, not just whether the runner is “trusted.” The Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack both show how quickly secrets leak once automation has access to too much. A practical control set looks like this:

• Issue one-time or short-lived secrets per job, not shared across environments.
• Use workload identity for runners, then exchange that identity for scoped access tokens.
• Separate build, test, and deploy permissions so compromise of one stage does not unlock the rest.
• Log secret retrieval, token exchange, and deployment actions as distinct events.

These controls tend to break down in legacy pipelines that depend on static service accounts and shared deployment keys because there is no clean place to enforce per-job identity.

Common Variations and Edge Cases

Tighter pipeline access often increases build complexity and operational overhead, requiring organisations to balance security gain against developer friction and release speed. There is no universal standard for this yet, but the direction is clear: static credentials and broad runner permissions are the most common cause of lateral movement, while ephemeral access and policy-as-code reduce blast radius. For highly automated environments, the question is less “can the pipeline authenticate?” and more “can it prove the exact task, target, and scope at runtime?” Some exceptions deserve attention. Self-hosted runners often carry higher risk than managed runners because they may sit closer to internal networks, reuse local state, or inherit broader cloud trust. Monorepos and shared build templates can also spread one bad secret pattern across many services. And in release systems with manual approvals, a weak approval gate does not compensate for over-privileged automation behind it. NIST AI RMF is relevant where pipeline behaviour is partially driven by AI-assisted code generation or autonomous agents, but for ordinary delivery pipelines, the best practice is still to minimise standing privilege and rotate secrets aggressively. NHI-focused guidance from Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks is especially useful when pipelines are one credential source among many. The failure mode is clearest in self-hosted runners that keep cached secrets or inherit broad cloud roles, because a single compromise can cascade across multiple environments.

Related resources from NHI Mgmt Group

• Why do service accounts increase lateral movement risk in enterprise environments?
• Why do stale non-human identities increase lateral movement risk?
• Why do SSO environments increase the risk of lateral movement?
• Why does unconstrained delegation increase the risk of lateral movement?