Why do supply chain attacks so often turn into identity incidents?

Why Supply Chain Incidents Become Identity Incidents

Supply chain compromise is rarely only about malicious code. Once an attacker lands in a package, build pipeline, or dependency update flow, the fastest path to impact is usually the non-human identities attached to that system: CI tokens, signing keys, cloud access keys, registry credentials, and service principals. That is why package abuse so often becomes infrastructure abuse, secret theft, and later privilege escalation.

This pattern is visible in NHIMG research on real-world compromise paths, including the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where the blast radius came from harvested secrets rather than code tampering alone. OWASP’s OWASP Non-Human Identity Top 10 frames the same issue: once machine identities are embedded in delivery systems, attackers inherit the trust those systems already have. In practice, many security teams discover the identity layer only after a signed release or trusted pipeline has already been used as the pivot point.

How Compromise Spreads Through Build and Release Paths

The mechanics are straightforward. A malicious dependency, poisoned maintainer account, or compromised workflow gains execution inside the software delivery path. From there, attackers search for secrets in environment variables, CI logs, runner caches, package manifests, git history, and deployment scripts. If they find a long-lived credential, they can often reuse it outside the original compromise window, which turns a single event into a broader identity incident.

That is why static secrets are such a weak control in supply chain environments. Current guidance suggests shifting to short-lived credentials, workload identity, and tighter runtime authorization, because trust should be expressed at the moment of use rather than embedded permanently in code or pipelines. The 52 NHI Breaches Analysis shows how frequently machine identities and exposed secrets shape breach outcomes, while Ultimate Guide to NHIs explains why non-human identity governance has to cover creation, rotation, and revocation, not just storage.

• Use workload identity so pipelines authenticate with cryptographic proof of what they are, not with copied credentials.
• Issue JIT, task-scoped secrets for builds, releases, and deployment steps, then revoke them automatically.
• Separate signing, publishing, and deployment permissions so one compromised tool cannot fan out into multiple control planes.
• Scan repositories, logs, and artifacts continuously, because leaked secrets often outlive the incident that exposed them.

These controls tend to break down when legacy CI systems, shared runners, or ad hoc deployment scripts still depend on durable tokens because the secret becomes the identity, and the identity becomes portable.

Where the Standard Answer Breaks Down

Tighter secret controls often increase operational overhead, so organisations have to balance developer velocity against revocation discipline and pipeline reliability. That tradeoff is real, especially in fast-moving product teams where automation is fragmented across many tools and ownership is unclear.

There is no universal standard for this yet, but best practice is evolving toward policy evaluation at request time, intent-based authorisation, and short-lived workload credentials rather than broad role grants. The Anthropic — first AI-orchestrated cyber espionage campaign report shows how automated tooling can accelerate abuse once access is obtained, which is relevant to supply chains that now include AI-assisted build and release steps. For governance context, the CISA cyber threat advisories and the MITRE ATLAS adversarial AI threat matrix are useful references when supply chain tooling overlaps with model-driven automation.

Edge cases matter. Air-gapped environments, vendor-managed build services, and mono-repo release pipelines often need compensating controls because normal rotation, monitoring, and separation of duties are harder to enforce. In those environments, the right question is not just whether code is trusted, but which NHI will be trusted to move, sign, and publish that code next.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do npm supply chain attacks often become NHI governance failures?
• How should teams reduce identity risk in cloud supply chain attacks?
• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?