GitHub Actions supply chain attacks expose the build runner gap

At a glance

What this is: Cycode shows that GitHub Actions supply chain attacks keep succeeding inside the build runner, where attacker code can read memory, exfiltrate secrets, and tamper with workflow output.

Why it matters: This matters because IAM, NHI, and DevSecOps teams often harden repository access and release trust while leaving runner runtime behaviour effectively unobserved.

Context

GitHub Actions supply chain attacks exploit a mismatch between where teams concentrate controls and where attackers execute. The trusted boundary is usually defined around source repositories, tags, and tokens, but the build runner is where third-party code actually runs and where secrets, deployment credentials, and package tokens are already loaded into memory.

For identity and access practitioners, the issue is not only supply chain integrity but identity exposure inside ephemeral execution. A runner can become a high-value non-human execution environment with broad access for a short period, which means the governance problem is runtime observability and control, not just pre-build approval.

The tj-actions incident illustrates the pattern clearly: a stolen token, a repointed action, and a malicious payload were enough to turn routine builds into secret exfiltration events. That starting position is now typical rather than exceptional across this class of incidents.

Key questions

Q: What breaks when GitHub Actions runners do not have egress monitoring?

A: Without egress monitoring, teams lose one of the clearest signals that a workflow step is reaching out to an unexpected destination. That makes poisoned actions, compromised dependencies, and secret exfiltration harder to detect during execution. The result is weaker containment, slower investigation, and less confidence in whether a build behaved normally.

Q: Why do GitHub Actions supply chain attacks keep exposing secrets even when teams pin SHAs?

A: Because SHA pinning only constrains what code is fetched, not what that code does once it runs. A malicious action, package, or injected workflow step can still access environment variables, read process memory, and print or send credentials from inside the runner. The risk is execution, not just provenance.

Q: How do security teams know whether runner protection is actually working?

A: Check whether every active build is inheriting the same runtime controls, whether the approved runner image is current, and whether any workflow still depends on a manual security step. If protection varies by repository or author behaviour, the control is not fully working.

Q: How should security teams respond when a widely used GitHub Action is compromised with a credential stealer?

A: Treat every workflow run during the exposure window as potentially credential-compromised. Isolate affected pipelines, identify which secrets the job could access, and rotate those credentials immediately. Review runner logs and outbound network activity for signs of exfiltration, then pin workflows to known safe versions or immutable commits before re-enabling automation.

Technical breakdown

Why build runners are the real target

A GitHub Actions runner is a transient execution environment that assembles code, dependencies, secrets, and deployment credentials into one place long enough to produce an artifact. That concentration makes the runner more valuable than the repository itself. Attackers do not need durable persistence if they can execute during the build window, because the runner already holds environment variables, injected tokens, and sometimes cloud or registry credentials. In this model, the build system becomes a non-human identity context with temporary but powerful access. The security challenge is that most controls are still designed to validate what enters the workflow, not what executes inside it.

Practical implication: Treat the runner as a privileged execution zone and instrument it for process, file, and network visibility.

How token theft and action abuse turn into secret exfiltration

The common attack sequence starts with initial access to a trusted action, token, or trigger context, then moves into code execution inside the runner. Once attacker code runs, it can inspect memory, read files such as /proc/PID/mem, spawn subprocesses, or inject values into workflow environment files. Secrets masked in logs are not protected if they are read from memory before logging. This is why static controls like SHA pinning and token scoping reduce risk but do not cover the execution phase. The attacker is no longer trying to bypass repository trust; they are exploiting the trust already granted to the workflow runtime.

Practical implication: Add runtime controls that watch for memory reads, unexpected subprocesses, and unapproved outbound connections.

Why eBPF changes CI/CD defence

Extended Berkeley Packet Filter, or eBPF, gives the kernel-level visibility needed to inspect runner behaviour as it happens. Rather than waiting for logs or post-build telemetry, eBPF can observe process creation, network egress, and file access in the exact execution path used by malicious actions or backdoored packages. That matters because the recurring GitHub Actions pattern is not novel entry, but identical in-runner behaviour. The defensive value is in seeing what a build step actually does, not assuming that trusted provenance prevents abuse once code is executing.

