Identity is the real perimeter in cloud supply chain attacks

At a glance

What this is: This article argues that cloud supply chain attacks increasingly succeed by stealing and abusing identities rather than exploiting servers, with the Nx compromise used as the main example.

Why it matters: IAM, IGA, PAM and NHI teams need to treat developer accounts, CI/CD identities and cloud roles as attack paths, not just administrative overhead.

👉 Read Unosecur's analysis of identity risk in cloud supply chain attacks

Context

Cloud supply chain attacks now exploit the identity layer that connects developers, pipelines, packages and cloud platforms. The problem is not only malicious code in a dependency chain, but the trust granted to tokens, service identities and automation accounts that can already reach production systems.

That shift matters because traditional perimeter thinking assumes attackers must first break infrastructure before they can act. In practice, the attacker may only need a poisoned package or stolen token to inherit legitimate access and move through the software delivery chain.

The article uses the Nx compromise to show how quickly a developer workstation can become a gateway into repositories, CI/CD and cloud administration. That is typical of current cloud identity abuse, not an edge case.

Key questions

Q: What breaks when poisoned packages harvest developer credentials?

A: The break is not just code execution. Once a malicious package can collect tokens, keys and cloud credentials, the attacker can move through repositories, CI/CD workflows and cloud access paths using legitimate identities. That makes the problem a trust failure in the software delivery chain, not only a malware detection problem.

Q: Why do CI/CD identities increase cloud takeover risk when they are overprivileged?

A: Because deployment identities are already trusted to move code into production and often sit close to sensitive cloud permissions. If those roles can assume broader privileges, modify policies or create new identities, a stolen pipeline credential can become a fast path to administrative control without exploiting the cloud platform itself.

Q: How can security teams tell if identity abuse is happening in the pipeline?

A: Look for unexpected token use, unusual OIDC role assumptions, service accounts performing new actions and IAM changes that do not match the release process. Those signals often appear before a full cloud takeover, especially when authentication logs are available but identity analytics are weak.

Q: How should organisations reduce the blast radius of build and deploy identities?

A: Limit the permissions of package managers, signing services, and deployment automation to the smallest set needed for their task. Separate fetch, sign, and promote functions, rotate required secrets, and prefer workload identity where feasible. That prevents one compromised automation account from controlling the entire release chain.

Technical breakdown

How poisoned packages turn developer identities into access paths

A malicious package can execute code during install, which makes the developer workstation part of the attack surface. In this case, the post-install script searched for GitHub personal access tokens, npm tokens, SSH keys, API keys and cloud credentials, then exfiltrated them to attacker-controlled repositories. The important point is that the package was only the delivery mechanism. The real value came from the identities already present on the machine, because those credentials were reusable across source control, deployment and cloud access.

Practical implication: treat developer endpoints as credential-rich identity zones and reduce the number of live secrets present during routine builds.

Why CI/CD and OIDC trust chains become escalation machinery

Modern pipelines often authenticate to cloud platforms through short-lived credentials issued from trust relationships such as GitHub Actions to cloud IAM via OIDC. That design reduces static secret exposure, but it also concentrates trust in the automation identity itself. If an attacker compromises the workflow token, service identity or role assumption path, they can use the same legitimate exchange as the pipeline. The compromise is then not a password theft event but a trusted identity event, which is harder to distinguish from normal release activity.

Practical implication: scope pipeline trust narrowly and review which cloud roles can be reached through each OIDC relationship.

How over-privileged automation turns identity abuse into cloud takeover

Automation roles often gather permissions over time until they can deploy resources, modify policies or create identities. Once an attacker controls one of those roles, the next step is privilege escalation rather than lateral movement in the classic server sense. The article describes a chain from developer credential to GitHub service identity to CI/CD automation role and then to new administrator IAM role. That is a cloud identity escalation path built from excess trust and weak permission boundaries, not from an unpatched host.

Practical implication: review automation roles for permission sprawl and separate deployment rights from identity-management rights.

Threat narrative

Attacker objective: The attacker wanted to convert trusted developer and automation identities into cloud administrative access without needing to exploit infrastructure vulnerabilities.

1. Entry began with a malicious code injection into a GitHub Actions workflow associated with the Nx release process, which enabled theft of the npm publishing token.
2. Credential harvesting followed when the malicious package executed on developer machines and collected GitHub tokens, SSH keys, API keys and cloud credentials from local systems.
3. Escalation occurred when those identities were reused to inspect repositories, examine CI/CD workflows and reach trusted cloud roles through OIDC-based authentication paths.
4. Impact was cloud privilege escalation, with attacker access able to progress from developer identities to administrative control of connected repositories and cloud infrastructure.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

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

