GitHub Actions supply chain attack exposes identity security gaps

At a glance

What this is: This analysis examines the tj-actions/changed-files compromise and shows how mutable GitHub Actions dependencies can expose CI/CD secrets at scale.

Why it matters: It matters because one compromised workflow component can turn CI/CD identities, cloud credentials, and package tokens into a broad cross-environment blast radius for IAM and security teams.

👉 Read Unosecur's analysis of the GitHub Actions supply chain attack

Context

GitHub Actions supply chain risk is not only a code integrity problem. When workflow dependencies are mutable, the identity attached to the runner can be turned against the organisation, and CI/CD secrets become exposed through execution paths that developers assume are stable.

This incident shows why pipeline identity belongs in the same governance conversation as NHI, secrets management, and access lifecycle control. A compromised action can bridge source control, cloud access, and package publishing in a single chain, which makes version pinning, log hygiene, and token scope management part of the identity programme rather than peripheral DevOps tasks.

Key questions

Q: How should security teams prevent GitHub Actions from becoming a supply chain entry point?

A: Security teams should pin actions to immutable commit SHAs, restrict workflow permissions, and remove reusable secrets from runners wherever possible. GitHub Actions becomes a supply chain entry point when trust is anchored to mutable tags and broad execution rights. The safest model is narrowly scoped, short-lived, and verifiable execution.

Q: Why do CI/CD secrets create such a large blast radius when a workflow is compromised?

A: CI/CD secrets often unlock cloud accounts, repository administration, and package publishing from a single execution context. When a compromised action can read those secrets, the attacker inherits multiple downstream identities at once. That is why pipeline compromise is rarely limited to one repository and often becomes cross-environment identity abuse.

Q: What do teams get wrong about using OIDC in GitHub Actions?

A: Teams sometimes treat OIDC as a complete fix when it is really a credential-lifecycle improvement. It reduces the value of stolen secrets, but it does not compensate for overly broad workflow permissions or unsafe dependency trust. OIDC works best when paired with least privilege and tight separation of pipeline roles.

Q: Who is accountable when a compromised workflow exposes cloud and repository credentials?

A: Accountability usually sits with the platform, IAM, and engineering teams together because the failure spans dependency trust, secret storage, and execution permissions. The right governance model assigns ownership for workflow identity, logs, and credential lifecycle instead of treating CI/CD as a pure developer concern.

Technical breakdown

Mutable version tags in GitHub Actions

Version tags such as v1 are convenient because they let teams consume updates without changing workflow files. The problem is that a tag is a moving reference, not a cryptographic guarantee. If an attacker can rewrite the tag or the referenced commit, every workflow that trusts the tag inherits the new code path automatically. That turns dependency resolution into an identity trust problem: the runner executes what the tag points to, not what the team reviewed. In this incident, that behaviour let a malicious commit masquerade as a legitimate release and propagate across many repositories.

Practical implication: pin workflows to immutable commit SHAs and treat mutable tags as an unacceptable trust boundary.

Runner permissions and CI/CD secret exposure

A GitHub runner executes with the permissions granted by the workflow, which often includes environment variables, cloud credentials, and repository tokens. Once malicious code runs inside that context, it does not need to break the platform again. It simply reads what the pipeline already made available. The attacker in this case used a memory-scanning script to collect authentication material from the runner, then bypassed normal log redaction by encoding the output so it appeared harmless until decoded. That is a classic secret exposure failure, not just a malware event.

Practical implication: minimise runner permissions, remove static secrets where possible, and assume logs may become a disclosure surface.

OIDC and least privilege for workflow identities

OpenID Connect changes CI/CD security by replacing long-lived cloud secrets with short-lived tokens issued at runtime. That reduces the value of a leaked credential because the token expires and is bound to a narrower trust context. But OIDC only helps when teams also constrain workflow permissions and separate build tasks from deployment privileges. The incident demonstrates that secret reduction and permission reduction need to move together. If a workflow can still access broad cloud or repository rights, the identity model remains too generous even if the credential format is modern.

Practical implication: combine OIDC with explicit workflow permissions and separate build, test, and release identities.

Threat narrative

Attacker objective: The objective was to harvest reusable identity material from CI/CD pipelines and use it to gain broader access across cloud, code, and package ecosystems.

1. Entry occurred when attackers gained control of the tj-actions/changed-files repository and rewrote a version tag to point to malicious code.
2. Credential harvesting happened after the compromised action executed in CI/CD workflows and scanned runner memory for tokens, AWS keys, and GitHub secrets.
3. Impact followed when stolen secrets were printed into publicly accessible workflow logs, creating the potential for cloud access, repository tampering, and package 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

