CI/CD pipeline compromise depends on secrets, privilege, and trust

At a glance

What this is: This is an analysis of how attackers compromise CI/CD pipelines, with the key finding that pipeline trust, credentials, and third-party execution create a broad blast radius.

Why it matters: IAM, NHI, and cloud security teams need to treat CI/CD as a privileged identity environment because pipeline credentials, tokens, and signing paths can be abused to reach production and downstream consumers.

Context

CI/CD pipelines are automation systems that build, test, and deploy software while holding unusually broad access across repositories, cloud environments, signing systems, and production workflows. That concentration of access makes them attractive to attackers because one compromise can expose both code and the credentials needed to move it.

The identity risk is not limited to human users. Service accounts, tokens, SSH keys, and deployment credentials often function as non-human identities inside the pipeline, so weak lifecycle control turns a software delivery workflow into a privileged access corridor. That is a typical enterprise pattern, not an edge case.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do privileged developer and pipeline identities increase supply chain risk?

A: Because they can write code, approve changes, publish artefacts, or trigger deployments with minimal friction. When those identities keep standing access, an attacker only needs one compromise to move from initial access to software distribution. Short-lived, task-scoped permissions reduce the blast radius and make abuse easier to detect.

Q: How can security teams tell if pipeline trust has become too broad?

A: The clearest sign is when one pipeline identity can read source code, deploy workloads, access secrets, and sign artifacts without separate approvals or boundaries. That means the pipeline is functioning as a universal trust anchor rather than a segmented automation system. Teams should look for shared credentials, inherited permissions, and direct links from build jobs to production actions.

Q: What should organisations do when a runner vulnerability is discovered in CI/CD pipelines?

A: Organisations should revoke exposed credentials, rotate any secrets that may have been reachable from the runner, isolate affected build environments, and review recent job activity for persistence or tampering. They should also patch or reimage runner infrastructure, validate release integrity, and expand review to other CI/CD systems that use similar runner patterns.

Technical breakdown

Why CI/CD pipelines become privileged trust zones

CI/CD environments are designed to authenticate continuously to repositories, runners, build hosts, cloud control planes, and signing services. That means the pipeline itself behaves like a high-trust automation fabric, not a simple development tool. When those systems share credentials or inherit broad permissions, the compromise of one component can unlock code, infrastructure, and release channels. The security issue is the concentration of trust, not just the presence of automation. In identity terms, the pipeline often operates as a cluster of non-human identities with inconsistent ownership and lifecycle controls. See the CI/CD Pipeline Identity Security Guide.

Practical implication: Treat the pipeline as a privileged identity domain and inventory every non-human credential it uses.

How credential theft turns into pipeline access

Attackers commonly target API keys, cloud credentials, service account tokens, SSH keys, and repository logins because these secrets let them authenticate as trusted pipeline components. If a secret is stored in code, config, logs, or a secret store with weak access boundaries, it can be reused to impersonate the pipeline or one of its jobs. Once inside, the attacker does not need to break normal authentication again. They are operating with the identity the pipeline already trusts, which is why rotation, scoping, and storage location matter together. Read Guide to the Secret Sprawl Challenge.

Practical implication: Move pipeline secrets out of code and into governed secret stores, then tighten token scope and rotation cadence.

How poisoned pipeline execution reaches production

Poisoned pipeline execution happens when an attacker can alter the code or scripts that a trusted pipeline runs, then let the automation execute the malicious change with legitimate permissions. That makes the pipeline itself the delivery mechanism for compromise. The same pattern can also touch third-party dependencies, where a trusted package or script becomes the injection point. This is why provenance, version pinning, and execution control matter: the attacker is not merely breaking in, they are hijacking the release path. See the CI/CD Security Guide.

Practical implication: Control what executes in build and release stages before you trust the output as deployable software.

Threat narrative

Attacker objective: The attacker wants to turn a trusted software delivery system into a channel for theft, persistence, and malicious software distribution.

1. Entry begins when attackers obtain a pipeline credential, dependency, or source-control foothold that lets them interact with trusted build systems.
2. Credential access follows when exposed tokens, service accounts, or repository logins are reused to authenticate directly into CI/CD components.
3. Escalation occurs when over-privileged pipeline identities let the attacker read code, change build logic, or access cloud and signing systems.
4. Impact lands as malicious releases, stolen secrets, downstream supply chain abuse, or persistent access across production and customer environments.

