GitHub Actions supply chain attacks expose NHI governance gaps

At a glance

What this is: Orca Security examines how GitHub Actions supply chain attacks exposed weaknesses in pipeline identity governance, especially around mutable dependencies, overprivileged tokens, and runner trust.

Why it matters: IAM, PAM, and NHI teams need to treat CI/CD workflows as governed identities because pipeline compromise can expose secrets, alter dependencies, and widen blast radius across repositories.

By the numbers:

• Approximately 218 repositories exposed secrets during the tj-actions compromise window.

Context

GitHub Actions is a CI/CD automation layer that executes code, handles secrets, and reaches into build infrastructure on behalf of a repository. When those workflows inherit trust from tags, tokens, and runner state, the identity problem is no longer just code execution. It becomes a governance problem for non-human identities, because the workflow itself can become the path from change request to secret exposure.

The article focuses on three real incidents and the recurring control gaps they reveal: mutable dependencies, unsafe handling of user-controlled input, and persistent runner trust. Each case shows that pipeline identities need lifecycle controls, permission scoping, and offboarding discipline just like other NHIs. The starting position in most teams is typical, not exceptional: workflows are usually managed as engineering plumbing rather than governed identities.

Key questions

Q: What breaks when GitHub Actions workflows use mutable dependencies and overprivileged tokens?

A: The reviewed workflow is no longer the executed workflow. Mutable actions can change after approval, and overprivileged tokens turn that change into repository control or secret exposure. The result is a trust gap where the pipeline looks governed but actually behaves like an unbounded access path.

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 are the signs that a CI/CD pipeline is being compromised?

A: Common warning signs include sudden dependency changes, base64 encoded or packed code, unexpected outbound connections during builds, install scripts that run without a clear reason, and commits or approvals at unusual times. Failed signature or checksum checks are especially important because they often indicate tampering, poisoned artifacts, or an attacker inserting untrusted components into the delivery chain.

Q: How should teams respond when a workflow dependency or runner is compromised?

A: Treat the workflow as a standing identity incident. Revoke tokens, rotate exposed secrets, pin or replace the affected dependency, inspect downstream repositories, and rebuild the affected runners or execution environment before resuming trusted automation.

Technical breakdown

How GitHub Actions trust becomes a supply chain dependency

GitHub Actions workflows often consume third-party actions by version tag, then inherit whatever code that tag points to at execution time. That is a dependency trust model, not a static code model. In the tj-actions case, a compromised upstream dependency propagated malicious behavior across downstream workflows because the referenced action was mutable. The security issue is not only code integrity. It is that workflow identity, dependency identity, and secret access were allowed to converge at runtime without a hard boundary between trusted and untrusted execution.

Practical implication: Pin actions to immutable commit SHAs and treat version tags as untrusted changeable references.

Why workflow commands and user input create injection risk

GitHub Actions runners historically interpreted certain output strings as workflow commands, which made untrusted text dangerous when echoed into execution contexts. If a pull request title, issue body, or branch name can reach shell interpolation or command parsing, an attacker can influence environment variables, PATH, or downstream job behavior. This is a classic input-to-execution break. The control failure is not simply poor validation; it is allowing user-controlled data to cross from content into instruction without a safe boundary such as environment variables or file-based command channels.

Practical implication: Move user-controlled values out of evaluated shell contexts and into safe, non-executable data paths.

Why self-hosted runners expand the blast radius of NHI compromise

Self-hosted runners are not just execution workers. They are persistent infrastructure with memory, filesystem state, network reach, and often broader access than ephemeral cloud runners. In the PyTorch example, that persistence let attackers stay hidden longer and harvest active tokens from a trusted runtime. This is where NHI governance becomes lifecycle governance: a runner with long-lived state behaves like a privileged machine identity that must be isolated, rotated, and revoked when its trust posture changes. Persistent execution environments turn one compromise into repeated secret exposure.

Practical implication: Use ephemeral runners for sensitive workflows and segment self-hosted runners away from internal and secret-bearing resources.

Threat narrative

Attacker objective: The attackers aimed to harvest repository and cloud secrets, take control of trusted workflow dependencies, and extend compromise across downstream CI/CD pipelines.

1. Entry occurred through risky workflow triggers and untrusted input paths, including pull_request_target and echoed user-controlled data.
2. Credential access followed when attackers extracted maintainer secrets and abused an overprivileged bot token with broad write permissions.
3. Lateral movement and impact came when compromised dependencies and mutable tags spread malicious code across thousands of downstream workflows, exposing secrets in logs and runner memory.

