CI runner compromises expose the blind spot in pipeline security

At a glance

What this is: This is an analysis of how compromised GitHub Actions and CI runners become execution points for supply chain attacks, credential harvesting, and downstream pivoting.

Why it matters: It matters because CI runners often hold production credentials, short-lived cloud tokens, and repository secrets, so identity, secret, and runtime controls all need to be treated as one governance surface.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 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.
• Internal repositories are 6x more likely to contain secrets than public ones, 32.2% versus 5.6%, contradicting the assumption that private repos are safe.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Abstract Security's analysis of CI runner threat detection and GitHub Action compromises

Context

CI/CD runner security is the control problem created when build systems combine code execution, secret access, and network reach in the same place. In practice, a runner is not just an automation node. It is an identity-bearing execution environment that can read credentials, fetch cloud tokens, and reach internal services if governance is weak. For security teams, the primary issue is that pipeline trust often assumes the job is legitimate once it starts, even though the runner is exactly where compromise becomes operational.

That matters because modern supply chain attacks increasingly target the runtime layer rather than only the repository. A malicious action or dependency can inherit the runner's permissions, scrape in-memory secrets, and pivot into cloud, Kubernetes, or package publishing systems. For identity programmes, this is a non-human identity problem as much as a detection problem: the runner's access scope, token lifetime, and secret exposure path all determine how far an attacker can move.

Key questions

Q: How should security teams reduce the blast radius of compromised CI/CD tools?

A: Limit each pipeline to the minimum credentials it needs, separate build from deploy permissions, and remove long-lived secrets from execution environments. The goal is to ensure that a poisoned package or workflow can only reach a narrow identity scope, not cloud administration, repository control, or broad data access. Review service accounts as privileged identities, not generic automation.

Q: Why do CI runners create such a high risk of secret exposure?

A: Runners often load secrets into memory during execution and, in self-hosted cases, may also retain credentials on disk between jobs. That combination gives attackers two collection paths at once, so secret minimisation and short-lived runtime retrieval matter more than static storage.

Q: What do teams get wrong about ephemeral build infrastructure?

A: They assume ephemeral means safe by default. Ephemeral infrastructure still becomes dangerous if the workflow has broad permissions, can access metadata services, or can mint federated tokens before the job ends. The lifetime is short, but the trust granted during that lifetime may be too large.

Q: Who is accountable when a poisoned action exfiltrates cloud credentials?

A: Accountability sits with the teams that defined workflow permissions, secret handling, runner isolation, and federation policy. Security, platform, and identity owners all share responsibility because the failure usually spans IAM, CI/CD, and cloud governance rather than a single control owner.

Technical breakdown

Why CI runners are attractive execution points for attackers

A CI runner is the process that executes workflow steps, which means it becomes the runtime boundary where untrusted code can inherit trusted access. Hosted runners are ephemeral, but both hosted and self-hosted models still load secrets, tokens, and environment variables into the job context. If a compromised action runs inside that context, the attacker does not need to break authentication from scratch. They can simply abuse the identity already granted to the job. That is why runner compromise is really an identity containment problem, not only a malware problem.

Practical implication: treat each runner as a high-value identity-bearing workload and restrict what it can reach before any job starts.

How secrets and tokens are harvested from runner memory and disk

The article shows two common collection paths. One path reads Runner.Worker memory via /proc to pull decrypted workflow secrets before the job ends. The other searches filesystem locations for stored credentials such as cloud profiles, Kubernetes configs, SSH keys, Docker auth files, and shell history. These methods work because secrets are often available in plaintext or decryptable form during execution, and self-hosted runners can retain that material between jobs. In governance terms, the weakness is not only exposure but persistence of reachable secret material.

Practical implication: minimise secret residency on runners and remove any filesystem path that can survive beyond a single job.

How compromised runners pivot into cloud and Kubernetes environments

Once attackers harvest credentials, they can use the runner's existing reach to mint short-lived cloud tokens, query metadata services, or abuse mounted Kubernetes service account tokens. This is a classic privilege inheritance problem. The attacker is not creating a new identity, but reusing one that already has federated trust into other systems. That makes OIDC, metadata access, and service account boundaries critical choke points. Where the runner can federate, an attacker can often expand from build-time execution into production-adjacent access.

Practical implication: separate runner permissions from production trust paths and deny unnecessary federation, metadata, and cluster API access.

Threat narrative

Attacker objective: The attacker aims to turn build infrastructure into a credential harvesting and lateral movement platform that can compromise downstream cloud and software supply chain targets.

1. Entry occurs when a compromised GitHub Action or poisoned dependency executes inside the CI runner with inherited workflow permissions.
2. Credential access follows through memory scraping of Runner.Worker or filesystem harvesting of stored cloud, Kubernetes, and SSH credentials.
3. Escalation happens when the stolen identity is used to mint cloud tokens, access metadata services, or pivot through mounted service account credentials.
4. Impact is downstream supply chain compromise, including exfiltration, backdoored pipelines, and reuse of stolen credentials across other environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI runner compromise is an NHI governance failure, not just a detection problem. The runner is a non-human identity with temporary but powerful access, and the article shows how quickly that access can be abused once malicious code executes. Identity teams that treat pipelines as simple automation miss the fact that the runner carries production-adjacent trust. The governing question is whether that identity can be constrained to the exact task it needs to perform.

