CI runner compromises expose the blind spot in pipeline security

At a glance

What this is: Abstract Security shows that CI runner compromises turn supply chain abuse into process-level execution on systems holding credentials, secrets and cloud access.

Why it matters: This matters because CI/CD runners sit inside the trust boundary for both software delivery and identity, so visibility and least-privilege controls must extend to ephemeral and self-hosted pipeline execution.

Context

CI runner security is the control problem that emerges when build and deployment systems are allowed to execute code with broad access but are monitored too lightly to see abuse in real time. In this article, Abstract Security frames the runner as the point where a poisoned dependency becomes an active process, which is why the issue belongs as much to identity governance as to runtime detection.

The core weakness is not only that runners can be compromised, but that they often hold cloud credentials, package registry access and other secrets that are difficult to distinguish from legitimate job activity. That creates a governance gap for both NHI and workload identity because the machine doing the work is also the machine that can silently exfiltrate the keys that power downstream access.

The article’s examples are typical of modern pipeline risk, not edge cases, because hosted and self-hosted runners both create a place where malicious code can execute inside trusted automation. The practical question is whether organisations can observe and constrain that execution before it turns into credential harvesting, persistence or lateral movement.

Key questions

Q: What breaks when CI runners are allowed to execute forked code with access to repository secrets?

A: The CI runner stops being a build environment and becomes an attack surface. A malicious pull request can run shell commands, read environment variables, dump memory, and send stolen data off platform. Once an attacker controls the job context, secret exposure, repository defacement, and destructive code injection can follow quickly.

Q: Why do overprivileged CI/CD components create such high supply chain risk?

A: Overprivileged pipeline components turn a routine build system into a high-value attack path. If an attacker reaches a runner, token, or job editor, they can move laterally, alter builds, leak secrets, or inject malicious code. Least privilege limits how far compromise can spread and reduces the blast radius when credentials or automation are abused.

Q: What are the signs that a CI/CD runner has been abused for secret theft or persistence?

A: Look for unexpected workflow executions from untrusted contributions, unusual outbound network connections, new or altered runner registrations, and process activity that does not match the build job. Secret theft often shows up alongside token abuse, log deletion, changes to release metadata, or access attempts against repositories and cloud storage outside normal build behavior.

Q: How should security teams govern CI runners as part of identity architecture?

A: Security teams should treat CI runners as first-class non-human identities with owner assignment, scoped access, lifecycle control, and auditable connection context. That makes pipeline behaviour visible and enforceable in the same way as other production workloads, rather than leaving it inside developer-managed secrets.

Technical breakdown

Why CI runners become the execution point for supply chain compromise

A CI runner is the worker that checks out code, runs workflow steps, and invokes third-party actions or dependencies. That makes it the point where a poisoned Action, malicious package, or altered workflow becomes active code rather than a static artifact. Hosted runners reduce persistence, but they do not remove runtime exposure because the job still executes with whatever credentials, environment variables, and file access the workflow has been granted. Self-hosted runners raise the stakes further because they can retain local state between jobs and reach internal services. The technical risk is therefore not just build integrity, but the combination of code execution and trusted access in the same runtime boundary.

Practical implication: Treat runner execution as a privileged control plane and restrict the access each job receives to the minimum it needs.

How secrets and workload credentials leak from runner memory and disk

The article shows two common harvest paths: reading the Runner.Worker process memory to extract decrypted workflow secrets, and walking the filesystem for stored credentials on persistent hosts. In both cases, the attacker is targeting where the runner temporarily or permanently materialises secrets for legitimate use. That includes cloud keys, kubeconfigs, Docker credentials, SSH material, and token caches. This is a classic non-human identity problem because the machine identity and its credentials are being consumed inside automation, often with little human review. Once exposed, those credentials can be reused immediately or sold into the developer credential economy for later abuse.

Practical implication: Assume any secret available to a job is reachable to an attacker with code execution on that runner unless you isolate issuance and minimise lifetime.

How runtime telemetry exposes runner abuse before exfiltration completes

The telemetry approach described in the article focuses on process lineage, /proc access, file reads, and outbound connections, which are strong indicators of runner compromise. Memory scraping shows up as cross-process reads into /proc/PID/mem, secret hunting appears as bursts of access to credential paths, and exfiltration often follows via curl or a shell-based reverse connection. That is why runner monitoring works best when it is tied to behaviour, not just static workflow scanning. The underlying lesson is that the detection target is the runtime process using the identity, not only the repository that defined the job.

Practical implication: Instrument runner process behaviour and file access so you can distinguish legitimate build activity from credential harvesting and data egress.

Threat narrative

Attacker objective: The attacker wants to turn trusted pipeline execution into a credential-harvesting foothold that can spread across cloud and supply chain environments.

1. Entry occurs when a compromised GitHub Action or dependency executes malicious code inside a CI runner during an otherwise legitimate job.
2. Credential access follows when the payload reads Runner.Worker memory or harvests credentials from runner filesystem locations used for cloud, Kubernetes, or registry access.
3. Escalation and lateral movement happen when those stolen credentials are reused to query metadata services, mint OIDC tokens, or access internal services beyond the original job boundary.
4. Impact is credential exfiltration, runner persistence on self-hosted systems, and downstream compromise of cloud, package, or infrastructure resources.

