GitHub Actions supply chain attacks expose NHI governance gaps

At a glance

What this is: This analysis shows how GitHub Actions supply chain abuse turns CI/CD identities, tokens, and runner trust into a path for secret theft and pipeline compromise.

Why it matters: It matters because IAM, NHI, and PAM teams have to govern pipeline identities as production access, not as disposable build plumbing.

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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Orca Security's analysis of GitHub Actions supply chain attacks and hardening

Context

GitHub Actions is a CI/CD runtime that executes code, handles credentials, and can touch production-adjacent systems. The security problem is that many teams still treat workflow identities, repository tokens, and self-hosted runners as low-risk build infrastructure, even though they can expose secrets and alter downstream pipelines.

This article uses real-world supply chain attacks to show how that assumption fails in practice. Once workflows can execute untrusted input, reuse mutable dependencies, or run with persistent runner state, the pipeline becomes an identity security problem as much as an application security one.

For IAM and NHI programmes, the takeaway is clear: build pipelines are not outside the governance boundary. They are credential-bearing execution environments that need least privilege, lifecycle control, and explicit trust boundaries.

Key questions

Q: How should teams secure GitHub Actions against supply chain compromise?

A: Teams should pin reusable actions to immutable commit SHAs, restrict token scope, and review every dependency that can execute inside a workflow. They should also assume that any action used in build or release automation can become a secret-bearing trust anchor and monitor it accordingly.

Q: Why do GitHub Actions workflows increase the risk of secret exposure?

A: Because workflows often run with access to repository tokens, cloud credentials, and runner state, a compromise can reveal more than code. When secrets remain valid after exposure, the workflow becomes a standing privilege path rather than a one-time event.

Q: What breaks when self-hosted runners are reused across jobs?

A: Reused runners can preserve tokens, local files, and hidden state between executions, which gives an attacker a place to persist. The risk is highest when the runner can reach internal systems or execute workflows from untrusted contributors.

Q: Who is accountable when a workflow secret is exposed through a GitHub Action?

A: Accountability sits with the team that owns the workflow, the secrets, and the runner environment, because pipeline identities are part of the access model. Security, platform, and application teams should share ownership of approval boundaries, token scope, and revocation.

Technical breakdown

Why mutable GitHub Actions dependencies become a supply chain path

GitHub Actions workflows often reference actions by version tags, reusable marketplace packages, or nested dependencies. When attackers compromise a maintainer account or a dependency chain, they can replace trusted code without changing the caller’s workflow. The problem is not just code execution. It is that the trust decision is made once and then reused across thousands of repositories, creating a shared failure domain. In the tj-actions case, the malicious change propagated through a widely trusted action and then executed inside downstream workflows with access to secrets and runner memory.

Practical implication: pin workflow dependencies to immutable commit SHAs and review every reusable action as an access-bearing dependency.

How command injection happens inside workflow runners

GitHub Actions runners have historically treated certain strings in output as workflow commands. That means untrusted content, such as pull request titles, issue text, or branch names, can become executable control data if it is interpolated into a shell or echoed into the runner in the wrong way. The exploit is simple because the boundary between data and instruction is weak. Once a workflow evaluates user-controlled input, an attacker can change environment variables, alter paths, or influence subsequent commands without needing a separate binary exploit.

Practical implication: treat all repository-supplied input as untrusted and route it through safe variables or sanitised parsing only.

Why self-hosted runners turn ephemeral build jobs into persistent access

Self-hosted runners are part of the trust chain, not just execution capacity. If they retain state between jobs, hold long-lived tokens, or can reach internal systems, a compromised workflow can persist beyond a single run and harvest credentials repeatedly. That changes the attacker’s economics. Instead of one-shot theft, they get a durable foothold in the CI/CD layer. The PyTorch example showed how a seemingly small trust relationship, combined with persistent runners and overprivileged tokens, can create a hidden access channel that is difficult to spot from repository history alone.

Practical implication: isolate self-hosted runners, make them ephemeral where possible, and remove production-grade privilege from build environments.

Threat narrative

Attacker objective: The attacker seeks to turn trusted CI/CD automation into a secret-extraction and downstream compromise channel.

1. Entry occurred through risky workflow execution paths and trust in mutable actions, allowing attackers to reach secrets-bearing jobs.
2. Escalation followed when compromised maintainer access and overprivileged tokens let the attackers modify trusted dependencies and workflow tags.
3. Impact came when downstream repositories executed the poisoned action, exposing secrets in logs and enabling broader pipeline compromise.

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/CD identity is production identity, not build convenience. GitHub Actions workflows carry secrets, token scope, and downstream authority, so they sit inside the identity control plane whether teams acknowledge it or not. When attackers compromise an action or inject into a runner, they are not just breaking software integrity, they are abusing an identity-bearing execution context. Practitioners should treat pipeline access as governed privilege, not as disposable automation.

