GitHub Actions supply chain attacks expose the CI/CD identity layer

At a glance

What this is: This analysis says the TeamPCP GitHub Actions campaign was less about code corruption than about exposing the CI/CD identity layer that trusted workflows use to access cloud and production systems.

Why it matters: It matters because IAM, PAM, and NHI programmes need to govern automation identities as first-class access paths, not as hidden implementation details inside pipeline tooling.

👉 Read Unosecur's analysis of GitHub Actions supply chain attacks and CI/CD identity risk

Context

GitHub Actions pipelines are not just build systems. They are identity-driven execution environments that use service accounts, tokens, secrets, and IAM roles to reach cloud, deployment, and release systems.

In the TeamPCP campaign, attackers exploited trusted workflow execution to expose machine credentials and then reuse them as authenticated access across downstream environments. The governance gap is not the action alone, but the identity authority that the action can reach.

For IAM and NHI teams, the core problem is visibility and control over automation identities that outlive a single build step and often have broader access than the teams running them realise.

Key questions

Q: What breaks when a GitHub Actions workflow can reach production credentials?

A: The control boundary breaks when a workflow identity can access production-grade secrets without tight scoping and ownership. At that point, a supply chain compromise becomes an identity compromise because the attacker inherits valid access rather than needing to break authentication. Teams should assume the blast radius is defined by downstream trust, not by the workflow file alone.

Q: Why do valid pipeline credentials create the same risk as compromise?

A: Valid pipeline credentials are risky because they let attackers act through normal authenticated channels. That means there may be no failed logins, password resets, or obvious intrusion pattern to trigger traditional alerting. The governance issue is not whether the credential was stolen, but whether the identity was scoped narrowly enough to limit what the attacker can do.

Q: What are the signs that CI/CD security controls are not working well enough?

A: Common warning signs include secrets appearing in code or adjacent collaboration tools, policy violations that remain unresolved, weak visibility across the pipeline, and scanners that miss misconfigurations until late. If teams rely on manual review, struggle to trace findings back to owners, or cannot prioritize issues by impact, the control set is probably too fragmented to be effective.

Q: How do teams contain a supply chain compromise before it spreads?

A: Teams should revoke exposed secrets, isolate affected runners, and cut off access from automation identities that could reuse the same credentials elsewhere. The containment goal is to stop the poisoned trust path from reaching other repositories, registries, or cloud environments. The faster the shared identity is disabled, the smaller the blast radius.

Technical breakdown

Why GitHub Actions becomes an identity attack surface

A CI/CD pipeline is an execution plane that authenticates to other systems on behalf of code. That means the real security object is not only the workflow definition, but the service accounts, OAuth tokens, cloud roles, and secrets bound to it. When a trusted action is modified, the attacker inherits the pipeline's authenticated relationships without needing to defeat perimeter controls. This is why supply chain compromise in CI/CD often becomes identity compromise almost immediately. The exposed credentials are already valid, already authorised, and often already over-scoped for the task at hand.

Practical implication: Treat pipeline identities as governed access assets, not as incidental configuration.

How credential exfiltration turns into authenticated movement

Once a malicious workflow can read secrets, it can harvest working identities rather than just sensitive data. A stolen cloud token or GitHub credential is actionable because it authenticates as the pipeline, not as an intruder. That removes the usual detection cues such as failed logins or unusual password resets. In practice, this means lateral movement can occur through legitimate API calls, deployment operations, or cloud control-plane activity that appears normal unless identity behavior is monitored in context.

Practical implication: Monitor automation accounts for behaviour, not only for successful authentication events.

Why revocation alone rarely closes the blast radius

Revoking the compromised action or rotating one exposed secret does not undo what the pipeline identity could already reach. CI/CD workflows often have multiple reusable credentials, shared permissions across jobs, and downstream trusts into cloud and production environments. If the inventory of machine identities is incomplete, teams cannot know which access paths were affected or whether new credentials were created during the attack window. The result is a hidden blast radius that extends beyond the initial compromise point.

Practical implication: Inventory every pipeline identity and map its downstream access before you rely on revocation as containment.

Threat narrative

Attacker objective: The attacker objective was to turn trusted pipeline execution into authenticated access that could reach cloud and production environments.

