Dependency confusion in NPM supply chains is now an identity problem

At a glance

What this is: Panther’s analysis describes a 38-package NPM supply chain campaign that used dependency confusion and postinstall hooks to steal credentials from developer and CI/CD environments.

Why it matters: It matters because build pipelines often hold the same secrets and access paths that identity teams try to protect elsewhere, so package trust is now part of NHI and access governance.

By the numbers:

• 27 days
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Panther's analysis of the 38-package NPM supply chain campaign

Context

Dependency confusion is a supply chain technique where an attacker publishes a public package that looks like an internal dependency, causing build systems to resolve the malicious package instead of the private one. In this campaign, the primary security failure is not simply malware in NPM, but the trust model that lets package naming, install-time execution, and developer convenience override explicit validation of what is allowed into the pipeline.

For IAM and NHI practitioners, the identity issue is immediate. CI/CD runners, build tools, service tokens, cloud credentials, SSH keys, and package publishing tokens behave like non-human identities, yet they are often governed as implementation detail rather than privileged access. That gap makes dependency confusion a governance problem as much as a malware problem.

The article’s starting point is typical of modern software supply chain attacks: the adversary did not need to breach an endpoint first. They targeted the place where software builds, secrets, and automation already intersect, which is exactly where identity boundaries become easiest to ignore and hardest to reconstruct.

Key questions

Q: What breaks when dependency confusion is allowed in CI/CD pipelines?

A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft. The failure is not only malware execution. It is the loss of control over where code comes from and what identity-bearing material the runner exposes during install.

Q: Why do CI/CD runners and build tools increase NHI risk?

A: They often hold cloud tokens, publishing credentials, SSH keys, and database secrets that behave like non-human identities. When those identities are long-lived or broadly scoped, a single package execution can expose multiple environments. That is why build infrastructure needs the same governance discipline as other privileged identity surfaces.

Q: How do security teams know whether package installation risk is under control?

A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment. If developers can still install arbitrary lifecycle hooks with broad credentials present, the risk is not under control. Strong secrets hygiene alone is not enough if execution itself remains trusted.

Q: What should teams do after a malicious repository or package is discovered?

A: Contain the repository, revoke any credentials that could have been exposed, and rotate secrets used by the affected developer and CI paths. Then inspect adjacent repositories for reused tokens, copied package names, and shared maintainer identities. The goal is to cut off both the delivery path and any persisted non-human access.

Technical breakdown

How dependency confusion turns naming into an access path

Dependency confusion works because package managers may prefer a higher-versioned public package when a private/internal dependency is not resolved with strict registry controls. Attackers exploit internal naming conventions, then publish malicious lookalikes that trigger during standard installs. In CI/CD, that means the package does not need a human click. It only needs the build system to trust the registry outcome. Once execution starts, the malicious code inherits the environment’s privileges and can inspect variables, local config, and token material.

Practical implication: lock registry resolution rules, not just package lists, so internal dependencies cannot be satisfied from public sources.

Why postinstall hooks are so effective in build environments

A postinstall hook runs automatically after a package is installed, which makes it a high-leverage execution point for supply chain abuse. Developers often expect helper scripts, audits, or checks to run there, so malicious packages can hide in routine package lifecycle behaviour. In a CI/CD context, the hook inherits whatever secrets the runner has available, including cloud auth material, NPM tokens, SSH keys, and kubeconfigs. That turns a standard dependency install into a secret collection event before defenders have any runtime visibility.

Practical implication: treat install-time scripts as executable code and restrict them in pipeline policy wherever business use allows.

Why rotating publisher accounts increase campaign resilience

Account rotation helps the attacker survive takedown by spreading the campaign across multiple publisher identities, names, and package clusters. The article shows this with coordinated account handoffs and consistent aliasing across multiple package families. Technically, the content and tooling matter more than a single username because the exfiltration framework can persist even if one account is removed. That is the same structural problem identity teams see with ephemeral service credentials: if ownership, provenance, and revocation are weak, shutting one identity does not dismantle the campaign.

Practical implication: couple package provenance review with publisher reputation, revocation, and rapid quarantine of related identities.

Threat narrative

Attacker objective: The attacker aimed to steal high-value developer and CI/CD credentials while positioning for broader package ecosystem compromise through trusted publish accounts.

1. Entry occurred through dependency confusion, where malicious public NPM packages were resolved in place of expected internal dependencies during normal build activity.
2. Credential access followed through postinstall execution that harvested environment variables, cloud tokens, SSH keys, database secrets, and publishing credentials from CI/CD systems.
3. Impact came from exfiltration and potential downstream package compromise, because stolen publisher tokens could be used to seed more trusted malicious releases.

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

