TL;DR: Shai-Hulud compromised more than 500 npm packages and spread through developer and machine identities by stealing credentials, tokens, and API keys, according to CyberArk’s analysis of the Sept. 16-17, 2025 worm. The incident shows that supply chain security now depends on identity controls as much as code review and package hygiene.
Editorial analysis by NHI Mgmt Group, based on content published by CyberArk: “Sandworm in the supply chain: Lessons from the Shai-Hulud npm attack on developer and machine identities”.
Key questions
Q: What breaks when an npm maintainer identity is compromised in a CI/CD pipeline?
A: The release process itself becomes part of the intrusion path.
Q: Why do npm tokens and build credentials increase supply chain risk so quickly?
A: Because they are reusable non-human identities with privileges that outlive a single session.
Q: What are the signs that a package publishing workflow has been compromised?
A: Common warning signs include unexpected package version bumps, releases from inactive or former employee accounts, changes to dependency behavior without a planned release, and traffic or transaction patterns that do not match normal application use.
Practitioner guidance
- Lock down maintainer publishing rights Require phishing-resistant MFA, remove legacy password-only access and restrict package publishing to tightly governed identities with explicit approval paths.
- Shorten the lifetime of developer and pipeline secrets Rotate npm tokens, cloud keys and GitHub credentials aggressively, then replace broad long-lived secrets with short-lived issuance where possible.
- Scan developer and CI/CD contexts for exposed secrets Search repositories, logs, environment variables and workflow files for tokens, API keys and cloud credentials, then revoke any discovered secret immediately.
Bottom line: Shai-Hulud showed that npm supply chain compromise is driven as much by identity trust as by malicious code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Identity trust, not code trust, is the decisive control surface in npm supply chains. The article shows that package managers fail when they assume the publisher is still the legitimate owner at the moment of release. Once maintainer credentials or tokens are stolen, the attacker can operate inside ordinary release workflows and the registry has little reason to question the action. Practitioners need to treat publisher identity as the primary trust boundary.
A few things that frame the scale:
- 42% of machine identities have privileged access and 61% of organisations lack identity security controls for cloud workloads, according to CyberArk's 2025 Identity Security Landscape.
A question worth separating out:
Q: How should teams separate release authority from CI/CD automation?
A: Treat release authority as privileged access and keep it distinct from build execution and secret retrieval. Automation should not inherit broad publish rights by default, and build identities should not be able to use the same secrets that authorise package release. That separation limits how far a single compromise can travel.
👉 Read our full editorial: Shai-hulud showed how npm supply chains fail on identity trust