Identity is the new cloud perimeter in Nx-style supply chain attacks

At a glance

What this is: This is Unosecur's analysis of the 2025 Nx supply chain compromise, arguing that stolen developer and automation identities, not the package itself, became the real attack path into cloud environments.

Why it matters: It matters because IAM, PAM, NHI and cloud security teams need to treat developer tokens, CI/CD roles and service identities as perimeter controls, not just implementation details.

👉 Read Unosecur's analysis of the Nx supply chain compromise and cloud identity risk

Context

Cloud security has traditionally assumed attackers would break in through exposed systems, misconfigurations or unpatched software. The Nx compromise shows a different pattern: attackers can enter by executing code that steals already trusted identities, then move through the environment as if they belong there.

For identity programmes, the critical issue is not only secret exposure but the trust placed in developer workstations, CI/CD authentication flows and automation roles. Once those identities are abused, the cloud control plane can be reached without a conventional exploit chain.

Key questions

Q: What breaks when a malicious npm package can read developer secrets during install?

A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.

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: What signs show that a stolen token or service identity is being abused?

A: Look for token use from unfamiliar locations, unexpected repository reads, unusual OIDC role assumptions, abnormal API activity and privilege changes that do not match the normal deployment pattern. The key is correlation across systems, because any single action may still look legitimate in isolation.

Q: How should teams separate credential hygiene from identity governance in cloud supply chains?

A: Credential hygiene removes exposed secrets, but identity governance controls who can use them, what they can do and how long that trust should last. Teams need both. Without privilege boundaries, lifecycle review and monitoring, a clean secret store can still support a compromised automation path.

Technical breakdown

How malicious package execution turns a workstation into an identity source

The Nx compromise used a poisoned package to run post-install code on developer systems, where it searched for GitHub personal access tokens, npm tokens, SSH private keys, API keys, cloud credentials and secret-bearing environment variables. This is a credential harvesting pattern, not a pure malware event. The attacker does not need to exploit the cloud first. They exploit the developer environment, because that environment already holds the keys needed to authenticate to code hosting, build systems and cloud platforms.

Practical implication: protect developer endpoints as identity-bearing systems and assume package execution can expose live secrets immediately.

Why CI/CD identity is a high-value escalation path

Modern pipelines often authenticate to cloud providers through federated trust, such as OIDC from GitHub Actions into a cloud IAM role. That design removes static cloud keys, but it also creates a reusable trust chain that attackers can abuse once they obtain a legitimate token or workflow credential. If the automation role is overprivileged, a compromise can progress from pipeline access to infrastructure changes, IAM modification and higher privileged roles.

Practical implication: map every CI/CD trust relationship and limit the privileges of deployment identities to the smallest possible cloud scope.

Why identity abuse is harder to detect than code compromise

When attackers use stolen credentials, the activity often resembles normal administration. Token use, role assumption and repository access can all be legitimate actions in the right context, which makes anomaly detection and identity telemetry essential. The control problem shifts from blocking executable malware to spotting impossible travel, unusual token usage, suspicious role assumptions and unexpected IAM changes across cloud and developer systems.

Practical implication: build detection around identity behaviour and privilege changes, not only endpoint malware alerts.

Threat narrative

Attacker objective: The attacker objective was to steal trusted identities that could be reused to move from developer execution into cloud and pipeline control.

1. Entry occurred when attackers injected malicious code into the Nx release pipeline and published modified packages that developers installed as trusted dependencies.
2. Credential access followed when the post-install script scanned developer systems for GitHub tokens, SSH private keys, API keys, cloud credentials and secret-bearing environment variables.
3. Escalation occurred when the stolen identities were used to inspect repositories, examine CI/CD workflows, identify automation accounts and reuse trusted cloud authentication paths.
4. Impact was the potential path from a developer machine into repositories, pipelines and cloud infrastructure, including the possibility of broader administrative control.

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 real cloud perimeter: The Nx compromise confirms that attackers do not need to defeat the cloud boundary if they can steal the identities that already cross it. Developer tokens, automation roles and service identities have become the practical perimeter because they are the credentials that authorize cloud actions. The practitioner conclusion is that cloud defence now depends on governing trust relationships, not only infrastructure exposure.