Dependency confusion is now an identity boundary failure, not just a package hygiene issue. The article shows that the exploit succeeds when build systems treat external registry resolution as trustworthy by default. Once a CI/CD runner installs the wrong package, it exposes secrets that should have been isolated as non-human identities with clear ownership, scope, and revocation. Practitioners should read this as a governance failure in the software delivery identity layer.

Install-time execution has become a privileged access moment. Postinstall hooks blur the line between dependency management and runtime code execution, which means package installation can no longer be treated as a low-risk maintenance event. The relevant control question is whether build systems are allowed to execute arbitrary code before provenance, policy, and secret boundaries are enforced. Teams should treat that boundary as an access control decision, not a developer convenience.

Build pipelines now hold the secrets most worth stealing. Cloud credentials, package publishing tokens, SSH keys, and database secrets are all non-human identities in practice, even when teams do not model them that way. The article’s package clusters show how attackers specialise exfiltration by environment, which is exactly what makes centralised secrets governance and scoped token ownership essential. Practitioners should assume the build plane is part of the identity estate.

Account rotation and alias reuse are the attacker’s resilience model. The campaign did not depend on a single publisher identity, which means takedown alone does not equal containment. That mirrors a broader NHI problem where ownership, lifecycle, and provenance controls are weaker than the credentials themselves. The named concept here is build-plane identity drift, where automation identities, publisher accounts, and secret-bearing services outgrow the governance model meant to contain them. Practitioners should map those identities before the next campaign does it for them.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader control lens, see OWASP Non-Human Identity Top 10 for the governance patterns most often missed when secrets, automation, and access controls overlap.

What this signals

Build-plane identity drift: CI/CD runners, publisher tokens, cloud credentials, and SSH keys are often managed as implementation detail, but attackers already treat them as a governed identity layer. If your pipeline can execute arbitrary install-time code with access to secrets, your NHI programme is already exposed at the software delivery boundary. Review secret ownership, runtime exposure, and registry trust as one control surface, not three.

The practical signal here is that secrets leakage is no longer a post-incident cleanup issue. It is a standing governance problem for pipeline design, especially where package managers, automation accounts, and publishing credentials intersect. Teams should align build controls with the same least-privilege logic used in PAM and NHI governance, then validate those controls against package resolution behaviour and install-time execution.

As a control benchmark, pair internal registry enforcement with the NIST SP 800-53 Rev 5 Security and Privacy Controls families most relevant to access, authentication, and configuration management. That combination matters because supply chain attacks increasingly target credentials before they target applications, and the environment that runs the build is often the environment that leaks the most.

For practitioners

• Enforce private-registry resolution for internal dependencies Require build systems to resolve internal package names only from approved private registries, and block fallback to the public registry for reserved namespaces such as *-internal-* patterns. Review package manager configuration in every CI/CD runner.
• Disable or tightly gate install-time scripts Restrict postinstall and similar lifecycle hooks in pipeline policy, especially for packages that do not require script execution to build. Where scripts are unavoidable, run them in isolated environments with no secret material present.
• Classify CI/CD secrets as privileged non-human identities Inventory NPM tokens, cloud credentials, SSH keys, kubeconfigs, and database secrets as governed identities with owners, expiry, and revocation paths. Apply least privilege and separate publishing tokens from build-time access where possible.
• Quarantine publisher identity patterns after compromise signals When one publisher account is confirmed malicious, search for related aliases, naming structures, and account rotation patterns before the next package release lands. Tie blocking decisions to the publisher cluster, not only to the single package hash.

Key takeaways

• Dependency confusion turns build systems into identity leakage points when package resolution and secret exposure are not separately controlled.
• The campaign’s 38 malicious packages show how account rotation, postinstall execution, and credential harvesting combine into a resilient supply chain threat.
• Teams should treat CI/CD secrets, publisher tokens, and registry trust as one governed identity problem rather than disconnected operational issues.

Key terms

• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Postinstall Hook: A script that runs automatically after a package is installed. In practice, it can function as an execution trigger for malicious code because developers and build systems often allow it to run with broad file, network, and environment access during dependency installation.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Publisher Account Rotation: The deliberate use of multiple package publishing identities to continue a campaign after detection or takedown. This tactic weakens response if defenders focus on one account rather than the shared infrastructure, naming patterns, and credential relationships behind the activity.

What's in the full report

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

• Package-by-package breakdown of the 38 malicious NPM artifacts and how each impersonation cluster was structured
• The actor-attribution evidence behind the rotating publisher accounts and recurring alias patterns
• The exfiltration targets observed in each cluster, including cloud tokens, SSH keys, database secrets, and publish credentials
• The technical indicators and package traits defenders can use to hunt similar dependency confusion activity

👉 Panther's full post covers the actor clusters, exfiltration paths, and package-level indicators of compromise

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It is designed for practitioners who need a practical framework for governing automation identities across the wider security programme.