Identity is the real perimeter in cloud supply chain attacks

At a glance

What this is: This analysis argues that modern cloud supply chain attacks succeed by stealing and abusing identities, not by breaking traditional perimeter defences.

Why it matters: It matters because IAM, NHI, and PAM teams must treat developer workstations, CI/CD roles, and cloud tokens as shared attack surface with control gaps that span human and non-human identities.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

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

Context

Cloud supply chain attacks now target identity material first, because credentials and tokens often provide more access than the malware itself. In practice, a poisoned package, compromised workflow, or stolen developer token can turn routine software delivery into a cloud access event.

For IAM and NHI programmes, the core issue is not simply whether a system is patched. It is whether developer identities, automation roles, and short-lived tokens are governed as first-class identities with monitoring, privilege scoping, and lifecycle control.

The article’s starting point is typical of modern cloud environments: attackers do not need to defeat the perimeter if they can inherit trust through a legitimate identity path.

Key questions

Q: How should security teams reduce the risk of poisoned packages compromising cloud identities?

A: Treat package execution as a credential exposure problem, not only a software integrity problem. Isolate dependency installs, remove unnecessary secrets from developer environments, and monitor for token access during post-install activity. If a workstation can reach source control, CI/CD, and cloud systems, its local secrets should be assumed valuable to attackers.

Q: Why do CI/CD automation accounts often become the easiest path to cloud escalation?

A: Because they frequently accumulate broad permissions to keep delivery fast. When a trusted automation identity can create roles, attach policies, or call cloud control APIs, a stolen token becomes an escalation engine. The risk is highest when federation is valid but downstream privilege is loosely governed.

Q: What do security teams get wrong about OIDC in cloud pipelines?

A: They often treat OIDC as a replacement for shared secrets, rather than a trust relationship that still needs strict scoping. Short-lived credentials reduce secret persistence, but they do not remove the need to limit which workflows, claims, and repositories can exchange assertions for cloud access.

Q: How can organisations tell whether identity-driven attacks are already moving through their cloud environment?

A: Look for unusual token use, unexpected role assumptions, policy attachment events, and identity activity that does not match normal build or developer patterns. Correlating cloud logs with developer and pipeline telemetry is essential, because the attack often looks legitimate at first glance.

Technical breakdown

How poisoned packages become identity theft vectors

A malicious package does not need to exploit a memory corruption flaw to be dangerous. In this attack pattern, the post-install script runs with the developer’s local context and can search for tokens, keys, environment variables, and cached session material. Because developers often hold credentials for source control, CI/CD, and cloud platforms, the compromise becomes a credential collection exercise. The important technical point is that the package is only the delivery mechanism. The real payload is identity material that can be replayed elsewhere with full trust.

Practical implication: treat dependency execution as a credential exposure event and isolate package installation from identities that can reach production systems.

Why CI/CD OIDC trust chains are attractive to attackers

CI/CD pipelines commonly use OpenID Connect to exchange a workload assertion for temporary cloud credentials. That design reduces static secret use, but it also creates a trust bridge between the pipeline and cloud IAM. If an attacker steals the upstream identity or can inspect the workflow, they can often reuse the same federation pattern the pipeline depends on. The weakness is not OIDC itself. It is the combination of broad workflow visibility, permissive claims, and automation roles that can assume powerful cloud identities with little friction.

Practical implication: tightly scope OIDC trust policies and review which workflows can mint cloud credentials.

How identity abuse turns into privilege escalation

Once an attacker authenticates with a stolen token or automation account, the next step is usually role discovery and permission chaining. Over-privileged CI/CD roles are especially valuable because they can modify infrastructure, create new IAM roles, or attach administrator policies. That turns a single stolen identity into a pivot point across the cloud control plane. Detection also becomes harder because the activity looks legitimate at the protocol level. The attacker is not breaking authentication. They are using it exactly as designed, but with stolen or misused trust.

Practical implication: monitor role assumptions, policy attachment events, and identity permission changes as high-priority escalation signals.

Threat narrative

Attacker objective: The attacker aims to convert trusted development identities into cloud administrative access and persistent control of delivery infrastructure.

1. Entry occurs when malicious code is injected into a package release workflow and reaches developer systems through a trusted dependency install path.
2. Credential access follows when the payload searches for GitHub tokens, SSH keys, API keys, environment variables, and cloud credentials on the host.
3. Escalation occurs when stolen developer and automation identities are reused to inspect CI/CD workflows, assume cloud roles, and reach broader IAM privileges.
4. Impact is the ability to move from a developer workstation into repositories, pipelines, and cloud administration paths with legitimate-looking access.

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 is now the cloud perimeter, not the network boundary. The article correctly shows that attackers no longer need to defeat firewalls when developer tokens, service identities, and CI/CD credentials already carry the trust needed to move. That shifts the governance problem from perimeter defence to identity control across the software delivery chain. Practitioners should treat every credential that can reach cloud control planes as part of the attack surface.