Developer workstations are identity vaults in disguise: The article shows that a single post-install script can surface a dense cluster of credentials from a machine that developers and security teams often treat as a productivity endpoint. That assumption fails because the workstation is where authentication material is concentrated, reused and quietly accumulated. The practitioner conclusion is to treat developer environments as high-value identity stores with their own lifecycle risk.

Trust relationships have replaced static cloud keys as the escalation surface: The shift to OIDC-backed CI/CD authentication improves key hygiene, but it does not eliminate identity abuse. It moves the attack surface into federated trust, where a compromised workflow identity can still assume powerful cloud roles and create a rapid privilege escalation path. The practitioner conclusion is to govern the trust chain itself, not just the secret it replaces.

Standing privilege in automation is now a cloud takeover accelerant: CI/CD roles often gain permissions organically and silently, which creates a path from legitimate deployment access to administrator-level changes. That is not a tooling problem alone; it is a governance failure in how machine identities are reviewed, scoped and allowed to mutate over time. The practitioner conclusion is that automation privilege must be treated as a lifecycle issue, not a one-time setup task.

Identity-driven supply chain attacks expose a runtime governance gap: Access review cadences were designed for access that persists long enough to be certified. That assumption fails when malicious code can harvest credentials, use them immediately and pivot before any review cycle can meaningfully intervene. The practitioner conclusion is that identity governance must move closer to issuance, authentication and runtime observation.

What this signals

Identity blast radius now defines cloud supply chain risk: The question is no longer whether code can execute unexpectedly, but how far a harvested credential can move once it does. In practice, the most important control is not malware blocking at the edge, but limiting what any single developer or automation identity can reach inside the cloud.

Federated trust needs lifecycle governance, not just authentication design: OIDC and temporary credentials reduce static secret exposure, but they also make trust chains more important to review. Teams should assume every deployment identity can become an escalation bridge unless its scope, rotation and delegation boundaries are continuously governed.

For practitioners

• Audit developer credential density Map which secrets are present on developer endpoints, in browser stores, local config files and environment variables, then reduce the number of live credentials available to any single workstation.
• Constrain CI/CD trust chains Review every OIDC trust relationship, deployment role and automation account to confirm the pipeline can only assume the minimum cloud permissions required for release activity.
• Separate deployment from privilege creation Prevent automation identities from creating or modifying IAM roles, policies or higher privileged accounts so a compromised pipeline cannot manufacture administrator access.
• Detect abnormal token use and role assumption Correlate token usage, repository access, unusual login locations and unexpected OIDC role assumptions across developer, SaaS and cloud logs.
• Treat package execution as credential exposure Flag unexpected install-time scripts in dependency pipelines and investigate any package that attempts filesystem discovery, secret scanning or outbound uploads.

Key takeaways

• The Nx compromise shows that supply chain attacks can become identity attacks the moment malicious code steals live credentials from developer systems.
• Developer tokens, CI/CD roles and service identities create a large attack surface because they are trusted to authenticate across repositories, pipelines and cloud control planes.
• Limiting privilege, reducing credential density and monitoring identity behaviour are the controls that matter when attackers do not break in, they log in.

Key terms

• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• 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.
• Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.
• Identity-driven supply chain attack: A supply chain compromise in which malicious code or poisoned dependencies are used to steal credentials and then abuse those identities for downstream access. The central risk is not the package itself but the trust it can inherit and reuse.

What's in the full article

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

• The specific Nx release pipeline abuse that enabled malicious package publication
• The exact classes of credentials harvested from developer systems during execution
• The identity telemetry used to spot abnormal token use and suspicious OIDC role assumptions
• How the vendor correlates endpoint, SaaS and cloud signals across the attack chain

👉 Unosecur's full post covers the attack chain, credential exposure and identity detection details.

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.