Shai Hulud 2.0 exposes npm supply chain visibility gaps

At a glance

What this is: This is an analysis of Shai Hulud 2.0, an npm supply chain attack that spreads through compromised packages and hidden dependency paths.

Why it matters: It matters because identity, secrets, and deployment governance all fail when teams cannot quickly map which repositories, files, and images reference a risky package.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arnica's analysis of Shai Hulud 2.0 exposure mapping in SBOMs

Context

npm supply chain attacks exploit the gap between what teams think is installed and what actually runs in repositories, build pipelines, and container images. In this case, the primary governance failure is visibility: large codebases can inherit a malicious dependency through transitive references, outdated package pins, or reused artefacts without obvious signs of compromise.

For identity and access teams, the real issue is not only malicious code but the credentials and secrets that packaged software can reach once it executes. That makes software supply chain events a governance problem for NHI, secrets management, and release controls, not just a developer workflow problem.

Shai Hulud 2.0 reflects a familiar pattern in modern supply chain compromise: attackers use trusted distribution paths to gain durable access before defenders can map exposure. That starting position is increasingly typical, not exceptional.

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 supply chain attacks so often turn into identity incidents?

A: Because attackers are not only changing code, they are harvesting the non-human identities that code runs beside. API keys, cloud credentials, SSH keys, and registry tokens give direct access to infrastructure and publishing systems, so a compromised package becomes an identity compromise with wider blast radius.

Q: How do security teams know whether a dependency compromise reached production?

A: They need to combine SBOM review, lockfile inspection, CI build logs, endpoint telemetry, and outbound network monitoring. A package may appear only briefly in a repository but still run on a laptop or ephemeral runner. If a malicious artefact executed, assume credential exposure and verify hosts before returning them to service.

Q: Should organisations treat SBOMs as a compliance artifact or an operational control?

A: They should treat SBOMs as an operational control that feeds policy, release gating, and remediation. A static inventory helps, but it does not reduce risk on its own. The value appears when the SBOM is current, machine-readable, and linked to the decisions that approve or block delivery.

Technical breakdown

How malicious npm packages gain initial trust

npm packages become dangerous when a malicious actor publishes a dependency that looks legitimate enough to be pulled into builds or installs. Because package managers resolve direct and transitive dependencies automatically, the malicious code can enter a project through a nested reference, a stale version constraint, or a reused internal artifact. At that point, trust is inherited from the dependency graph rather than earned at runtime. The package does not need to look suspicious to a human reviewer if the build system treats it as approved input.

Practical implication: teams need dependency provenance and package allowlisting, not just repository review.

Why secrets and credentials are the real prize

Once a malicious package executes, its value comes from whatever the build or development environment exposes. That often includes API keys, tokens, cloud credentials, signing materials, and internal environment variables. In identity terms, the package becomes a transient execution foothold that can harvest NHI secrets and abuse the trust granted to automated workflows. This is why supply chain compromise often turns into identity compromise: the attacker is not only running code, but also searching for reusable credentials and privilege paths that outlive the package execution itself.

Practical implication: secrets should be isolated from build contexts and scoped so package execution cannot reach high-value credentials.

How SBOM visibility changes containment speed

A software bill of materials is only useful if it can answer operational questions quickly: where the package is used, which version is deployed, and whether the dependency exists in source or in an image. Package-centric SBOM views are designed to collapse that search problem by tying package names to repository, file, and image references. That matters because the response window in a supply chain attack is often shorter than traditional triage cycles. Visibility is not remediation by itself, but it is the prerequisite for deciding what to rotate, rebuild, or quarantine.

Practical implication: map package exposure to deployed artefacts first, then prioritise rebuild and rotation actions.

Threat narrative

Attacker objective: The attacker wants to turn dependency trust into durable access to engineering environments, secrets, and downstream production paths.

1. Entry occurs when a developer or build process pulls a malicious npm package that masquerades as a legitimate dependency.
2. Escalation follows when the package executes inside trusted engineering environments and harvests secrets, tokens, or other reusable credentials.
3. Impact arrives when the attacker uses stolen credentials or inserted backdoors to persist in build workflows, steal data, or compromise downstream systems.

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

Supply chain compromise is now an identity problem as much as a code problem. Malicious packages matter because they inherit the privileges of the environments that install them. When a dependency can reach tokens, cloud keys, or signing material, software distribution becomes an identity-control surface. Practitioners should treat package execution as a privileged event and not just a build artifact issue.

