CI/CD subversion is turning trusted build infrastructure into attack surface

At a glance

What this is: This article argues that CI/CD environments are being used as attack infrastructure, with trusted runners, service accounts, and developer workstations enabling compromise to blend into normal software delivery.

Why it matters: It matters because identity, secrets, and automation controls now sit on the critical path for software delivery, so IAM and NHI teams have to govern build-time trust as tightly as runtime access.

Context

CI/CD pipelines are not just delivery tooling, they are privileged execution environments that can move code, secrets, and artifacts across an organisation. When those trusted paths are compromised, the attack is harder to distinguish from legitimate operations because the malicious work is performed by systems that already look authorised.

The identity angle is central here: service accounts, build runners, developer credentials, and repository tokens all behave like non-human identities with powerful, often under-governed access. Once attackers inherit that trust, they can operate through the same automation channels that software teams rely on every day.

Key questions

Q: What breaks when CI/CD access is not tightly governed?

A: Build and deployment systems become an easy path to bypass application defenses. If tokens, service accounts, or deployment credentials are over-privileged, an attacker or careless operator can alter what gets shipped, inject malicious changes, or expose sensitive data. Least privilege and credential rotation are essential in those environments.

Q: Why do compromised build pipelines create identity risk beyond AppSec?

A: Because build pipelines often hold publishing rights, signing secrets, and automation tokens that function like privileged identities. When those credentials are reused across systems, the compromise extends into IAM and NHI governance, not just source code integrity. Security teams need to treat pipeline trust as an access-control problem with lifecycle and revocation requirements.

Q: How do security teams know whether pipeline access is actually under control?

A: Look for three signals: no long-lived deploy secrets in repository or pipeline settings, tight Kubernetes roles scoped to the smallest viable namespace and verbs, and audit logs that tie each deploy to a specific workflow run. If any one of those is missing, the pipeline still has standing privilege.

Q: What should organisations do when build infrastructure is used as an attack path?

A: They should investigate runner enrolment, revoke suspicious tokens, rotate exposed secrets, and review every workflow that could have executed under stolen automation identity. The priority is containment of the trusted path before the same identities are reused for persistence or further spread.

Technical breakdown

Why CI/CD runners and build servers are high-risk trust zones

Build servers and CI/CD runners are designed to execute code automatically, pull dependencies, publish artifacts, and deploy software with minimal friction. That makes them powerful, but it also means they behave like privileged orchestrators rather than ordinary endpoints. In a compromise, the attacker does not need to create obviously malicious behaviour. They only need to issue actions that resemble normal build tasks, such as script execution, package retrieval, or job chaining. Because the environment is already expected to run code and interact with internal resources, traditional endpoint assumptions break down quickly.

Practical implication: treat build infrastructure as privileged execution infrastructure and monitor it with controls that distinguish normal pipeline activity from abuse.

How service accounts and tokens turn automation into an attack path

CI/CD systems commonly rely on service identities, tokens, and other machine credentials to trigger jobs and move work between systems. Those credentials are often long-lived and broadly scoped, which means compromise of one automation identity can hand an attacker the same authority as the pipeline itself. Once a valid token is used to create jobs or submit artifacts, the platform may process the action as trusted automation rather than adversarial activity. The core issue is not merely authentication failure, but the absence of tight lifecycle governance around who can issue, reuse, and revoke automation identities.

Practical implication: bind each pipeline identity to a narrow scope, short lifetime, and explicit offboarding process.

Why developer workstations and rogue runners extend the pipeline attack surface

The pipeline attack surface extends beyond central build tools because developers, maintainers, and self-hosted runners all participate in the delivery chain. A compromised workstation can expose SSH keys, repository access, and tokens that let an attacker move into source control and automation systems. Likewise, attacker-registered runners can become persistent participants in trusted workflows, allowing malicious jobs to run as if they belonged in the environment. This is a governance problem as much as a technical one, because the organisation has to know which machines are allowed to act inside the delivery path and how they are enrolled and removed.

Practical implication: inventory every machine that can run build tasks and verify that runner enrolment is controlled, monitored, and revocable.

Threat narrative

Attacker objective: The objective is to turn the organisation’s own delivery infrastructure into a trusted mechanism for persistence, secret theft, and downstream compromise.

