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

At a glance

What this is: This is an analysis of how attackers are subverting CI/CD infrastructure, service identities, and developer environments to weaponize trusted delivery workflows.

Why it matters: It matters because CI/CD compromise crosses infrastructure and identity boundaries, so IAM, PAM, NHI, and platform teams need shared controls for runners, service accounts, tokens, and workflow integrity.

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.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.

👉 Read SentinelOne's analysis of CI/CD compromise and trusted infrastructure abuse

Context

CI/CD compromise is not a conventional malware problem. The defender is dealing with trusted automation, valid service identities, and workflows that are supposed to execute code, move artifacts, and access secrets as part of normal operations. That makes abuse harder to distinguish from legitimate build activity, which is why pipeline control has become a security and governance issue as much as an engineering one.

The identity angle is real here because build agents, service accounts, runner registrations, and developer tokens act like non-human identities with broad operational reach. When those identities are over-privileged, poorly monitored, or allowed to persist beyond their intended purpose, attackers can inherit the trust of the delivery system itself. That is a typical failure pattern in modern software supply chain compromise, not an edge case.

Key questions

Q: What breaks when CI/CD runners and service accounts are not tightly governed?

A: When CI/CD identities are not tightly governed, attackers can inherit trusted execution inside the software delivery path. A compromised runner, token, or workflow trigger can access secrets, move artifacts, and deploy malicious code while appearing operationally valid. The practical failure is not just exposure of one account, but a broader loss of trust in the pipeline's execution context.

Q: Why do non-human identities make supply chain attacks harder to detect?

A: Non-human identities make supply chain attacks harder to detect because build jobs and malicious actions often use the same tools, scripts, and permissions. If a service token or runner is valid, security tools may see expected automation rather than compromise. That is why provenance, scope, and runtime context matter as much as authentication.

Q: How should security teams reduce blast radius in CI/CD environments?

A: Security teams should reduce blast radius by assigning each pipeline identity the minimum permissions needed, rotating credentials aggressively, and separating build, test, and deploy privileges. They should also treat self-hosted runners as high-risk assets and monitor for unusual registrations, network activity, or secret access that does not fit the job's role.

Q: Who is accountable when a trusted build pipeline is used to deploy malware?

A: Accountability usually spans platform engineering, application owners, and security governance because the compromise sits at the intersection of code delivery and identity control. Organisations should map ownership for runners, tokens, workflow definitions, and release approvals before an incident occurs. Clear accountability is what makes containment and audit response possible.

Technical breakdown

How attackers turn CI/CD trust into execution

CI/CD systems are designed to execute code automatically, often with broad access to repositories, packages, secrets, and deployment targets. That design creates a structural weakness: if an attacker can influence a runner, service account, or workflow definition, the pipeline may execute malicious actions as if they were ordinary build tasks. In practice, this can mean injecting a benign-looking job, altering a trigger, or registering an attacker-controlled runner that the platform treats as trusted. The core failure is not just execution, but execution under legitimate operational context, which defeats many signature-based and perimeter-oriented detections.

Practical implication: Treat runner registration, workflow changes, and service account activity as security events, not just DevOps changes.

Why service identities and tokens are the real control plane

The article points to a recurring pattern in supply chain compromise: service account tokens, SSH keys, repository credentials, and automation secrets become the control plane for attackers once they are exposed. These are non-human identities in everything but name. If they are long-lived, widely scoped, or reused across systems, compromise of one token can provide access to multiple projects, pipelines, and environments. The technical issue is lifecycle control. Without rotation, scope restriction, and abuse monitoring, a token can outlive the job it was meant to serve and become a durable foothold.

Practical implication: Map CI/CD identities to owners, scopes, and rotation requirements, then remove standing access wherever automation does not need it.

Why traditional detection struggles in build environments

Build activity and malicious activity often look identical at the process level because both can compile code, fetch dependencies, open network connections, and launch scripts. That overlap makes context essential. Defenders need provenance signals such as who created the job, what changed, which secrets were accessed, whether the runner was newly registered, and whether the job behavior fits the expected role of the pipeline. This is where supply chain assurance intersects with identity governance, because the question becomes not just what ran, but which identity was allowed to run it and why.

Practical implication: Correlate build provenance with identity and secrets telemetry so deviations from expected workflow behavior are visible.

Threat narrative

Attacker objective: The attacker wants to inherit trusted automation so malicious code, credential access, and persistence can move through the software delivery chain as normal operations.

1. Entry occurs through compromised developer workstations, vulnerable self-hosted runners, exposed service account tokens, or malicious workflow triggers embedded in trusted collaboration systems.
2. Escalation happens when the attacker uses legitimate pipeline identities or registered runners to execute jobs with privileged access to repositories, secrets, and deployment paths.
3. Impact follows when the pipeline itself delivers backdoors, malicious dependencies, or automated execution into internal environments under trusted operational cover.

NHI Mgmt Group analysis