Package-centric exposure mapping is a missing control layer in modern SBOM programmes. Static inventory alone does not answer whether a vulnerable or malicious package is actually present in a repo, file, or deployed image. The governance gap here is the inability to move from theoretical exposure to verified blast radius. Teams should make package-to-image traceability a required control, not an optional convenience.

NHI governance must extend into developer tooling and CI/CD because that is where most dependency abuse lands. Supply chain attacks increasingly target reusable credentials, long-lived tokens, and build automation accounts. That means secrets lifecycle, least privilege, and runtime segmentation need to cover development systems as well as production. Practitioners should assume attacker value lies in the credentials exposed by software installation, not only in the malicious code itself.

Dependency trust debt: the longer organisations allow unresolved package exposure in sprawling repositories, the more likely transitive compromise becomes operational compromise. The problem is not size alone but the absence of fast, package-level governance that can locate impact before attackers can exploit it. Teams should shorten the path from detection to containment by designing for package-level decision-making.

Supply chain response now depends on whether governance can distinguish source risk from deployed risk. A package may exist in a repository without ever reaching a production image, and that distinction changes containment strategy. This is where the identity bridge matters: the same logic used for entitlement scoping should be applied to software artefacts and the credentials they can access. Practitioners should align remediation to verified runtime exposure, not repository presence alone.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• A separate NHIMG finding shows the average estimated time to remediate a leaked secret is 27 days, while 75% of organisations still express strong confidence in their secrets management capabilities.
• Forward look: Read The State of Secrets in AppSec to compare remediation gaps with package exposure workflows and build a tighter secrets response model.

What this signals

Package exposure governance will increasingly sit alongside secrets governance in CI/CD programmes. The practical lesson is that teams cannot separate dependency risk from identity risk when the dependency can touch cloud credentials, signing keys, or agent tokens. The next maturity step is package-level visibility tied to credential scope, not just repository scanning.

Dependency sprawl creates a control gap that SBOMs only solve when they are operationalised. A list of components is not enough unless it can be used to confirm runtime presence and trigger containment actions. Practitioners should expect package-level traceability to become a baseline expectation in software risk reviews.

NHI lifecycle controls need to extend into build systems because compromise often begins there. Short-lived credentials, segmentation, and offboarding for build identities reduce the chance that a malicious package can convert temporary execution into persistent access. The programme implication is clear: if build identities are unmanaged, supply chain defence remains incomplete.

For practitioners

• Map package exposure to deployed images Use SBOM and source-to-container mapping to determine whether the affected npm package exists only in code, in build artefacts, or in production images. Prioritise the artefacts that can actually execute in trusted environments.
• Isolate build-time secrets from package execution Remove high-value API keys, cloud credentials, and signing tokens from contexts where dependency installation or test execution can reach them. Use short-lived credentials and separate identities for build, publish, and deploy stages.
• Rebuild and rotate after confirmed exposure If the package is present in a deployed image or has accessed credentials, rebuild the affected artefact and rotate any secrets that were accessible in that environment. Do not rely on package deletion alone to close the incident.
• Enforce package provenance checks Require signed, approved, or policy-validated dependencies for production pipelines, especially where transitive packages can enter without direct developer review. Block unknown or stale references before they enter release workflows.

Key takeaways

• Shai Hulud 2.0 shows that npm supply chain attacks are really trust and identity failures in software delivery.
• Visibility into where a package exists and whether it reached a deployed image is the control that changes response speed.
• Build-time credential isolation and fast rotation matter because malicious packages often target secrets, not just code execution.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Package-Centric SBOM View: A package-centric SBOM view maps a dependency to the repositories, files, and images where it appears. It is useful because it turns inventory into an operational answer about exposure, deployment, and containment, which is what response teams need during a supply chain incident.
• Build-Time Secret: A build-time secret is a token, key, or certificate made available to automation during software compilation, testing, or deployment. These credentials are often high-value because they unlock cloud services, repositories, or registries, and they are especially dangerous when reused across multiple pipelines.
• Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.

What's in the full article

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

• Package-centric SBOM workflow showing every repo, file, and image reference for an impacted npm dependency
• Step-by-step guidance for checking whether the package reached a deployed container image
• Documentation path for using the Arnica app to list impacted packages and versions
• Demo workflow showing how to trace Shai Hulud 2.0 exposure through source code to runtime artefacts

👉 Arnica's full post covers package lookup, impacted versions, and exposure tracing across repositories and images.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls to the places where software delivery and access risk intersect.