Breaches seen in the wild

• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

Pipeline identities are being governed as software components when they should be governed as access-bearing identities. A GitHub Actions workflow can read secrets, invoke tools, and alter downstream state, which makes it an identity subject, not just an automation script. The article shows that the real failure is lifecycle blindness: workflow trust was granted through tags, maintainer access, and runner persistence without identity-specific controls. The practical conclusion is that CI/CD must be treated as part of the identity estate, not as a separate engineering concern.

Mutable dependency trust is an identity governance problem, not merely a software supply chain problem. When an action can change after approval, the approval decision no longer maps to the code that actually runs. That breaks the assumption that authorisation is stable between review and execution. The named concept here is workflow trust drift: the gap between the workflow a team reviewed and the workflow that ultimately executes. Practitioners need to recognise that SHA pinning is not just a build-hardening step, it is an identity integrity control.

Overprivileged workflow tokens collapse the boundary between build-time convenience and production-grade access. The tj-actions-bot PAT had broad write permissions, which turned one compromised path into repository control. That is a classic NHI failure mode: a token granted for automation accumulates more authority than the task requires, then becomes a persistence and escalation mechanism. The implication is that privilege scope, not workflow frequency, is the control variable that matters most in CI/CD governance.

Persistent runners invalidate the assumption that a trusted execution environment is clean after each job. That assumption was designed for short-lived, observable sessions. It fails when the actor is a long-lived runner with memory, disk, and network access that survives across jobs and can be quietly reused by an attacker. The implication is that review, revocation, and blast-radius thinking must extend to runner lifecycle, not just to secrets and repository permissions.

GitHub Actions security is now a test case for broader non-human identity governance. The same pattern appears anywhere machine identities inherit trust from upstream artifacts, runtime context, or human-created approval states. This article reinforces OWASP-NHI concerns about secret leakage, overprivilege, and offboarding, but it also shows that CI/CD pipelines are where those weaknesses become operationally visible. Practitioners should use the pipeline as a forcing function for NHI policy maturity.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Workflow trust drift: CI/CD teams often approve one thing and execute another when actions are referenced by mutable tags or rewritten dependencies. That gap matters because identity authority in a pipeline is not static, so the control point must move to immutable references and governed approval of workflow changes.

Persistent runners need identity lifecycle treatment: a self-hosted runner behaves like a privileged machine identity when it retains memory, filesystem state, and network reach between jobs. NHI teams should consider runner offboarding, isolation, and blast-radius reduction as part of the same governance model they use for service accounts.

GitHub Actions incidents are a reminder that least privilege is only meaningful when the runtime boundary is real. In practice, that means short-lived permissions, narrow token scope, and execution environments that cannot preserve attacker state across jobs.

For practitioners

• Pin workflow dependencies to immutable SHAs Replace version tags with commit SHAs for all third-party actions so the reviewed code matches the executed code. Limit this to workflows that handle secrets, write permissions, or production deploys.
• Scope workflow tokens to the minimum required permissions Set GitHub_TOKEN to read-only by default, then grant write access only for the specific job and environment that needs it. Review bot tokens and maintainer tokens as standing credentials, not temporary conveniences.
• Isolate self-hosted runners from sensitive resources Prefer ephemeral runners for public or secret-bearing workflows, and deny internal network reach from any runner that can process untrusted pull request content or third-party actions.
• Protect workflow files with approval control Require CODEOWNERS review for any change under .github/workflows/ so pipeline logic cannot be modified silently through routine repository edits.
• Scan artifacts and logs for secret leakage Validate build artifacts before release and review logs for leaked tokens, keys, or private data, especially after dependency updates or workflow trigger changes.

Key takeaways

• GitHub Actions attacks expose a governance gap where workflow identities are trusted like code but behave like access-bearing non-human identities.
• The article’s examples show how mutable dependencies, broad tokens, and persistent runners combine into a repeatable secret-exposure pattern.
• Immutable references, narrow permissions, and ephemeral execution boundaries are the control set that limits blast radius in CI/CD pipelines.

Key terms

• Claim Trust Drift: Claim trust drift is the gap between where a token was issued and where it is later accepted without enough restriction. It happens when audience, issuer, or lifetime controls are too broad, allowing a valid cryptographic token to create invalid access across systems.
• 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.
• 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.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

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 building or maturing an IAM programme, it is worth exploring.