Runner trust persistence is the core concept this article exposes. The problem is not only that secrets exist during a job, but that the execution context often remains rich enough to be harvested, reused, or pivoted from. This weakens assumptions behind short-lived tokens and ephemeral infrastructure when the surrounding permissions are broad. Practitioners should read this as a call to shrink the usable trust surface around every job, not merely to observe it better.

Pipeline identities need lifecycle controls equivalent to human privileged accounts. CI runners, service accounts, and OIDC-linked workloads can all become privileged access paths when they are granted broad repository or cloud reach. That means registration, rotation, scoping, and offboarding logic must apply to pipeline identities as first-class assets. The practical conclusion is that IAM and PAM teams should stop treating CI as an isolated DevOps concern.

Runtime monitoring has to be paired with secret design, because visibility alone cannot close the breach window. The article's telemetry approach is useful, but it becomes reactive if secrets remain accessible in memory or on disk after execution begins. The broader lesson is that detection should complement, not substitute for, least privilege, secret minimisation, and offboarding of stale runner access. Security teams need both guardrails and observability to make pipeline identity governable.

From our research:

• 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, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to GitGuardian, which shows why exposure and revocation must be linked.
• Forward look: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026, showing how new automation surfaces expand the secret problem.

What this signals

Runner trust has become a policy problem, not just an observability problem. As build systems absorb more credentials and federated access, the governance boundary shifts toward the runner identity itself. Teams should expect pressure to prove where secrets can be read, which jobs can mint tokens, and how fast compromised access can be revoked. That is where Ultimate Guide to NHIs , Key Challenges and Risks remains relevant.

Blast-radius control is now the decisive design question for CI/CD identity. The relevant metric is not simply whether a runner is monitored, but whether it can touch enough to cause downstream compromise if one step is poisoned. IAM, PAM, and platform engineering teams should align on task-scoped permissions, short-lived federation, and hard separation between build and release trust paths.

The more automation depends on secrets, the more the secret lifecycle becomes part of the attack surface. Detection needs to be paired with revocation, because harvested credentials can outlive the event that exposed them. For identity leaders, this is a strong argument for treating CI/CD secret handling as part of identity governance rather than a separate DevOps hygiene issue.

For practitioners

• Restrict workflow permissions to the minimum viable scope Set explicit read-only or task-scoped permissions on every workflow and remove broad repository or cloud access from runner identities. Separate build, test, and release permissions so a compromised job cannot inherit deployment reach.
• Eliminate long-lived secrets from runner hosts Move cloud, registry, and Kubernetes credentials into a runtime secret manager and fetch them only when a step needs them. Remove cached credentials, dotfiles, and reusable auth material from self-hosted runner disks.
• Treat OIDC and metadata access as privileged attack paths Block unnecessary access to cloud metadata services, constrain federation claims, and require strict conditions before a runner can mint short-lived tokens. Review how mounted service account tokens and trusted publishing flows can be abused.
• Instrument runners for cross-process memory and file access Monitor /proc memory reads, temp directory staging, and suspicious file collection patterns on CI hosts. Pair those detections with process lineage telemetry so a script interpreter reading runner memory stands out immediately.
• Rotate every credential reachable from a compromised workflow If a runner or action is suspected to be compromised, revoke any secret the pipeline could touch, then review cloud audit logs, package publishing logs, and Kubernetes access records for downstream reuse.

Key takeaways

• CI runner compromises turn build infrastructure into a credential-bearing identity surface that attackers can reuse for cloud and supply chain pivoting.
• The evidence across recent campaigns shows that memory scraping, filesystem harvesting, and token abuse are recurring patterns, not isolated anomalies.
• The controls that matter most are task-scoped permissions, short-lived secrets, restricted federation, and telemetry that can catch cross-process memory reads.

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.
• Secret Residue: Secret residue is credential material that remains available after the point where it should no longer be accessible, such as cached files, environment variables, or leftover config data on disk. It turns a short-lived workflow into a longer-lived exposure window and increases the chance of reuse after compromise.
• Federated Token Abuse: Federated token abuse occurs when an attacker uses a trusted workload identity to mint short-lived access tokens for cloud or downstream systems. The attack does not require creating a new account. It exploits the existing trust chain, which is why federation boundaries and claim conditions matter so much.

What's in the full article

Abstract Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact Tetragon tracing policies used to detect cross-process /proc memory reads and suspicious file access patterns.
• Example detection logic for Runner.Worker memory scraping, temp-directory staging, and reverse shell behaviour.
• Runner-specific hardening guidance for GitHub-hosted, self-hosted, and Kubernetes-based runners.
• The payload-driven analysis of Trivy compromise telemetry and the specific process patterns that surfaced.

👉 The full Abstract Security post covers telemetry, detection logic, and runner hardening examples.

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 is designed for practitioners who need to connect identity controls to real-world operational risk across modern infrastructure.