1. Entry occurred when attackers modified a widely used GitHub action so downstream workflows executed malicious payloads inside trusted CI/CD jobs.
2. Credential harvest followed as the payload exposed cloud credentials, GitHub tokens, SSH keys, Kubernetes secrets, and environment variables bound to the pipeline.
3. Impact came when those harvested credentials were used as authenticated access across cloud and production environments, extending the compromise beyond the workflow itself.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD identity is the real security boundary: The article shows that supply chain compromise in GitHub Actions mattered because the pipeline carried authenticated access, not because the code path itself was novel. That shifts the control question from code integrity to identity governance over automation. Practitioners should treat pipeline identities as production-grade assets with explicit ownership, scope, and lifecycle.

Pipeline secrets are identities, not just sensitive values: Cloud credentials, OAuth tokens, SSH keys, and Kubernetes secrets in this context are working machine identities that can be reused immediately once exposed. That means secrets handling, offboarding, and rotation are all part of identity governance, not separate operational chores. The practical conclusion is that untracked machine credentials create invisible access paths that normal IAM reviews miss.

Blast radius depends on delegated trust, not just compromise timing: The TeamPCP pattern shows why a compromised action can cascade through cloud and deployment systems even when no zero-day is involved. The weak point is the assumption that trusted workflows remain trustworthy after execution begins. Teams need to know which identities a workflow can activate, where those identities are reused, and what downstream systems accept them.

Identity blast radius is the right named concept for CI/CD risk: In CI/CD, the harm is defined by how far a pipeline identity can reach once a trusted action is altered. That concept captures both the breadth of accessible systems and the persistence of valid credentials after initial compromise. Practitioners should use blast radius as the unit of CI/CD risk assessment, not the job or repository alone.

Security models that stop at code integrity are incomplete: The attack worked because the control plane around the workflow was not governed with the same rigor as application access. Access reviews, least privilege, and continuous monitoring have to extend to service accounts, tokens, and role bindings used by automation. The field should stop treating CI/CD as a development concern and start treating it as an identity governance domain.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Identity blast radius: The hidden risk in CI/CD is not just that a workflow runs untrusted code, but that one compromised automation identity can authenticate into multiple control planes. Teams that still manage pipeline access as a build concern will miss the moment when code compromise becomes downstream account abuse.

A strong CI/CD programme treats service accounts, tokens, and secret material as governed identities with ownership, scope, and offboarding rules. The lesson from this campaign is that access review models built for humans do not map cleanly onto pipeline execution, where credentials can be created, used, and replaced inside a single workflow run.

For practitioners

• Map every CI/CD automation identity Inventory service accounts, tokens, roles, and secrets used by GitHub Actions and document exactly which cloud, deployment, and registry systems each can reach.
• Scope pipeline credentials to one job Replace broad reusable credentials with short-lived credentials bound to a single workflow, environment, or deployment target, and revoke them when the job or project ends.
• Separate build and release privileges Remove the assumption that the same identity should build code, publish artifacts, and deploy to production. Distinct automation identities reduce cross-environment reuse if one action is altered.
• Monitor automation behaviour continuously Alert on unexpected token use, unusual API calls, new credential issuance, and cross-system access from pipeline identities, especially when valid credentials are in use.
• Pin and validate third-party actions Reference GitHub actions by verified commit hash rather than mutable tags, and require review before dependency changes are allowed into production workflows.

Key takeaways

• The campaign shows that GitHub Actions compromise becomes dangerous when the workflow holds machine credentials that can reach cloud and production systems.
• Pipeline identities, not just workflow code, determine the eventual blast radius of a supply chain incident.
• Organisations need visibility, least privilege, and revocation controls for automation identities if they want CI/CD compromise to stay contained.

Key terms

• CI/CD Identity: CI/CD identity is the set of credentials and permissions used by build, test, and deployment systems to act in software delivery pipelines. It includes service accounts, tokens, keys, and certificates that let automation access code, artifacts, cloud resources, and deployment targets. Strong governance limits exposure, scope, and lifetime.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.

What's in the full article

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

• Workflow-level indicators for detecting credential misuse inside GitHub Actions runs
• Step-by-step mitigation guidance for rotating exposed cloud, SSH, and Kubernetes credentials
• Practical advice on pinning third-party actions and validating dependency changes
• Examples of how identity monitoring changes the response to a CI/CD supply chain compromise

👉 Unosecur's full blog covers the pipeline attack chain, exposed credentials, and mitigation steps in more detail.

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.