Raskt svar: NPM-forsyningskjedeangrep fungerer ved å kompromittere en pålitelig vedlikeholderkonto eller en CI/CD token, publisere en ondsinnet versjon av en pakke som utviklere allerede stoler på, og la pakkens installasjonsskript eller ormlogikk gjøre resten. Mellom august 2025 og midten av 2026 produserte dette mønsteret den største bølgen av npm-pakkeforsyningskjedeangrep i registerets historie, inkludert chalk/debug-kapringen, Shai-Hulud-ormenog skadelig programvare fra nasjonens stat skjult i en pakke som lastes ned 100 millioner ganger i uken. Løsningen skanner ikke kode etter at den har landet. Den fanger opp skadelige pakker før de installeres og overvåker pipeline for den nøyaktige oppførselen disse angrepene deler.
Hver installasjon er en tillitshandling, og angripere vet det
En utvikler kjører npm installasjonBak den ene kommandoen ligger et avhengighetstre med hundrevis, noen ganger tusenvis, av pakker, de fleste av dem skrevet og vedlikeholdt av folk utvikleren aldri vil møte. Ingen gjennomgår dette treet linje for linje. Ingen har tid til det.
Den tilliten er målet. Det er billigere for en angriper å phishe én npm-vedlikeholder med 2.6 milliarder ukentlige nedlastinger enn å finne en nulldagsangrep i en Fortune 500-brannmur. Npm-forsyningskjedeangrep utnytter nettopp denne asymmetrien, og bølgen fra 2025–2026 viser hvor langt denne angrepet har skalert: fra isolert typosquatting til selvforplantende ormer som publiserer sine egne ondsinnede pakker raskere enn noe menneske kan reagere.
Hva som teller som et npm-forsyningskjedeangrep
Et npm-forsyningskjedeangrep er enhver hendelse der en angriper setter inn skadelig kode i npm-distribusjonen. pipeline snarere enn inn i et måls egen kodebase, slik at skadevaren ankommer forkledd som en rutinemessig avhengighetsoppdatering. Inngangspunktet er vanligvis ett av tre ting: en vedlikeholders stjålne legitimasjon, en stjålet publisering eller CI/CD token eller en kompromittert versjon pipeline som blir lurt til å publisere på angriperens vegne. Fordi npm-pakker henter inn transitive avhengigheter automatisk, kan en enkelt kompromittert pakke nå applikasjoner som aldri har deklarert den som en direkte avhengighet i det hele tatt.
Tidslinje: de største npm-forsyningskjedeangrepene i 2025–2026
Mønsteret bak hvert npm-pakkeforsyningskjedeangrep
Fjern detaljene, og nesten alle hendelser ovenfor følger de samme fire trinnene:
- Kompromiss med en identitet, ikke et system. En phishing-vedlikeholder, et lekket npm-token, en stjålet GitHub PAT eller et OIDC-token hentet fra CI/CD runner-minne. Angriperen bryter ikke registeret. De låner noens nøkkel til det.
- Publiser under et navn utviklere allerede stoler på. Ingen typosquatting nødvendig når det virkelige pakkenavnet fungerer. Dette er det som gjør disse angrepene så effektive mot automatiserte oppdateringer pipelines: oppdateringen ser helt legitim ut.
- Løp før noen anmelder det. Ondsinnede installasjonsskript, obfuskerte nyttelaster eller sovende kode som bare aktiveres under spesifikke forhold, kjører i det øyeblikket npm installasjon kjører, ofte på en utviklers bærbare datamaskin, lenge før en planlagt sikkerhetsskanning noen gang ville sett den.
- Vedvare og, i økende grad, forplante seg. Shai-Hulud og dens etterkommere bruker legitimasjonen de stjeler til å publisere den neste forgiftede pakken automatisk, og dermed gjøre et enkelt kompromiss om til en kjedereaksjon på tvers av avhengighetsgrafen.
Hvorfor de vanlige forsvarene bommer på det
Mesteparten av AppSec-verktøy ble bygget for å analysere hva som allerede finnes i depotet: kjente CVE-er, statiske kodemønstre, lisensproblemer. Det er nødvendig, men det kommer strukturelt for sent for denne angrepsklassen. Når en skanner ser en avhengighet, kan installasjonsskriptet allerede ha blitt kjørt på en utviklers maskin. Tradisjonelt antivirusprogram og EDR overvåker operativsystemet, ikke pakkeregistre, så de har ikke noe konsept om en "ny npm-utgivelse" som en risikoenhet. Og som TanStack- og Red Hat-hendelsene viser, kan selv byggintegritetsattester som SLSA provenance hjelper ikke når angriperen legitimt har fanget identiteten som signerer dem: signaturen er gyldig, pakken er fortsatt skadelig.
Gapet som disse npm-forsyningskjedeangrepene utnytter, ligger spesifikt ved publisering og installasjon, før en signatur for skadevaren finnes, og før pakken har kjørt noe sted en tradisjonell skanner ville sett etter.
Slik stopper du det neste npm-forsyningskjedeangrepet
Noe av dette er prosessdisiplin som alle ingeniørteam kan ta i bruk i dag:
- Pin-avhengigheter og commit låsefiler, så en automatisk oppdatering kan ikke stille hente inn en nettopp publisert skadelig versjon.
- Deaktiver eller sandboks etterinstallasjonsskript som standard trenger de fleste pakker ikke å kjøre vilkårlig kode under installasjon.
- Håndhev maskinvarestøttet MFA for npm-publiseringskontoer, og lukket den nøyaktige phishing-banen som kompromitterte chalk, debug og Qix sin konto.
- Omfang og rotasjon CI/CD tokens aggressivt, og behandle OIDC-tokener i runner-minnet som en legitimasjon verdt å beskytte, ikke en implementeringsdetalj.
- Se etter opplåsings-injeksjons-låsingsmønsteret in CI/CDen regel for grenbeskyttelse deaktivert, en commit presset, regelen aktivert på nytt, alt i et stramt vindu. Det er en tilbakevendende signatur av pipelinekompromiss i forsyningskjeden på alle nivåer.
Der prosessdisiplinen tar slutt
Prosesdisiplin reduserer eksponering. Den fanger ikke opp en ondsinnet pakke i det øyeblikket den publiseres, og den fanger ikke opp en orm som allerede sprer seg gjennom grafen raskere enn et menneske kan prioritere. Det er det laget Xygenis Supply Chain Security er bygget for.
Xygenis MEW (tidlig advarsel om skadelig programvare) analyserer kontinuerlig nye pakker publisert til npm, PyPI og Maven, fanger opp skadelig programvare før en signatur finnes i stedet for etter, og mater bekreftede trusler tilbake til Xygenis egen deteksjonsmotor. Den Avhengighetsbrannmur skanner npm, PyPI, Maven, NuGet og RubyGems i sanntid og blokkerer ondsinnede installasjoner før de når en utviklers maskin eller en build. CI/CD anomali påvisning klokker pipelines for nøyaktig atferdsmønsteret bak hendelser som TanStack-kompromisset, inkludert opplåsings-injeksjons-låsingssekvensen, med et fullstendig revisjonsspor. Og fordi Xygenis AI-drevet triage og utbedring gjelder også funn fra tredjepartsskannere, teamene trenger ikke å rive ut eksisterende verktøy for å tette dette gapet.
Vanlige spørsmål: npm-angrep i forsyningskjeden
Hva er et npm-forsyningskjedeangrep?
Det er et angrep der ondsinnet kode når et målprogram gjennom en klarert npm-avhengighet i stedet for gjennom målets egen kode, vanligvis fordi en angriper kompromitterte en vedlikeholders konto, et publiseringstoken eller en ... CI/CD pipelineidentitet.
Hva var det største NPM-angrepet i forsyningskjeden?
Etter eksplosjonsradius er chalk/debug-kapringen i september 2025 blant de største: 18 pakker med til sammen 2.6 milliarder ukentlige nedlastinger ble kompromittert gjennom en enkelt phishing-vedlikeholderkonto. Av teknisk nyhet var Shai-Hulud det viktigste vendepunktet, som den første selvforplantende ormen i npms historie.
Hvordan starter vanligvis et NPM-pakkeforsyningskjedeangrep?
Nesten alltid med en stjålet identitet: en phishing-vedlikeholder, en lekket publiseringstoken eller en stjålet CI/CD legitimasjon som et OIDC-token hentet fra en løpers minne, snarere enn et teknisk innbrudd i selve npm.
Kan antivirus eller EDR stoppe et NPM-forsyningskjedeangrep?
Ikke pålitelig. EDR overvåker operativsystemet og forstår ikke pakkeregistre, og antivirus er signaturbasert, noe som mislykkes mot skadelig programvare som publiseres før det finnes noen signatur. Å stoppe denne angrepsklassen krever overvåking på publiserings- og installasjonsstedet, ikke bare på endepunktet.
Betyr SLSA provenance eller byggeattestering forhindre dette?
Det beviser pipeline selve ikke ble tuklet med under byggingen. Det beviser ikke at identiteten som utløste byggingen ikke ble kompromittert, slik TanStack- og Red Hat-hendelsene begge demonstrerte med gyldige attester knyttet til skadelige pakker.
Hvordan kan et team oppdage en ondsinnet npm-pakke før den installeres?
Ved å kjøre kontinuerlig, forhåndssignert analyse av skadelig programvare på nylig publiserte pakker, som er det et tidlig varslingssystem for skadelig programvare og en avhengighetsbrannmur er utformet for å gjøre, i stedet for å utelukkende stole på etterfølgende sårbarhetsskanning av kode som allerede finnes i et arkiv.
Hvor skal jeg starte
NPM-angrep i forsyningskjeden avtar ikke, og trendlinjen siden Shai-Hulud peker mot mer automatisering, ikke mindre. Teamene som er best posisjonert for neste kampanje er de som sluttet å behandle hver NPM-installasjon som en rutinehendelse og begynte å følge med på registeret, pipeline, og endepunktet som én tilkoblet angrepsflate.
Xygenis utviklerplan inkluderer MEW og avhengighetsbrannmurdekning for opptil 25 repositorier uten kostnad. Det er et rimelig sted å se hva som allerede ligger i et avhengighetstre.
