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

At a glance

What this is: This is an analysis of the Nx supply chain compromise and the shift from network intrusion to identity abuse in cloud environments.

Why it matters: It matters because IAM, NHI, and cloud security teams need to treat developer credentials, automation roles, and OIDC trust paths as primary attack surfaces.

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

Context

Cloud supply chain attacks now succeed by abusing identities that already have trusted access, rather than by exploiting a new server-side flaw. In this case, a malicious package in the Nx ecosystem harvested developer credentials and used them to move from endpoint access into repositories, CI/CD pipelines, and cloud control planes, which is a direct NHI governance problem because those tokens, keys, and automation identities are the real perimeter.

The more automation becomes embedded in software delivery, the more privilege shifts from human operators to service accounts, tokens, and federated roles. That changes the security question from how to stop login attempts to how to govern trust relationships, credential scope, and escalation paths across the build and deployment chain. The Nx compromise is a familiar pattern, not an anomaly, which means most enterprises should assume they are closer to this model than they admit.

Key questions

Q: How should teams reduce identity risk in cloud supply chain attacks?

A: Start by inventorying every developer and automation identity that can reach repositories, build systems, and cloud roles. Then remove unnecessary permissions, segment trust between environments, and monitor for unusual token use or role assumptions. The goal is to make stolen credentials less reusable across the delivery chain and to shrink the blast radius of any one compromise.

Q: Why are CI/CD identities so dangerous when compromised?

A: CI/CD identities are dangerous because they often sit on trusted authentication paths and carry permissions that extend beyond deployment. A compromised pipeline role can be used to access cloud resources, modify configurations, or in badly designed environments alter IAM policy itself. That turns delivery automation into an escalation bridge instead of a control.

Q: What is the difference between static secrets and federated workload credentials?

A: Static secrets are reusable credentials stored for later use, while federated workload credentials are issued through a trust exchange such as OIDC and expire quickly. Federated credentials reduce secret sprawl, but they still depend on tightly scoped roles and trustworthy workflow controls. If the role is over-privileged, the short lifespan does not eliminate the risk.

Q: When does least privilege matter most for cloud automation?

A: Least privilege matters most when automation can reach production, modify infrastructure, or touch identity policy. In those cases, even a short-lived credential can have broad impact if the role is over-scoped. Teams should review automation permissions whenever a workflow can create resources, change access, or assume additional roles.

Technical breakdown

How package poisoning turns developer identities into entry points

Package poisoning is a supply chain technique where an attacker inserts malicious code into a trusted dependency or release workflow so the code executes in a developer environment. In the Nx case, the important detail is not the package itself but the credentials present on the workstation. Build tools, token caches, SSH keys, and cloud credentials often coexist on the same machine, so a single post-install script can exfiltrate multiple identity types at once. That creates a high-density identity harvest point, which is why endpoint compromise quickly becomes cloud access compromise.

Practical implication: Protect developer workstations as identity-rich environments and treat dependency execution as a credential exposure event.

OIDC trust chains and CI/CD role abuse

Modern CI/CD systems often use OIDC to exchange a workload assertion from the pipeline for temporary cloud credentials. That design removes static secrets, but it also creates a strong trust bridge between the code platform and the cloud IAM role. If an attacker steals the pipeline token or learns the workflow structure, they can imitate the trusted build identity and request the same role assumptions used by legitimate automation. The security failure is usually not OIDC itself. The failure is over-broad role scope, weak workflow governance, and poor segmentation between deployment identities and administrative permissions.

Practical implication: Limit each pipeline identity to the smallest possible cloud role and review every OIDC trust policy as if it were a privileged access grant.

Privilege escalation through automation identities

Automation identities often accumulate permissions over time because teams add access to fix delivery friction. A CI/CD role that originally deployed resources may eventually gain permission to alter IAM policies, create new roles, or attach administrator rights. Once compromised, that role becomes an escalation bridge from ordinary deployment access to full cloud control. This is why identity abuse is harder to notice than traditional intrusion. The actions look like legitimate administration unless the environment tracks unusual role assumptions, token usage, and permission changes in context.

Practical implication: Inventory automation roles by effective privilege and remove any path that allows deployment identities to modify IAM itself.

Threat narrative

Attacker objective: The attacker’s objective was to convert a software supply chain foothold into trusted cloud access and administrative reach.

1. Entry via malicious code embedded in a trusted Nx package that executed in a developer environment and searched for stored credentials.
2. Escalation through theft of GitHub tokens, SSH keys, API keys, and cloud credentials from that workstation.
3. Impact when stolen identities were used to inspect repositories, probe CI/CD workflows, and reach cloud control plane permissions.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity blast radius is now the central cloud security metric. The Nx compromise shows that the useful unit of analysis is no longer the host or even the workload, but the reach of a stolen identity. When a developer token or CI/CD role can touch repositories, pipelines, and cloud roles, the blast radius expands faster than most teams can detect. Practitioners should measure and reduce identity blast radius before they try to perfect detection.