Practical implication: Use kernel-level monitoring to block reads of sensitive process memory and outbound traffic to unfamiliar domains.

Threat narrative

Attacker objective: The attacker wants to harvest CI/CD secrets and use the build runner as a trusted conduit for further supply chain compromise.

1. Entry occurs when an attacker steals a trusted token, abuses a pull_request_target context, or compromises a third-party action used by the workflow.
2. Execution follows when the malicious action or package runs inside the privileged build runner and gains access to injected secrets and environment variables.
3. Exfiltration happens when the payload reads process memory, writes secrets into logs, or sends credentials to an attacker-controlled endpoint.
4. Impact is secret disclosure, build tampering, or downstream package poisoning across the repositories that trusted the compromised workflow component.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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

The build runner is the control gap, not the repository. Most supply chain programmes still assume that securing tags, tokens, and source provenance is enough. In these incidents, the attacker’s meaningful action happens after trust is already granted, inside the runner where secrets are live and logging can be abused. The governance failure is treating runtime as an implementation detail instead of the primary enforcement point.

Build environments now behave like high-value non-human identities. They receive delegated access to cloud credentials, registry tokens, signing material, and deployment secrets for a narrow window, then execute without human supervision. That means NHI governance concepts, especially scoped privilege and lifecycle containment, apply directly to CI/CD runners and not only to service accounts or API keys. Practitioners should manage runners as ephemeral, privileged identities with explicit runtime boundaries.

Secret masking does not solve in-memory exposure. Masking protects logs, not the memory of a process that has already loaded credentials. This is the decisive lesson from repeated memory-read attacks: the control assumption was that the secret only needed to be hidden at output time. The stronger concept here is runtime disclosure window, the period in which credentials are present in memory and therefore exploitable. Practitioners need controls that reduce that window, not just controls that redact the aftermath.

SHA pinning is necessary but structurally incomplete. It protects against moved tags and some poisoned releases, but it cannot see shell injection, malicious post-install code, or direct memory reads once the runner starts. The market signal is clear: CI/CD security is moving toward execution-layer monitoring because provenance alone does not prevent runtime abuse. Teams should assume the build step itself is part of the attack surface, not a trusted gap between controls.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Runtime disclosure window: CI/CD security now depends on controlling the brief period when secrets exist inside a build runner, because that is where attacker code can read memory, not just where logs can leak. Teams that only harden repository trust will continue to miss the execution layer where compromise becomes practical.

The practical shift for practitioners is to treat pipeline identity as ephemeral but highly privileged, then enforce controls that see process behaviour inside the runner. That means pinning and token scoping remain necessary, but they are only the front door; the real safeguard is runtime inspection of memory access, subprocess creation, and outbound traffic.

For practitioners

• Instrument runner runtime behaviour Monitor process execution, file access, and network egress inside CI/CD runners so malicious actions are visible while they run.
• Reduce trust in third-party actions Require commit-SHA pinning, review maintainership exposure, and restrict workflows that execute third-party actions in privileged contexts.
• Separate build secrets from general workflow context Minimise what is injected into the runner and avoid loading credentials that are not required for the specific job phase.
• Block sensitive memory and unexpected egress Alert on reads of /proc/PID/mem, anomalous subprocess launches, and outbound calls to destinations outside the pipeline baseline.

Key takeaways

• GitHub Actions supply chain attacks repeatedly succeed by abusing the build runner, where secrets are already present and runtime behaviour is often invisible.
• The article cites more than 23,000 affected repositories in the tj-actions incident and says GitHub Actions runs over 5 million workflows daily.
• Runtime controls matter because pinning, token scoping, and pre-build scanning do not observe the execution phase where memory reads and secret exfiltration happen.

Key terms

• 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.
• Runtime Monitoring: The practice of observing identity activity while it is happening, not after the fact. For agents and NHIs, it means tracking tool calls, credential use, and resource access in real time so deviations from approved scope can be detected before damage compounds.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.
• Pull Request Target Risk: A workflow risk pattern where untrusted pull request content is processed in a privileged context. Because the job may run with write access or access to secrets, the boundary between review and execution collapses. The control failure is not the pull request itself, but the permissions attached to the trigger.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to the runtime environments where privileged non-human access is actually exercised.