Credential collection is the real payload of supply chain malware. The malicious package is only the first-stage delivery mechanism. Once it executes on a developer system, the attacker inherits a dense concentration of live secrets, and that concentration is what makes cloud compromise so fast. The lesson for IAM and NHI teams is that workstation identities and stored secrets must be governed together, not as separate domains.

Automation identities become escalation engines when they are allowed to accumulate privilege. CI/CD roles often start narrow and then absorb access over time as deployment demands grow. That creates a standing pathway from routine build activity to policy modification, role creation, and cloud takeover. The practical conclusion is that privilege creep in automation is not technical debt in the abstract. It is pre-positioned breach capacity.

Least privilege for cloud delivery must be measured at the role chain, not the login event. The article shows that a legitimate authentication step can still lead to catastrophic abuse if the downstream role can mint higher privilege or modify IAM itself. That means governance has to examine what an identity can become after federation, not just what authenticated successfully at the start. Practitioners should review effective privilege, not just nominal access.

Identity blast radius: the size of the compromise that follows one stolen developer or automation identity now defines cloud security maturity. This is the right named concept for the pattern described here because the issue is not a single leaked token, but how far that token can propagate into repositories, pipelines, and cloud administration. Teams that cannot map blast radius by identity will keep underestimating supply chain exposure. Practitioners should reduce every identity to its reachable blast radius.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• That governance gap is one reason to read OWASP NHI Top 10 for the controls that matter when identities act at runtime.

What this signals

Identity blast radius: cloud programmes should now measure how far a single stolen token can travel across source control, build systems, and cloud administration. That means tuning monitoring around reachable privilege, not just successful authentication. With 70% of organisations granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, over-assignment is no longer an edge case.

The practical signal for security teams is that identity governance and supply chain security are converging. A dependency compromise can now become an IAM event, which means developer telemetry, federation policy, and cloud audit trails need to be analysed as one control plane rather than separate domains.

Teams that already track service accounts, API keys, and workload identities should extend the same controls to developer workstations and CI/CD trust chains. The governing question is no longer whether the package is trusted, but whether the identity it can reach is over-trusted.

For practitioners

• Harden developer credential stores Remove long-lived cloud credentials, GitHub tokens, SSH keys, and API keys from local workstations wherever possible. Where storage is unavoidable, separate build access from administrative access and monitor for bulk secret access during dependency installation.
• Constrain CI/CD federation paths Scope OpenID Connect trust policies to specific repositories, workflows, branches, and claims. Require each automation identity to assume only the minimum cloud role needed for the job, and block workflows that can mint broader privileges.
• Audit automation privilege creep Review every CI/CD role for ability to create IAM roles, attach administrator policies, or alter security controls. If a deployment identity can change its own permissions or create new ones, treat that as an escalation path, not a convenience.
• Detect identity misuse at the cloud control plane Alert on unusual token usage, unfamiliar login locations, unexpected role assumptions, and high-risk IAM events such as policy attachments or role creation. Correlate these signals with developer and pipeline activity to find the first legitimate-looking abuse.

Key takeaways

• Cloud supply chain attacks increasingly succeed by abusing developer and automation identities rather than exploiting a classic software vulnerability.
• The scale of the risk is driven by dense secret exposure, broad CI/CD trust chains, and privilege creep in automation roles.
• The control that matters most is reducing identity blast radius through scoped federation, secret minimisation, and identity-focused detection.

Key terms

• Identity Blast Radius: The amount of access an attacker can reach after compromising one identity. In cloud and delivery environments, blast radius is shaped by credential scope, role chaining, and whether a stolen token can reach repositories, pipelines, or production control planes.
• CI/CD Trust Chain: The authentication path that allows build and deployment systems to exchange assertions for cloud access. It is useful because it removes static secrets, but it also concentrates risk where claims, repositories, and roles are too broadly trusted.
• Automation Identity: A non-human identity used by pipelines, scripts, or deployment systems to perform actions without human interaction. These identities often need elevated access to function, which makes scope control and monitoring essential to prevent escalation.
• Federated Cloud Credential: A short-lived cloud credential issued after an external identity assertion is validated. Federation reduces password and secret persistence, but the effective security depends on how tightly the trust policy limits who can exchange the assertion and what role they receive.

What's in the full article

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

• Step-by-step detection logic for compromised credentials across developer, CI/CD, and cloud control planes
• Specific identity telemetry examples for unusual token use, role assumptions, and administrator policy changes
• Operational guidance for monitoring service accounts, API tokens, and automation identities in cloud environments
• The article’s own walk-through of how Unosecur correlates identity signals across multiple layers

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

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.