Mutable dependencies create trust reuse at dangerous scale. A tagged GitHub Action can be altered after review, which means the original approval no longer matches the code that executes later. That is a trust model designed for stable software but applied to a moving target. The implication is that dependency pinning is an identity control as much as a software supply chain control, because it freezes the object that was actually authorised.

Secret exposure in workflows is usually a lifecycle failure, not a one-off leak. The real problem is that exposed tokens often remain valid long after the original job ends, allowing reuse across repositories and environments. This is where lifecycle governance, rotation discipline, and access scope intersect. Practitioners should recognise that a leaked workflow secret is a standing privilege event, not just an alert to investigate.

Workflow trust boundaries must be designed for untrusted input, not friendly contributors. Pull request titles, issue bodies, and branch names are data, but runners can accidentally treat them as instructions. That breaks the assumption that text from the repository is safe because it came from a developer workflow. Security teams need to reassess where data becomes command inside CI/CD and where approval gates should interrupt execution.

More CI/CD automation does not reduce governance demand, it expands it. The pipeline now spans human contributors, NHI credentials, and machine execution in one chain of custody. That makes the control problem cross-domain: human review, NHI lifecycle, and runtime isolation all have to line up. Practitioner focus should shift from securing a workflow file to governing the identity behaviour of the entire pipeline.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• For a broader control lens, read The 52 NHI breaches Report for recurring patterns in leaked credentials, overprivilege, and downstream compromise.

What this signals

Identity blast radius: GitHub Actions shows how a single workflow can carry enough authority to behave like production access. When a build system can read secrets, modify tags, or reach internal services, the blast radius is no longer limited to software delivery. Teams should model pipeline identities as governed assets and review them with the same seriousness as privileged service accounts.

The control signal is no longer whether a repository is public or private. Internal repositories are 6x more likely to contain secrets than public ones, so hidden trust often sits inside the places teams assume are safer. That means secrets detection, token revocation, and workflow review have to be continuous rather than event-driven.

For practitioners aligning CI/CD to NIST SP 800-207 Zero Trust Architecture, the lesson is straightforward: verify every trust boundary inside the pipeline, including reusable actions, runners, and secret scope. The next maturity step is to connect workflow governance to lifecycle controls, not just code review.

For practitioners

• Pin every reusable action to an immutable commit SHA Replace version tags and floating references with commit-level pins in all GitHub Actions workflows. Review whether any trusted dependency can still be altered after approval, especially actions used in release, deploy, or secret-handling jobs.
• Set repository tokens to read-only by default Grant write permission only to jobs that truly need it, and scope secrets to the smallest environment possible. If a workflow can reach production or release assets, require explicit approval before elevated credentials are exposed.
• Treat all repository input as untrusted data Handle pull request titles, issue text, and branch names as attacker-controlled content. Avoid direct shell interpolation, use safe environment variables, and remove any workflow pattern that lets text become executable control data.
• Isolate self-hosted runners from sensitive systems Make runners ephemeral where feasible, block internal network access by default, and avoid using them for public repositories. If persistent runners are unavoidable, monitor token reuse, local state, and filesystem residue after each job.
• Protect workflow files with explicit ownership controls Require security team review for changes under .github/workflows/ and related reusable action paths. That keeps pipeline changes inside a controlled lifecycle process instead of allowing silent privilege expansion through ordinary code review.

Key takeaways

• GitHub Actions compromises show that CI/CD pipelines are identity-bearing execution environments, not low-risk build utilities.
• Mutable actions, overprivileged tokens, and persistent runners create the exact conditions needed for secret theft and downstream compromise.
• The practical answer is governance discipline: immutable references, least privilege, runner isolation, and lifecycle control for every workflow identity.

Key terms

• GitHub Actions runner: A GitHub Actions runner is the machine that executes a workflow job. In practice it is an identity-bearing execution environment because it can hold secrets, access tokens, and network reach. If the runner is persistent or overprivileged, it becomes part of the attack surface rather than just infrastructure.
• Mutable dependency: A mutable dependency is a workflow component that can change after it has been reviewed, such as a version tag or reusable action reference. The danger is that the approved object and the executed object are no longer the same, which undermines trust, traceability, and access control.
• Workflow secret: A workflow secret is a credential, token, key, or certificate exposed to a CI/CD job so it can perform a task. Because these secrets can unlock cloud, code, or release systems, they must be treated as privileged identities with lifecycle, scope, and revocation requirements.
• Command injection in CI/CD: Command injection in CI/CD happens when untrusted text is interpreted as executable workflow syntax or shell input. In GitHub Actions, that can allow titles, comments, or branch names to alter environment variables, command paths, or job behaviour without a separate malware payload.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: GitHub Actions supply chain attacks and hardening techniques. Read the original.