What should organisations do when npm supply chain compromise is suspected?

Why This Matters for Security Teams

A suspected npm compromise is rarely just a package integrity issue. It is often an identity event that can expose build tokens, GitHub credentials, runner registrations, and downstream publishing rights. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on Shai Hulud npm malware campaign shows that package compromise often becomes persistence through secrets and automation, not just code injection.

The practical risk is that a malicious dependency can execute during install, reach CI/CD credentials, and plant footholds that survive package removal. That is why response has to include both software supply chain hygiene and Non-Human Identity controls: token rotation, workflow review, and runner validation. NHIMG’s 52 NHI Breaches Analysis repeatedly shows that identity misuse is what turns a contained event into a wider compromise.

In practice, many security teams discover the real blast radius only after a build system has already published malicious artifacts or reused stolen automation credentials.

How It Works in Practice

The first objective is to assume the compromised package may have executed with whatever identity the build process exposed. That means removing the package is necessary but not sufficient. Teams should rebuild from a clean dependency lockfile, clear caches, and revoke any secrets that could have been present during install. If the pipeline used npm tokens, GitHub personal access tokens, deployment keys, or cloud credentials, treat them as exposed until proven otherwise.

Operationally, response works best when it is sequenced around identity containment:

• Identify all affected repositories, workspaces, and package versions.
• Recreate builds in a clean environment with fresh dependencies.
• Rotate tokens and certificates used by CI/CD, package publishing, and repository automation.
• Inspect GitHub workflows, runner registrations, and self-hosted runner images for persistence.
• Review repository history for new secrets, injected scripts, or altered publish steps.

This is consistent with lessons from the Reviewdog GitHub Action supply chain attack, where compromise propagated through workflow trust rather than package code alone. It also aligns with the control intent behind the OWASP Non-Human Identity Top 10, which treats machine credentials as primary attack surface, not byproducts.

Where possible, validate runner provenance, enforce short-lived credentials, and require reauthentication for publish paths. These controls tend to break down in sprawling monorepos with shared self-hosted runners because one compromised workflow can inherit broad permissions across many packages.

Common Variations and Edge Cases

Tighter response procedures often increase build downtime and developer friction, requiring organisations to balance speed of containment against release pressure. That tradeoff is real, especially when the compromised dependency sits deep in a shared toolchain or when multiple teams publish from the same automation account.

There is no universal standard for exactly how far to roll back a suspected npm compromise. Current guidance suggests using the narrowest safe rebuild window, but expanding containment if any of the following are true: the package had install-time scripts, the CI runner was persistent, secrets were mounted into the job, or the workflow had write access to repositories and registries.

Edge cases also matter. Private repositories are not inherently safe, and internal package mirrors can still propagate malicious code if they cached the compromised artifact before detection. The most reliable indicator is not whether a repo was public, but whether the automation identity had standing privilege. NHIMG’s research on the Ultimate Guide to NHIs — Why NHI Security Matters Now is clear that this is the real control boundary.

When npm compromise is suspected in environments with shared runners, long-lived publish tokens, or mirrored artifacts, the guidance breaks down because a single package event can leave multiple identity-based footholds that survive simple dependency removal.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers turn stolen npm secrets into broader compromise?
• Why do service account and maintainer tokens increase supply-chain risk?
• What did Shai Hulud 2.0 actually compromise?