npm Supply Chain Attacks: Risks and Protection of Software Dependencies

Why npm supply chain attacks affect developers

High-profile supply chain attacks such as the insertion of a backdoor into SolarWinds in 2020 or the near-global compromise of OpenSSH server software via a backdoor in XZ Utils in 2024 attracted international attention. Companies mostly responded with short-term measures. As serious as these cases are, they often divert attention from the actual risk: everyday but frequently overlooked supply chain attacks on software libraries and software dependencies.
Attacks against the Node Package Manager (npm) – the standard package manager of the JavaScript runtime environment Node.js – in recent weeks have clearly highlighted the current threat landscape:

• An as-yet unknown threat actor carried out successful attacks against npm in August, September and November. In the process, malicious code labelled by the attacker as Shai-Hulud, exhibiting worm-like behaviour, was injected into legitimate packages. The result was the automatic compromise of build pipelines, repositories and stored secrets, which were then abused to compromise additional packages. In this way, more than 750 npm packages were compromised.
• In mid-September, individual developers of very widely used npm packages (for example debug, chalk, etc.) were also targeted, with the aim of deliberately injecting malware. Since the malicious code was directed exclusively at Web3 and cryptocurrency transactions, the direct damage remained limited; however, the incident reveals a massive structural weakness in the open-source ecosystem itself.

Although GitHub, Inc., the parent company of npm, has already announced extensive security measures for the Node Package Manager, organisations are still required to take action themselves: by consistently applying measures from the secure software development lifecycle (SSDLC) in order to independently increase their resilience against supply chain attacks. 

Shai-Hulud and the mechanisms of supply chain attacks

The risk potential of compromised software dependencies becomes particularly evident in successful attacks on continuous integration and continuous deployment (CI/CD) environments.
A striking example is the Shai-Hulud attack: this worm collected secrets from short-lived build and development systems and used them immediately to unauthorisedly publish infected updates of other npm packages maintained by the same maintainer.
The stolen credentials were additionally exfiltrated into specially created GitHub repositories named
The name is inspired by the sandworms from Dune, a science fiction novel from the 1980sShai-Hulud. The injected malware triggered a number of different secondary effects, implemented through various mechanisms:

• Exfiltration: Stolen secrets were stored in newly created GitHub repositories.
• Abuse of stolen tokens: Using the stolen credentials, the malware performed actions via the GitHub API – for example pushing infected commits, creating or modifying repositories, and changing repository visibility from “private” to “public”.
• Self-replication: The malware searched accessible repositories for additional secrets and injected malicious code.

In our threat notifications, we documented the observed attack mechanisms. This enables organisations to identify risks at an early stage and derive appropriate measures to secure dependencies, CI/CD pipelines and secrets management.

Risks and consequences for CI/CD pipelines and software dependencies

Worm-like attacks on software dependencies allow attackers to infect hundreds or even thousands of systems unnoticed with a single, targeted attack – (unfortunately) extremely efficiently.
In modern CI/CD environments, short-lived containers dominate, as do lightly monitored cloud components. This makes timely detection and appropriate response nearly impossible. 
Such attacks regularly lead to the exfiltration of sensitive assets, such as valuable secrets, credentials, and source code, which can then be used for post-exploitation and persistence of the attack.
 

Best practices for protecting against npm attacks

We recommend implementing the following best practices from the secure software development lifecycle (SSDLC) to effectively reduce vulnerability to supply chain attacks on software dependencies:

Managing and maintaining software dependencies

• Use lockfiles correctly to explicitly fix versions.
• Set up automatic updates (e.g., Dependabot or Renovate).
• Consider implementing small, trivial functions yourself rather than relying on third-party packages.
• Avoid dependencies on small projects with few or inactive maintainers.
• Check repositories for embedded secrets and remove them.

Securing registries and pipelines

• Only use trusted (official) registries (e.g., npmjs.com).
• Use multi-factor authentication (MFA) and short-lived tokens for publishing packages.
• Isolate build pipelines, monitor logs, and use static code analysis.

Improving detection and response

• Create and maintain an SBOM (Software Bill of Materials). This can be implemented permanently using tools like OWASP CycloneDX. For short-term source code analysis, OWASP Dependency-Check can be used.
• Monitor tokens for irregularities.

Language-specific tips

• npm: use npm ci instead of npm install, --ignore-scripts, perform regular npm audit scans, and consider pnpm for better isolation.
• Python / PyPI: use virtual environments, strict dependency management, hash verification, and version pinning (==). Avoid wildcards (*) or (latest).

Conclusion: taking proactive measures against supply chain attacks

It can be expected that the simplicity and effectiveness demonstrated by Shai-Hulud will serve as a blueprint for future supply chain attacks using worm-like malware.

The impact achieved has vividly shown various stakeholders the inherent vulnerabilities that modern software development entails under the paradigm of CI/CD.

In addition to the global security measures implemented by the companies behind the registries, it is essential to act proactively and embed your own security measures early in the software development process.

Prevention, monitoring, and security awareness are crucial to detect compromised software dependencies early and either prevent damage entirely or at least limit it effectively.