Identity is now the primary cloud perimeter, not the network edge. The article is right to frame the Nx compromise as an identity event rather than a malware event. When a package can collect tokens, keys and cloud credentials, the attacker inherits legitimate access paths instead of forcing entry. For practitioners, that means the security boundary is defined by who and what can authenticate, not by where the workload sits.

Standing trust in CI/CD identities is an assumption that no longer holds. OIDC-based pipeline authentication was designed for controlled, task-scoped trust, but the article shows how that trust becomes an escalation path when workflow identities or roles are over-broadened. The old assumption that automation only executes approved build steps fails when the same identity can also reach cloud roles and identity-management functions. Practitioners need to rethink the trust model behind every release path.

Ephemeral credentials do not eliminate identity abuse when the actor holding them is over-privileged. The article shows that short-lived tokens still become powerful when they can be reused to assume cloud roles, inspect workflows or create more privileged identities. The named concept here is identity blast radius: the number of systems an attacker can reach once one developer or automation identity is compromised. The practitioner challenge is not just credential lifetime but the scope of damage attached to each identity.

Developer endpoints are part of the identity control plane. A workstation used for builds and releases often stores more production-relevant secrets than a server does, which makes endpoint telemetry an identity signal source rather than just a malware indicator. That should change how teams think about developer environments, especially where CI/CD and cloud credentials coexist. The control problem is cross-domain, but the governance answer starts with identity inventory and permission discipline.

Least privilege must be enforced across human, automation and service identities together. The compromise chain in this article only worked because each identity type handed off trust to the next. That is a lifecycle and governance problem, not a single-control problem. The implication for practitioners is to evaluate identity privilege as a connected chain from developer to pipeline to cloud role, rather than as isolated accounts.

What this signals

Identity-driven cloud attacks are forcing security teams to treat developer workstations, CI/CD workflows and cloud roles as one governance surface. The practical shift is from perimeter defence to identity-chain defence, where compromise anywhere in the chain can become cloud control.

Identity blast radius: this article illustrates why the more important question is not whether a credential is short-lived, but how far that credential can travel once it is stolen. Teams that measure privilege by reachable systems and reachable roles will see the real exposure sooner than teams focused only on token lifetime.

For practitioners

• Reduce secret density on developer endpoints Remove long-lived GitHub tokens, SSH keys, API keys and cloud credentials from standard developer workstations wherever possible, and keep local secret storage tightly scoped to active work only.
• Tighten OIDC trust between pipelines and cloud roles Review which workflows can assume which cloud IAM roles, then narrow claims, audiences and role bindings so one compromised pipeline identity cannot fan out across environments.
• Separate deployment access from identity-management rights Prevent CI/CD roles from creating or modifying administrator identities, policy attachments or privilege-bearing roles unless that function is explicitly required and justified.
• Monitor for identity reuse across repositories and cloud controls Correlate GitHub token use, service account activity, unexpected OIDC assumptions and IAM changes so stolen developer credentials cannot blend into normal release traffic.

Key takeaways

• Cloud supply chain attacks increasingly succeed by stealing and reusing trusted identities rather than by exploiting infrastructure weaknesses.
• The Nx compromise shows how a poisoned package can expose developer tokens, SSH keys, API keys and cloud credentials in a matter of hours.
• Reducing the privilege and reach of developer, pipeline and automation identities is the control that most directly limits the resulting blast radius.

Key terms

• 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.
• OIDC trust chain: The authentication path that lets a workload or pipeline exchange an identity assertion for short-lived cloud access. In practice, it links GitHub Actions or similar systems to cloud IAM roles, so the security of the cloud session depends on the scope and integrity of the upstream trust relationship.
• 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.
• Developer endpoint as an identity surface: A developer workstation or laptop becomes an identity surface when it stores, uses, or can exfiltrate reusable credentials. In practice, that means local shells, package managers, AI assistants, and browser sessions all participate in access risk, even when no production system is directly targeted.

What's in the full article

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

• Walkthrough of the Nx attack chain from workflow compromise to credential theft
• Examples of identity telemetry that can expose stolen GitHub token and OIDC activity
• Discussion of Unosecur's detection logic for privileged identity abuse across cloud and developer environments
• Implementation-focused examples for monitoring service accounts, API tokens and CI/CD roles

👉 Unosecur's full blog covers the Nx compromise, stolen credentials and cloud escalation signals 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.