1. Entry begins when attackers compromise build infrastructure, steal a service account token, or infect a developer workstation that already has access to source control and CI/CD systems.
2. Credential access and abuse follow when the attacker uses a valid token, trusted runner, or developer credential to create malicious jobs, register rogue runners, or trigger automated workflows.
3. Escalation occurs as the compromised automation executes with trusted permissions, accesses internal resources, and deploys backdoors or malicious dependencies across the delivery chain.
4. Impact is achieved when the pipeline itself becomes the delivery mechanism for persistence, secret exposure, lateral movement, or malware distribution inside the environment.

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 trust has become a governance problem, not just a tooling problem. Build systems are being targeted because they already hold the authority to execute code, move artifacts, and touch secrets. That means the core failure is implicit trust in automation, not simply weak malware detection. Practitioners need to govern build-time trust as a privileged identity problem, not a generic endpoint issue.

Build runners now behave like non-human identities with exploit value. A runner or service account that can execute jobs, read repositories, and access secrets is effectively an NHI with production-grade privilege. When those identities are long-lived or loosely controlled, attackers can inherit their authority without ever needing a human login. This makes lifecycle control, offboarding, and scope restriction central to CI/CD security.

Shift-left attacks are collapsing the boundary between software delivery and intrusion. The article’s pattern shows that attackers do not need to wait for production exposure when they can manipulate the build path earlier. That changes how teams should think about assurance: the delivery chain itself must be continuously verified, because trusted automation can be the attack vector, the persistence layer, and the exfiltration path all at once.

Supply chain compromise now depends on identity abuse as much as code abuse. The most important risk signal is not only tampered code, but unauthorised use of service identities, runners, and developer credentials. That brings IAM, PAM, and NHI lifecycle governance directly into software supply chain defence. The practical conclusion is that CI/CD resilience starts with governing who and what is allowed to act inside the pipeline.

Continuous verification is the right control model for build infrastructure. Static trust assumptions fail when the same workflow can be normal one minute and hostile the next. Organisations need to treat new runners, modified workflows, and unexpected secret access as governance events. The discipline here is to make pipeline trust earned at execution time, not granted by default.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Build infrastructure is now an identity governance surface. The practical lesson for practitioners is that CI/CD cannot be treated as a pure engineering concern. Service accounts, runners, and developer credentials behave like privileged identities, so lifecycle control and offboarding discipline have to extend into the delivery stack.

Trusted automation needs continuous verification, not static trust. Pipeline compromise often succeeds because defenders assume that a valid job, token, or runner is inherently safe. Continuous monitoring for new runners, unusual workflow triggers, and secret access is what closes that gap in practice.

Secret sprawl increases the blast radius of CI/CD compromise, according to the Ultimate Guide to NHIs and the State of Secrets Sprawl 2026. If secrets live in repositories, config files, and pipeline tools instead of governed vaults, a single compromised workflow can expose far more than the immediate job needs. That is why pipeline security and secrets governance now rise or fall together.

For practitioners

• Harden build runner enrolment Require explicit approval for self-hosted runners, maintain a current inventory of every registered runner, and alert on new or renamed build agents that appear outside approved change windows.
• Constrain service account scope and lifespan Limit pipeline service identities to the minimum repositories, workflows, and artifacts they need, then revoke any token that can create projects or trigger jobs outside its intended purpose.
• Inspect workflow-triggered execution paths Review jobs that start from comments, repository events, or other indirect triggers, and flag any workflow that can execute code without a human reviewing the exact change first.
• Monitor build-time secret exposure Scan repositories, pipeline definitions, and build logs for credentials that should never persist in source or output, then rotate any exposed tokens before they can be reused in automation.
• Add behavioural detection to CI/CD infrastructure Watch for child processes, outbound tunnels, unusual package retrieval, and unexpected artifact movement from build systems, because those are the actions attackers most often hide inside legitimate jobs.

Key takeaways

• CI/CD compromise succeeds when attackers inherit trusted automation rather than fighting their way through perimeter controls.
• Service accounts, runners, and developer workstations are part of the pipeline attack surface, not separate from it.
• Defenders need continuous verification of build identities, workflow changes, and secret access to keep delivery trust from becoming intrusion trust.

Key terms

• CI/CD subversion: CI/CD subversion is the use of trusted software delivery systems as the intrusion path instead of attacking production directly. The attacker abuses build jobs, runners, service identities, or workflows so malicious activity is executed as normal automation.
• 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.
• Bound Service Account Token: A service account token that is tied more closely to a specific pod or workload context. This binding improves traceability and reduces the usefulness of a stolen token, because the token is less transferable and easier to constrain to its intended runtime scope.
• Shift-left attack: A shift-left attack targets earlier parts of the software lifecycle, such as developer workstations, source control, dependencies, and build systems. The aim is to compromise trusted development processes before code reaches production, where defenders often expect to do most of their detection.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern non-human access across modern delivery pipelines and other privileged systems.