Mutable workflow references are a governance weakness, not a convenience feature. GitHub Actions tags were designed for ease of consumption, but that assumption fails when the referenced code can be altered after teams have approved it. The implication is that pipeline trust must shift from human-readable labels to immutable provenance and verified execution paths.

CI/CD secrets are NHI credentials with the same lifecycle risk as service accounts. Once a runner can read cloud keys, PATs, and package tokens, the attack surface extends far beyond the repository. This is the same identity problem that appears in workload and service-account governance: access granted for automation can outlive the moment it was intended to support, so practitioners should treat workflow secrets as governed identities, not embedded configuration.

Ephemeral execution does not eliminate blast radius when the runtime can disclose durable credentials. The compromised action did not need persistence in the traditional sense because the runner already held valuable secrets in memory and logs. That makes blast radius the decisive control variable, not whether the workflow is short-lived. Teams that still model CI/CD as a narrow build concern are underestimating the identity reach of their pipelines.

GitHub Action supply chain compromise is a named concept for the trust gap between workflow labels and executable code. It captures the failure mode where mutable references, broad runner permissions, and exposed logs combine into a repeatable credential abuse pattern. The practical conclusion is that workflow identity needs the same governance discipline applied to NHI and privileged access.

This attack is a textbook example of over-trusted automation identity. The workflow identity was allowed to inherit more privilege than the task itself required, and the malicious code turned that privilege into credential harvesting. Practitioners should read this as a control-boundary failure across source control, secrets management, and cloud access governance.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why exposed workflow credentials remain a recurring governance failure.
• For the control gap behind this incident, see 52 NHI Breaches Analysis for repeatable breach patterns and lifecycle failure modes.

What this signals

GitHub Actions security now belongs in the identity programme, not just the DevOps backlog. The combination of mutable references, runner permissions, and exposed logs means workflow identity should be reviewed alongside service accounts and cloud access paths. Teams that already map secret lifecycle risk can use that framework here, but they need to extend it to pipeline execution and provenance controls.

GitHub Action supply chain compromise: the trust gap between workflow labels and executable code will keep widening as more organisations depend on shared automation. With 6 distinct secrets manager instances on average, fragmentation makes it harder to enforce consistent workflow secret handling across teams and environments.

Practitioners should expect more incidents where the first compromise is not a cloud control plane but a build dependency that can read tokens, keys, and publish rights. That pushes organisations toward tighter provenance controls, reduced workflow privilege, and better visibility into where CI/CD identities are allowed to act.

For practitioners

• Pin workflow dependencies to immutable commits Replace mutable version tags in GitHub Actions with pinned commit SHAs so the executed code cannot change after review.
• Reduce runner privilege to the task minimum Separate build, test, and release workflows so each runner receives only the repository scopes and cloud rights it actually needs.
• Replace long-lived cloud secrets with OIDC Use short-lived federation tokens for cloud access and remove static AWS keys, GitHub PATs, and similar reusable credentials from workflow storage.
• Treat workflow logs as a disclosure surface Scan logs for credential leakage, restrict who can read them, and assume obfuscated output can still be decoded by an attacker.

Key takeaways

• This incident shows that a trusted GitHub Action can become a credential-harvesting path when mutable references and runner permissions are left unchecked.
• The scale matters: more than 23,000 repositories were affected, which demonstrates how quickly one workflow compromise can propagate across many environments.
• Immutable pinning, short-lived credentials, and narrower workflow privilege are the controls that would have reduced the blast radius most directly.

Key terms

• Workflow Identity: The identity a CI/CD pipeline uses when it runs code, reads secrets, or reaches external services. It is often a mixture of repository permissions, runner context, and cloud federation rights, so governance must cover execution scope, token lifetime, and what the workflow can disclose if compromised.
• Mutable Version Tag: A reference such as v1 that can point to different code over time. In supply chain security, it is a convenience mechanism that becomes a trust problem when attackers can change what the tag resolves to after teams have approved it.
• Runner Blast Radius: The amount of access and downstream impact a compromised build runner can create. It includes credentials in memory, secrets in environment variables, and permissions inherited from the workflow, which means a small execution foothold can become a multi-system identity incident.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Line-by-line MITRE ATT&CK mapping of the tj-actions compromise from tag rewrite to log exposure
• Specific remediation steps for GitHub Actions runners, including token scope review and workflow hardening
• Examples of how the malicious script accessed memory, secrets, and encoded output in build logs
• Practical guidance on replacing mutable action references with pinned commit hashes across repositories

👉 Unosecur's full blog covers the attack chain, exposed credential types, and workflow hardening steps

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.