Package poisoning is a governance failure, not just a malware problem. The attack succeeded because trusted build channels were allowed to carry credential exposure across environments. That means source control hygiene, pipeline trust, and cloud IAM policy are part of the same control plane. Teams that separate these domains operationally will keep missing the real risk path.

Ephemeral credentials do not solve over-privilege by themselves. Temporary tokens reduce persistence, but they still inherit whatever permissions the role grants at issuance time. If the automation role is over-scoped, an attacker only needs a short window. Least privilege, workflow segmentation, and role review remain the decisive controls.

NHI governance must cover developer systems as identity concentration points. The workstation is where human and non-human identities intersect, which makes it a high-value target for secret harvesting. Governance that only watches cloud logs is already too late. Practitioners need policies that treat developer endpoints, CI/CD identities, and cloud roles as one chained risk surface.

Identity-driven attacks are becoming the default supply chain pattern. The broader market signal is that attackers increasingly prefer trusted execution paths over noisy exploit chains. That shifts NHI security from a narrow secrets-management conversation to a lifecycle problem that includes issuance, use, escalation, and recovery. Security teams should plan accordingly.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, which shows that governance maturity is still lagging behind exposure.
• The next step is to apply the same visibility discipline to build systems and automation accounts, using OWASP NHI Top 10 as the control lens for identity sprawl.

What this signals

Identity concentration points are becoming the highest-value targets in software delivery. When developer endpoints, CI/CD platforms, and cloud roles share credential pathways, a single compromise can produce outsized access. That is why practitioners should treat lifecycle control, not perimeter hardening, as the primary response to supply chain identity abuse. The governance model needs to follow the credential across systems, not the other way around.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the broader pattern is clear: identity visibility still breaks down at the edges of trust relationships. The same blind spot now exists inside build and deployment paths, where automation identities are often less visible than human users. Security programmes that cannot explain who can assume what role, and from where, are already behind.

Trust-path governance: teams should begin mapping the exact chain from source control to cloud action and retire any trust step that is not necessary. That includes reviewing OIDC policies, role assumptions, and administrative permissions together rather than as separate tickets. For practitioners, this is the point where NHI control becomes an architectural discipline, not an audit exercise.

For practitioners

• Map the full identity chain from workstation to cloud Document every credential a developer can use, including GitHub tokens, SSH keys, API keys, OIDC roles, and service accounts. Then trace which repositories, pipelines, and cloud resources each identity can reach. This makes the identity blast radius visible before an attacker does.
• Tighten OIDC trust policies for CI/CD roles Scope each pipeline role to one deployment purpose, one environment, and one account boundary. Remove permissions that allow role creation, policy attachment, or downstream IAM changes unless they are explicitly required and time-bound.
• Monitor abnormal token use and role assumption patterns Alert on GitHub tokens used from unfamiliar locations, service accounts performing unexpected actions, and unusual OIDC role assumptions. Correlate identity signals with endpoint events so a suspicious package install is treated as a credential incident, not just a developer issue.
• Remove IAM modification rights from automation identities Review CI/CD roles for any ability to alter IAM permissions, create new identities, or attach administrator policies. If a deployment identity can change access policy, compromise of that role becomes a cloud takeover path.

Key takeaways

• Supply chain compromise has become an identity problem because developer credentials can unlock repositories, pipelines, and cloud control planes.
• Automation identities often carry enough privilege to turn a single stolen token into cloud-wide escalation.
• Teams should reduce identity blast radius, tighten OIDC trust, and monitor abnormal token and role behavior as one control set.

Key terms

• Identity Blast Radius: The total reach a stolen identity can have across systems, data, and administrative controls. In cloud and NHI environments, blast radius depends on role scope, trust relationships, and whether the identity can trigger downstream access or policy changes.
• CI/CD Automation Identity: A non-human identity used by build and deployment systems to authenticate to code repositories, cloud platforms, and internal services. These identities often have broad permissions and are attractive targets because compromise can move directly from software delivery into infrastructure control.
• OIDC Trust Policy: A rule set that allows a workload or pipeline to exchange an assertion for temporary cloud credentials. The policy defines who can assume the role, from where, and under what conditions, which makes it a critical control point for preventing token abuse.
• Package Poisoning: A supply chain attack in which a trusted software package or release workflow is modified so that malicious code runs in a downstream environment. The immediate technical effect is code execution, but the strategic goal is often secret theft or identity abuse.

What's in the full article

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

• The article breaks down the full Nx attack chain from malicious package execution to credential harvesting and cloud escalation.
• It lists the identity signals that appear on developer endpoints, in CI/CD activity, and in cloud control plane logs.
• It shows how Unosecur positions identity threat detection and response across secrets, sessions, and privileges.
• It includes the specific detection patterns the vendor says it uses for abnormal token use, role assumption, and IAM changes.

👉 The full Unosecur post covers the attack chain, detection signals, and cloud escalation path in more detail.

Deepen your knowledge

Developer identity exposure and CI/CD trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to secure software delivery paths with the same discipline you apply to human access, the course is a practical next step.