CI/CD compromise is now an identity governance problem, not only a pipeline security problem. The article shows attackers inheriting trust through service accounts, tokens, runners, and workflow triggers rather than breaking into production directly. That makes lifecycle control, least privilege, and provenance verification the core governance issues, not optional hardening steps. Practitioners should treat build identities as governed assets with owners, scopes, and expiry.

Shift-left attacks expose a pipeline trust gap: automation is being trusted to do exactly what attackers want it to do. The article's examples show why broad execution rights in build systems are risky when the job creator, trigger source, or runner registration is not continuously verified. In identity terms, the dangerous assumption is that valid automation equals valid intent. Practitioners should break that assumption with continuous attestation and contextual authorisation.

Standing privilege in delivery systems creates a long-tail blast radius. Self-hosted runners, long-lived service tokens, and reused credentials allow a single compromise to persist across multiple builds and releases. That pattern fits OWASP NHI and the broader attack surface described in the OWASP Non-Human Identity Top 10. Practitioners should prioritise short-lived credentials, scoped permissions, and rapid offboarding for every pipeline identity.

Developer workstations remain part of the pipeline's identity perimeter. The article correctly shows that compromise often begins with the human operator, then pivots into tokens, SSH keys, and repository access. That is why IAM, PAM, and NHI governance cannot stop at the repository boundary. Practitioners should align endpoint controls and identity controls around the same trust chain.

Continuous verification is becoming the operational baseline for software delivery. The old model assumed trusted runners and trusted releases were stable enough to review later. That no longer holds when attackers can subvert the automation layer itself. Practitioners should move from one-time approval to ongoing verification of build identities, workflow changes, and artifact provenance.

What this signals

The practical signal for enterprise teams is that CI/CD is now part of the identity perimeter. If runners, tokens, and workflow definitions are not managed with the same discipline as privileged human access, attackers will keep using automation as an execution layer. That shifts investment toward identity telemetry, provenance verification, and tighter secrets lifecycle controls across engineering platforms.

Pipeline trust gap: organisations need to assume that valid automation can still be malicious if the triggering identity, runner state, or job source has been altered. That is a governance problem first and a detection problem second. The teams that will cope best are the ones that connect endpoint telemetry, repository change control, and NHI ownership into one operating model.

GitHub and CI/CD telemetry should be treated as early warning data for broader supply chain exposure. A single compromised developer workstation or service account can become a release-channel incident, so security teams should plan for cross-functional response between IAM, DevSecOps, SOC, and platform engineering before the next compromise appears.

For practitioners

• Inventory every build identity and runner Create a complete register of self-hosted runners, service accounts, pipeline tokens, and developer automation credentials, then assign each one an owner, scope, and expiry date.
• Enforce short-lived access for pipeline automation Replace long-lived tokens where possible, scope credentials to a single workflow or environment, and revoke any automation secret that outlives the job it supports.
• Require provenance checks before execution Block workflow execution unless the job source, runner registration, and triggering identity match expected patterns for that repository and environment.
• Monitor for runner abuse and secret harvesting Alert on new runner registrations, unusual child processes, outbound tunnels, and access to secrets from jobs that do not normally need them.
• Tie developer endpoint telemetry to CI/CD risk Correlate workstation compromise signals with repository access, token use, and build activity so a developer phishing event does not become a pipeline incident.

Key takeaways

• CI/CD compromise succeeds when attackers inherit trusted automation rather than bypassing it.
• The scale of secrets exposure remains extreme, which means workflow identity and credential lifecycle are still too weak in many environments.
• Security teams need to govern runners, service accounts, tokens, and developer endpoints as one delivery-chain risk surface.

Key terms

• Build Runner: A build runner is the system that executes jobs in a CI/CD pipeline. It often has access to repositories, secrets, and deployment tooling, which makes it a high-value target if it is self-hosted, over-privileged, or not continuously verified.
• Service Account Token: A service account token is a credential used by automation rather than a person. In CI/CD, these tokens can unlock repositories, build systems, and deployment paths, so their scope, lifetime, and revocation process are critical security controls.
• Pipeline Provenance: Pipeline provenance is the evidence chain showing who created a job, what changed, which runner executed it, and what artifacts were produced. It is the difference between merely observing execution and proving that the execution matched the intended workflow.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, configuration files, tickets, chat, and automation platforms. It increases the chance that a single exposed secret can unlock multiple systems and makes revocation harder because no one knows where all copies live.

What's in the full article

SentinelOne's full report covers the operational detail this post intentionally leaves for the source:

• Threat-by-threat examples of runner compromise, workflow abuse, and dependency poisoning across 2025 incidents
• The specific signals used to distinguish malicious pipeline activity from expected automation in live environments
• Detailed guidance on monitoring self-hosted runners, service identities, and build artifacts for abuse
• Examples of how attacker tradecraft moved from developer compromise into CI/CD execution paths

👉 The full SentinelOne report covers attack examples, detection context, and pipeline defense guidance

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners align identity controls with the systems that actually execute modern software delivery.