Breaches seen in the wild

• 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).
• 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.

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 runner compromise is a workload identity problem, not only a build integrity problem. The article makes clear that the runner is where code execution, secrets, and cloud reach converge. That means the governance unit is the job itself, not just the repository or the developer account that triggered it. Practitioners should treat runner-issued privileges as ephemeral NHI state that must be observed and constrained at issuance time.

Pipeline identities create a blind spot when monitoring assumes human-like review cycles. Access reviews and log review processes assume access persists long enough to be inspected, but pipeline credentials can be consumed and stolen within a single job. That makes post-hoc certification too slow for the problem the article describes. The practical conclusion is to move control left into workload issuance, runtime telemetry, and strict action allowlisting.

Secret sprawl in CI/CD is the enabling condition that turns runner compromise into enterprise compromise. The article’s focus on memory scraping and disk harvesting shows that exposed secrets, not just vulnerable code, are the real breach multiplier. In identity terms, this is a standing access problem hidden inside automation. Teams need to reduce the number of places a runner can see a reusable secret at all.

Runtime detection is now a governance control, not just a SOC enhancement. The article’s eBPF and telemetry examples show that process-level visibility is what distinguishes normal build activity from hostile collection and exfiltration. For organisations with cloud-native delivery, the absence of runner telemetry is a policy gap, not merely an operational gap. Practitioners should regard runner monitoring as part of identity assurance for the software factory.

CI runner security is where supply chain defence and NHI governance meet. Abstract Security’s analysis shows that third-party actions, federated tokens, and ephemeral jobs all depend on machine identities that are easy to over-trust. That combination is why runner security cannot be treated as a narrow DevOps topic. The correct response is to govern machine access as rigorously as human privileged access.

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

CI runner blind spots are now an identity governance issue. When build automation can read secrets from memory and disk, the control failure is not just in detection coverage but in how much reusable access is available to the job in the first place. Teams should reduce the number of credentials any runner can see and prefer short-lived issuance over stored secrets.

Pipeline identity must be governed as a runtime subject. The article’s telemetry examples show that abuse is observable when organisations collect the right process and file signals, but that only works if runner activity is considered part of the identity plane. According to the State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.

Secret sprawl inside CI/CD is the signal that the governance model is too permissive. If secrets still live in workflow files, runner home directories, and cached credentials, then compromise of the automation layer becomes compromise of the enterprise access layer. Organisations that want real containment need to move issuance, not just monitoring, closer to the job boundary.

For practitioners

• Constrain workflow permissions to the minimum Set explicit, minimal permissions for every workflow and remove write access wherever read-only execution is sufficient. The goal is to reduce what a compromised runner can reach during the job.
• Reduce secret exposure inside runners Stop placing reusable credentials on runner hosts and fetch sensitive material at runtime from a dedicated secret manager. Prefer short-lived tokens and scoped step-level access over persistent credentials.
• Instrument runner behaviour as a detection source Monitor process lineage, /proc reads, credential-path access, and outbound connections so memory scraping and exfiltration are visible as runtime events rather than only as post-incident artefacts.
• Harden self-hosted and persistent runners Keep self-hosted runners off public repositories, require approval for outside collaborators, and prefer ephemeral runners where practical so malicious persistence has less room to survive between jobs.
• Review external action trust and pinning Pin third-party actions to full commit SHAs and allow only approved actions through organisation policy, because tag repointing and action compromise are central to this attack pattern.

Key takeaways

• CI runner compromise turns software delivery infrastructure into an identity and secrets exposure problem, not just a source-code integrity problem.
• Abstract Security’s analysis points to a recurring pattern of memory scraping, filesystem harvesting, and exfiltration from within trusted jobs.
• The control that matters most is reducing what a runner can access in the first place, then watching its runtime behaviour for abuse.

Key terms

• CI runner: A CI runner is the execution environment that processes build, test, and deployment jobs. In NHI terms, it often holds privileged automation access, temporary credentials, and environment context that can be harvested if a malicious dependency or script executes during the pipeline.
• Runner.Worker process: Runner.Worker is the GitHub Actions worker process that executes jobs and handles job-request data. Because it can contain environment values and secret-related data during a run, it becomes a sensitive runtime boundary that attackers may target if workflow code is compromised.
• Ephemeral Runner: A disposable build executor that exists only for a single job or short-lived task. Ephemeral runners reduce the chance that credentials, state, or malicious changes persist across builds, which makes them a key control for pipeline isolation and supply chain resilience.
• Developer Credential Sprawl: Developer credential sprawl is the uncontrolled spread of keys, tokens, SSH material, and secrets across endpoints, applications, and build pipelines. The risk is not just exposure but reuse, because one stolen credential can unlock multiple trusted workflows.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and human identity controls. It helps practitioners connect identity policy to the runtime systems that actually consume access.