Breaches seen in the wild

• 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.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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

CI/CD is now an identity control plane as much as a delivery mechanism. The article is right to treat pipelines as valuable targets because they concentrate machine credentials, signing authority, and deployment reach in one workflow. That makes the governance problem one of identity scope, ownership, and revocation rather than software release speed. Practitioners should classify every pipeline credential as a managed non-human identity, not an implementation detail.

Standing privilege inside pipelines is the failure mode that turns routine exposure into systemic compromise. The article repeatedly shows that broad repository, cloud, and signing access magnify the damage of any single secret leak. That is the same control gap that breaks secret sprawl governance when teams keep reusable credentials in too many places and for too long. Practitioners should assume that broad pipeline access will be abused the moment one secret is harvested.

Third-party execution is the hidden governance boundary in CI/CD security. The article’s dependency and poisoned pipeline examples show that trust extends beyond first-party code into scripts, packages, and build steps that many teams do not review with the same rigor. That is why provenance and execution policy belong in the same conversation as access control. Practitioners should govern external code as a release-time identity risk, not only as a supply chain issue.

Pipeline credential lifecycle debt: long-lived secrets, broad permissions, and weak offboarding create a compound failure pattern that attackers exploit faster than most review cycles can respond. This is a named concept worth tracking because it explains why the compromise surface keeps reappearing even after individual tools are hardened. Security teams should look for this pattern wherever build automation depends on reusable credentials and inherited trust.

Zero Trust only helps CI/CD when it reaches the job boundary. The article’s Zero Trust tips matter because conditional access, just-in-time elevation, and software execution control reduce what a compromised pipeline can do after authentication. But the real governance shift is to stop assuming that authenticated automation is inherently trustworthy. Practitioners should validate identity at issuance time and constrain execution at run time.

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

CI/CD security is becoming a secret governance problem first. Most organisations still allow credentials to live outside governed secret managers, which means pipeline security fails at the point of issuance long before detection or response can help. The most durable programme shift is to treat build-time identity as a lifecycle problem, not a tooling problem. CI/CD pipeline identity security becomes the right next step when teams need to redesign trust at the pipeline boundary.

Pipeline blast radius is now defined by who can execute, not just who can log in. If build environments can run arbitrary scripts or dependencies with trusted permissions, the attack surface extends from secret theft into release-time abuse. That is why execution control, provenance checks, and environment isolation belong in the same governance conversation. Security teams should watch for any place where automation can cross from authenticated to authorised without a separate control gate.

For practitioners

• Map every CI/CD credential to an owner and expiry policy Inventory API keys, service account tokens, SSH keys, and cloud logins used by build and deployment systems, then assign ownership, rotation intervals, and revocation procedures for each one.
• Eliminate broad repository and cloud permissions Review whether pipeline identities can access more repositories, environments, or cloud resources than their job requires, then narrow scope to the minimum set of actions and targets.
• Move secrets out of code and config files Search for hardcoded credentials in repositories, build scripts, and configuration files, then replace them with centrally managed secrets and short-lived authentication where possible.
• Restrict what build jobs are allowed to execute Use application control and runner isolation so build environments only run approved tools, scripts, and packages, especially where third-party dependencies enter the pipeline.

Key takeaways

• CI/CD compromise is primarily a governance failure in how trusted automation, credentials, and release authority are scoped and controlled.
• The article shows how one exposed secret or poisoned dependency can cascade into code theft, malicious releases, and downstream customer impact.
• Least privilege, central secret management, and execution controls are the main levers that reduce pipeline blast radius.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · CI/CD Pipeline Identity Security Guide · CI/CD Security Guide · reviewdog Action compromise 2025

Key terms

• CI/CD Pipeline: The automated systems that build, test, and deploy software, often holding privileged credentials for source control, cloud access, and release automation. When these pipelines leak secrets, they can turn a software delivery function into a high-trust compromise path.
• Direct Poisoned Pipeline Execution: A supply chain attack in which an adversary injects malicious commands directly into pipeline definition files so the next build runs attacker-controlled code. The compromise works because the CI system trusts workflow configuration as execution authority, turning repository change control into runtime access control.
• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Build Runner: A build runner is the machine or container that executes automated development tasks such as installs, tests, packaging, and deployment. Because it often has access to tokens and service credentials, it should be treated as a privileged NHI environment rather than disposable infrastructure.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the automation systems their software delivery depends on.