Tre ganger på åtte måneder fungerte den samme npm-orm-håndboken. Ulike angripere, forskjellige pakker, samme mekanikk og samme tidsvindu mellom publisering og deteksjon som gjorde hver enkelt mulig. Hvis du lurer på hva en npm-orm egentlig er, og hvorfor mønsteret gjentar seg i stedet for å bli fikset, er dette det ærlige svaret: hendelser, mekanikk og det ene gapet selv et solid defensivt rammeverk fortsatt lar være åpent.
Hva er en npm-orm?
En npm-orm er en del ondsinnet kode publisert i npm-registeret som automatisk sprer seg til andre pakker når den kjører, vanligvis ved å stjele en vedlikeholders publiseringsinformasjon og bruke dem til å injisere den samme nyttelasten i hver pakke som vedlikeholderen kontrollerer. Det er en «orm» i klassisk forstand: den venter ikke på at noen skal installere den med vilje, den forplanter seg av seg selv, fra pakke til pakke, konto til konto, i maskinhastighet.
Denne selvforplantningen er det som skiller en npm-ormhendelse fra en vanlig ondsinnet pakke. En enkelt skadelig pakke er en nål i en høystakk. En npm-orm gjør hver kompromitterte vedlikeholder om til et nytt distribusjonspunkt, og høystakken begynner å generere sine egne nåler.
De største npm-ormhendelsene så langt
Det siste året ga npm-ormemønsteret tre virkelige testkjøringer, hver mer effektiv enn den forrige:
- Shai-Hulud (september 2025). Den første dokumenterte selvforplantende npm-ormen. Den kompromitterte vedlikeholderens legitimasjon, og brukte dem deretter til å publisere ondsinnede versjoner av hver pakke under vedlikeholderens kontroll, og gjorde dermed utviklerne selv til leveringsmekanismen for neste fase av ormen.
- axios (mars 2026). Nasjonalstatlig skadevare gjemt inne i en pakke hentes omtrent 100 millioner ganger i uken. Ikke en orm i streng forplantningsforstand, men bevis på at den samme npm-økosystemtillitsmodellen som Shai-Hulud utnyttet kunne bære en nyttelast i virkelig massiv skala.
- SAP npm (april 2026). Beskrevet den gang som en mini Shai-Hulud: det samme ormemønsteret, gjentatt i stor skala, mindre enn et år etter den opprinnelige hendelsen. Mekanismen hadde ikke endret seg. Forsvaret hadde stort sett heller ikke.
Tre npm-ormhendelser, ett gjentakende mønsterkompromittere en pålitelig utgiver, bruke deres legitimasjon til å spre seg automatisk, og stole på gapet mellom publisering og fellesskapsdeteksjon for å gjøre resten.
Mønsteret som gjentar seg
Fjern detaljene, og hver npm-ormhendelse følger de samme fire taktslagene:
- Konto kompromittert. En vedlikeholders publiseringstoken, npm login, eller CI-legitimasjon blir stjålet, vanligvis gjennom phishing, en lekket hemmelighet eller en kompromittert avhengighet lenger oppe i sin egen kjede.
- Stille injeksjon. Angriperen sender ut en ny versjon av en legitim, pålitelig pakke med skadelig kode lagt til, ofte i et postinstall- eller annet livssyklusskript som kjører automatisk i det øyeblikket noen installerer det.
- Automatisk forplantning. Hvis den kompromitterte vedlikeholderen kontrollerer andre pakker, eller hvis det ondsinnede skriptet selv høster ytterligere påloggingsinformasjon, sprer ormen seg til den neste pakken og den neste vedlikeholderen uten ytterligere handling fra angriperen.
- Deteksjonsforsinkelsen. Pakken ligger live i registeret, installerbar av hvem som helst, helt til noen legger merke til det, rapporterer det, og den blir hentet. Den forsinkelsen, timer for noen hendelser, dager for andre, er hele vinduet ormen trenger.
Å gjenkjenne det fjerde taktslaget er det som faktisk betyr noe for forsvaret. Enhver avbøtende strategi for en npm-ormhendelse er i kjernen et forsøk på å redusere eller omgå den deteksjonsforsinkelsen.
Et rammeverk verdt å sitere: SIPs svar på nedkjølingsproblemet
Ikke alle reaksjoner på dette mønsteret kommer fra en leverandør. En av de tydeligste er SIP, Mohammad-Ali A'râbis sikkerhetsplan, et fem-kontrollers nødrammeverk for risiko i programvareforsyningskjeden som kom ut av et veldig praktisk spørsmål stilt på slutten av en SafeDev-økt: «Hvis vi bare kan gjøre noen få ting, hva bør vi gjøre først?»
SIPs andre kontroll er rettet direkte mot npm-ormproblemet: frys ukontrollerte avhengigheter med en fem-dagers nedkjølingsperiode, og deaktiver livssyklusskript slik at en ondsinnet etterinstallasjon ikke kan kjøres automatisk under installasjonen. I praksis er det min-release-age=5 og ignore-scripts=true i et prosjekt .npmrc, håndhevet i CI slik at en låsefil ikke stille kan løse en pakke publisert i går. Det er en genuint solid, lavinnsatssbasert kontroll, og den retter seg direkte mot den samme deteksjonsforsinkelsen som hver npm-ormhendelse er avhengig av. Dykk ned i det:
Der nedkjølingsvinduet fortsatt etterlater et gap
En nedkjølingsperiode er et veddemål: at fellesskapet vil legge merke til og rapportere en ondsinnet pakke før venteperioden er over. Som oftest lønner det seg. En betydelig andel av kompromitterte pakker blir flagget innen de første dagene etter publiseringen, og det er nettopp derfor et femdagersvindu er en rimelig standard.
Men en npm-orm oppfører seg ikke som en typisk ondsinnet pakke, og det endrer hva en fast nedkjølingsperiode kan og ikke kan gjøre for deg.
Å være førcise om hastighet: En hurtigvoksende orm beseirer ikke selve nedkjølingstiden. Hvis du håndhever en streng minimumsalder for utgivelse, er pakker publisert i løpet av den første bølgen fortsatt for nye til å bli en del av en build, uansett hvor mange pakker ormen kompromitterer i mellomtiden. Hastighet er viktig, men det er viktig for alle nedstrøms som ikke kjører en nedkjølingstid, ikke for å beseire en som allerede er håndhevet.
Den virkelige begrensningen er tålmodighet. En mer forsiktig nyttelast kan ligge i dvale etter nedkjølingsperioden, og aktiveres først når dagene er over og pakken har aldret seg til den "pålitelige" sonen.cisfordi den vet at en nedkjølingsprosess overvåker den. Det er i dette scenarioet at en fast nedkjølingsprosess alene ikke er nok, og akkurat der noe som MEWs evidensbaserte deteksjon må fungere ved siden av, ikke i stedet for den.
Ingen av feilmodusene er en svakhet i SIPs tankegang. En nedkjølingsfase er et veddemål for fellesskapsdeteksjon, og fellesskapsdeteksjon har en grense: den kan ikke fange opp det ingen har rapportert ennå. Det er ikke et gap som er unikt for SIP, det er en strukturell grense for ethvert forsvar som venter på at en signatur, en rådgivning eller en offentlig rapport skal eksistere før det handler.
Hvordan MEW lukker gapet mellom nedkjølingsvinduet
Dette er førcisely gapet Xygenis tidlige advarsel om skadelig programvare (MEW) er bygget for å lukkes. I stedet for å vente på fellesskapsrapporter eller en publisert signatur, skanner MEW kontinuerlig NPM, PyPI og Maven etter hvert som nye pakker og versjoner publiseres, og analyserer atferd i stedet for å matche mot kjente trusler. Når noe ser skadelig ut, settes det i karantene, og funnet bekreftes av sikkerhetsforskere før offentliggjøring, ikke etterpå.
Dette skillet er viktig for begge npm-ormfeilmodusene ovenfor. Mot en hurtigformet orm trenger ikke forhåndssignaturdeteksjon de fem dagene en nedkjølingsfrist antar den har. Mot en tålmodig, sovende nyttelast ser ikke MEWs atferdsanalyse etter alder eller omdømme, den ser etter hva koden faktisk gjør, så det å vente ut et nedkjølingsvindu kjøper ingenting for en angriper.
MEWs avhengighetsbrannmur utvider dette til selve installasjonen, og blokkerer en ondsinnet pakke i sanntid selv om den ikke har bestått tidligere kontroller, og det samme deteksjonslaget dekker CI/CD siden av en npm-ormhendelse: mønsteret for å låse opp grenen, injisere og låse på nytt som lar en angriper sende en ondsinnet commit og i stillhet dekke over sporene deres, med et fullstendig revisjonsspor hvis det uansett skjer.
SIP og MEW svarer på det samme spørsmålet, på forskjellige lag
Ingenting av dette gjør SIPs nedkjølingskontroll feil, og det er verdt å si rett ut: en fem-dagers nedkjølingskontroll med livssyklusskript deaktivert er fortsatt et av de raskeste og billigste forsvarene et team kan sette på plass mot en vanlig npm-ormhendelse, og det hører hjemme i enhver seriøs plan for herding av forsyningskjeden. Det den ikke kan gjøre, per design, er å fange opp det fellesskapet ikke har funnet ennå. Det er en jobb med kontinuerlig, atferdsbasert deteksjon som kjører under nedkjølingskontrollen, ikke i stedet for den.
Lagvis sammen dekker de to tilnærmingene begge ender av det samme problemet: SIP forsterker konstruksjonen pipeline, avhengighetsfrysingen og containeravbildningen rundt et kjent, avslørt trussellandskap, mens MEWs forhåndssignaturdeteksjon dekker npm-ormhendelser som ikke er avslørt ennå, de som et nedkjølingsvindu, etter sin egen logikk, ikke kan forutse komme.
FAQ
Hva er en npm-orm, kort fortalt?
Ondsinnet kode publisert til npm som automatisk sprer seg til andre pakker, vanligvis ved å stjele en vedlikeholders påloggingsinformasjon og bruke den til å injisere den samme nyttelasten et annet sted, uten ytterligere handling fra angriperen.
Er alle ondsinnede npm-pakker en npm-orm?
Nei. En ondsinnet pakke som ikke sprer seg av seg selv er et forsyningskjedeangrep, men ikke en orm. Det som spesifikt definerer en npm-ormhendelse er selvspredningstrinnet: ett kompromiss som automatisk fører til det neste.
Stopper en nedkjølingsperiode for avhengighet en npm-orm?
Det reduserer risikoen betydelig, siden de fleste skadelige pakker rapporteres innen de første dagene etter publisering. Men en nedkjølingsfrist er et veddemål på hastigheten på deteksjon i fellesskapet, og en raskt forplantende eller bevisst sovende npm-orm kan bygges spesielt for å komme seg forbi det vinduet.
Hva fanger egentlig en npm-orm før en nedkjølingsperiode?
Kontinuerlig, atferdsbasert skanning som ikke er avhengig av en signatur eller en offentlig rapport som allerede eksisterer. Det er spesifikke gap som verktøy for forhåndssignaturdeteksjon, som Xygenis MEW, er bygget for å lukke.
