Resposta ràpida: Els atacs a la cadena de subministrament NPM funcionen comprometent un compte de mantenidor de confiança o un CI/CD token, publicant una versió maliciosa d'un paquet en què els desenvolupadors ja confien i deixant que els scripts d'instal·lació o la lògica del cuc d'aquest paquet facin la resta. Entre l'agost de 2025 i mitjans de 2026, aquest patró va produir l'onada més gran d'atacs a la cadena de subministrament de paquets npm de la història del registre, inclòs el segrest chalk/debug, el Cuc Shai-Huludi programari maliciós d'estat-nació amagat en un paquet descarregat 100 milions de vegades a la setmana. La solució no és escanejar el codi després que arribi. És detectar paquets maliciosos abans que s'instal·lin i observar-los pipeline pel comportament exacte que comparteixen aquests atacs.
Cada instal·lació és un acte de confiança, i els atacants ho saben.
Un desenvolupador executa npm instal·larDarrere d'aquesta única ordre hi ha un arbre de dependències amb centenars, de vegades milers, de paquets, la majoria escrits i mantinguts per gent que el desenvolupador no coneixerà mai. Ningú revisa aquest arbre línia per línia. Ningú té temps per fer-ho.
Aquesta confiança és l'objectiu. És més barat per a un atacant fer phishing a un mantenidor de npm amb 2.6 milions de descàrregues setmanals que trobar un zero-day en un tallafocs de la llista Fortune 500. Els atacs de la cadena de subministrament de npm exploten exactament aquesta asimetria, i l'onada del 2025-2026 mostra fins a quin punt ha escalat aquesta explotació: des de typosquatting aïllat a cucs autopropagadors que publiquen els seus propis paquets maliciosos més ràpid del que qualsevol humà pot reaccionar.
Què es considera un atac a la cadena de subministrament npm
Un atac a la cadena de subministrament npm és qualsevol incident en què un atacant insereix codi maliciós a la distribució npm. pipeline en lloc de fer-ho a la base de codi pròpia d'un objectiu, de manera que el programari maliciós arriba disfressat d'una actualització de dependències rutinària. El punt d'entrada sol ser una de tres coses: les credencials robades d'un mantenidor, una publicació robada o CI/CD token o una compilació compromesa pipeline que és enganyat per publicar en nom de l'atacant. Com que els paquets npm extreuen dependències transitives automàticament, un únic paquet compromès pot arribar a aplicacions que mai l'han declarat com a dependència directa.
Cronologia: els atacs més grans a la cadena de subministrament de NPM del 2025-2026
El patró darrere de cada atac a la cadena de subministrament de paquets npm
Si eliminem els detalls, gairebé tots els incidents anteriors segueixen els mateixos quatre passos:
- Comprometre una identitat, no un sistema. Un mantenidor phishing, un token npm filtrat, un PAT de GitHub robat o un token OIDC extret de CI/CD memòria del corredor. L'atacant no trenca el registre. Pren prestada la clau d'algú.
- Publica amb un nom en què els desenvolupadors ja confiïn. No cal typosquatting quan el nom real del paquet funciona. Això és el que fa que aquests atacs siguin tan efectius contra l'actualització automatitzada. pipelines: l'actualització sembla completament legítima.
- Corre abans que ningú ho revisi. Els scripts d'instal·lació maliciosos, les càrregues útils ofuscades o el codi inactiu que només s'activa en condicions específiques s'executen en el moment. npm instal·lar s'executa, sovint a l'ordinador portàtil d'un desenvolupador, molt abans que una anàlisi de seguretat programada el vegi.
- Persisteix i, cada cop més, propaga't. Shai-Hulud i els seus descendents utilitzen les credencials que roben per publicar automàticament el següent paquet enverinat, convertint un únic compromís en una reacció en cadena a través del graf de dependències.
Per què les defenses habituals ho passen per alt
La majoria de les eines d'AppSec es van crear per analitzar el que ja hi ha al repositori: CVE coneguts, patrons de codi estàtics, problemes de llicència. Això és necessari, però estructuralment arriba massa tard per a aquesta classe d'atac. Quan un escàner veu una dependència, és possible que l'script d'instal·lació ja s'hagi executat a la màquina d'un desenvolupador. Els antivirus tradicionals i l'EDR observen el sistema operatiu, no els registres de paquets, de manera que no tenen cap concepte d'una "nova versió de npm" com a unitat de risc. I com mostren els incidents de TanStack i Red Hat, fins i tot les atestacions d'integritat de compilació com... SLSA provenance no ajuden quan l'atacant ha capturat legítimament la identitat que el signa: la signatura és vàlida, el paquet continua sent maliciós.
La bretxa que exploten aquests atacs de la cadena de subministrament npm es troba específicament en el moment de la publicació i la instal·lació, abans que existeixi una signatura per al programari maliciós i abans que el paquet s'hagi executat en qualsevol lloc on es veuria un escàner tradicional.
Com aturar el proper atac de la cadena de subministrament de NPM
Part d'aquesta és una disciplina de procés que tot equip d'enginyeria pot adoptar avui dia:
- Dependències de pins i commit fitxers de bloqueig, de manera que una actualització automàtica no pot incorporar silenciosament una versió maliciosa que s'acaba de publicar.
- Desactiva o emmagatzema els scripts de postinstal·lació en un espai de proves per defecte; la majoria de paquets no necessiten executar codi arbitrari en el moment de la instal·lació.
- Aplicar l'MFA amb suport de maquinari per a comptes de publicació npm, tancant exactament la ruta de phishing que havia compromès Chalk, debug i el compte de Qix.
- Abast i rotació CI/CD fitxes agressivamenti tractar els tokens OIDC a la memòria de l'executor com una credencial que val la pena protegir, no com un detall d'implementació.
- Vigileu el patró de desbloqueig-injecció-rebloqueig in CI/CD: una regla de protecció de branques desactivada, a commit empès, la regla reactivada, tot en una finestra ajustada. És una signatura recurrent de pipelinecompromís de la cadena de subministrament a nivell.
On la disciplina del procés s'esgota
La disciplina de processos redueix l'exposició. No detecta un paquet maliciós en el moment en què es publica, i no detecta un cuc que ja s'estigui propagant pel gràfic més ràpid del que un humà pot fer un triatge. Aquesta és la capa per a la qual està dissenyada la seguretat de la cadena de subministrament de Xygeni.
Xygeni's MEW (Alerta Precoç de Programari Maliciós) analitza contínuament els nous paquets publicats a npm, PyPI i Maven, detectant programari maliciós abans que existeixi una signatura en lloc de després, i introduint les amenaces confirmades de nou a Xygeni's propi motor de detecció. El Tallafocs de dependències escaneja npm, PyPI, Maven, NuGet i RubyGems en temps real i bloqueja les instal·lacions malicioses abans que arribin a la màquina d'un desenvolupador o a una compilació. CI/CD detecció d'anomalies rellotges pipelines per exactament el patró de comportament darrere d'incidents com el compromís de TanStack, inclosa la seqüència de desbloqueig-injecció-rebloqueig, amb un registre d'auditoria complet. I com que Xygeni's Triatge i remediació amb tecnologia d'IA s'apliquen també a les troballes d'escàners de tercers, els equips no han de treure les eines existents per tancar aquesta bretxa.
Preguntes freqüents: atacs a la cadena de subministrament de NPM
Què és un atac a la cadena de subministrament npm?
És un atac en què el codi maliciós arriba a una aplicació objectiu a través d'una dependència npm de confiança en lloc d'a través del propi codi de l'objectiu, normalment perquè un atacant ha compromès el compte d'un mantenidor, un token de publicació o un... CI/CD pipelinela identitat de.
Quin va ser el major atac a la cadena de subministrament de NPM?
Per radi d'explosió, el segrest de chalk/debug del setembre de 2025 és un dels més grans: 18 paquets amb un total de 2.6 milions de descàrregues setmanals van ser compromesos a través d'un únic compte de mantenidor de phishing. Per novetat tècnica, Shai-Hulud va ser el punt d'inflexió més significatiu, ja que va ser el primer cuc autopropagador de la història de npm.
Com sol començar un atac a la cadena de subministrament de paquets npm?
Gairebé sempre amb una identitat robada: un mantenidor phishing, un token de publicació filtrat o un robat CI/CD una credencial com ara un token OIDC extret de la memòria d'un corredor, en lloc d'una irrupció tècnica al mateix npm.
Pot un antivirus o EDR aturar un atac de la cadena de subministrament npm?
No de manera fiable. L'EDR supervisa el sistema operatiu i no entén els registres de paquets, i l'antivirus es basa en signatures, cosa que falla contra el programari maliciós publicat abans que existeixi cap signatura. Aturar aquesta classe d'atac requereix supervisió en el punt de publicació i instal·lació, no només al punt final.
Té SLSA provenance o l'atestat de construcció impedeix això?
Demostra la pipeline en si mateix no va ser manipulat durant la compilació. No demostra que la identitat que va desencadenar la compilació no estigués compromesa, tal com van demostrar els incidents de TanStack i Red Hat amb atestacions vàlides adjuntes a paquets maliciosos.
Com pot un equip detectar un paquet npm maliciós abans que s'instal·li?
Executant anàlisis contínues de programari maliciós prèvies a la signatura en paquets recentment publicats, que és per a això estan dissenyats un sistema d'alerta primerenca de programari maliciós i un tallafocs de dependències, en lloc de confiar únicament en l'escaneig de vulnerabilitats post-hoc del codi que ja es troba en un repositori.
On començar
Els atacs a la cadena de subministrament de NPM no s'estan alentint, i la línia de tendència des de Shai-Hulud apunta cap a una major automatització, no menys. Els equips més ben posicionats per a la propera campanya són els que van deixar de tractar cada instal·lació de npm com un esdeveniment rutinari i van començar a observar el registre, el pipeline, i el punt final com una superfície d'atac connectada.
El pla per a desenvolupadors de Xygeni inclou cobertura de MEW i Dependency Firewall per a un màxim de 25 repositoris sense cap cost. És un lloc raonable per veure què ja hi ha en un arbre de dependències.
