Topic starter
18/08/2026 2:32 pm
TL;DR: Npm supply chain attacks increasingly begin with stolen maintainer credentials, publishing tokens, or CI/CD identities, and Xygeni says the largest wave in the registry’s history included the chalk/debug hijack, the Shai-Hulud worm, and nation-state malware hidden in a package downloaded 100 million times a week. The control gap is now publication-time identity abuse, not just code scanning after release.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Npm Supply Chain Attacks: Biggest Incidents & How to Stop Them”.
By the numbers:
- A package in the wave was downloaded 100 million times a week.
Key questions
Q: What fails first in an npm supply chain attack when identities are compromised?
A: The first failure is usually publication trust, not code validation.
Q: Why do stolen maintainer accounts and CI/CD tokens create such large npm blast radius?
A: Because package ecosystems amplify a single privileged identity across many consumers.
Q: How should security teams build detection for malicious npm packages at publish time?
A: Security teams should combine fast package intake with layered enrichment, static analysis, and automated quarantine of suspicious records.
Practitioner guidance
- Strengthen publishing identity controls Require hardware-backed MFA, device binding, and separate privileged accounts for package publication so a stolen maintainer login cannot directly ship releases.
- Treat CI/CD tokens as high-risk NHIs Inventory OIDC tokens, runner credentials, and publishing secrets, then scope and rotate them aggressively with explicit ownership and expiry.
- Reduce install-time execution exposure Disable or sandbox postinstall scripts by default and allow exceptions only for packages that have a documented operational need.
Bottom line: npm supply chain attacks now exploit identity at publication time, so the main control gap is who can publish trusted software, not whether the code looks suspicious after release.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:19 pm
Publication identity is now the control plane for npm risk. The article shows that attackers are no longer relying primarily on code novelty. They are compromising the identities that can publish software, which means the governance failure sits in credential authority, not in source code review. For identity teams, package publication is a privileged action and should be treated like any other high-risk approval path.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: How should IAM teams govern npm publishing and CI/CD identities?
A: They should treat package publishing accounts, tokens, and runner credentials as privileged non-human identities with explicit ownership, lifecycle control, and tight scope. That means separating publish rights from routine development access, enforcing strong authentication, and revoking or rotating credentials that are no longer needed.
👉 Read our full editorial: Npm supply chain attacks now exploit identity, not code