Snel antwoord: Npm-toeleveringsketenaanvallen werken door een vertrouwd beheerdersaccount of een ander account te compromitteren. CI/CD token, het publiceren van een kwaadaardige versie van een pakket dat ontwikkelaars al vertrouwen, en de installatiescripts of wormlogica van dat pakket de rest laten doen. Tussen augustus 2025 en medio 2026 veroorzaakte dit patroon de grootste golf van aanvallen op de pakketketen van npm in de geschiedenis van het register, waaronder de chalk/debug-kaping, de Shai-Hulud-wormEn malware van een natiestaat, verborgen in een pakket dat 100 miljoen keer per week wordt gedownload. De oplossing is niet het scannen van code nadat deze is gedownload. Het gaat erom kwaadaardige pakketten te onderscheppen voordat ze worden geïnstalleerd en de installatie ervan te monitoren. pipeline voor het exacte gedrag dat deze aanvallen gemeen hebben.
Elke installatie is een blijk van vertrouwen, en aanvallers weten dat.
Een ontwikkelaar runt npm installerenAchter dat ene commando schuilt een afhankelijkheidsboom met honderden, soms duizenden pakketten, waarvan de meeste geschreven en onderhouden worden door mensen die de ontwikkelaar nooit zal ontmoeten. Niemand bekijkt die boom regel voor regel. Niemand heeft daar tijd voor.
Dat vertrouwen is het doelwit. Het is voor een aanvaller goedkoper om één npm-maintainer met 2.6 miljard wekelijkse downloads te phishen dan om een zero-day-vulnerabiliteit te vinden in de firewall van een Fortune 500-bedrijf. Aanvallen op de toeleveringsketen van npm maken precies gebruik van deze asymmetrie, en de golf van 2025-2026 laat zien hoe ver deze exploit is opgeschaald: van geïsoleerde typosquatting tot zelfverspreidende wormen die hun eigen kwaadaardige pakketten sneller publiceren dan een mens kan reageren.
Wat wordt beschouwd als een npm-toeleveringsketenaanval?
Een npm supply chain attack is elk incident waarbij een aanvaller kwaadwillende code in de npm-distributie invoegt. pipeline In plaats van in de eigen codebase van het doelwit, komt de malware binnen vermomd als een routinematige update van afhankelijkheden. Het toegangspunt is meestal een van de volgende drie dingen: gestolen inloggegevens van een beheerder, gestolen publicatierechten of CI/CD token, of een gecompromitteerde build pipeline dat wordt misleid om namens de aanvaller te publiceren. Omdat npm-pakketten automatisch transitieve afhankelijkheden binnenhalen, kan één gecompromitteerd pakket applicaties bereiken die het nooit als directe afhankelijkheid hebben gedeclareerd.
Tijdlijn: de grootste npm-toeleveringsketenaanvallen van 2025-2026
Het patroon achter elke aanval op de toeleveringsketen van npm-pakketten
Als je de details weglaat, volgen vrijwel alle bovenstaande incidenten dezelfde vier stappen:
- Breng een identiteit in gevaar, niet een systeem. Een via phishing verkregen beheerder, een gelekt npm-token, een gestolen GitHub PAT of een OIDC-token dat is verkregen via CI/CD Runner-geheugen. De aanvaller beschadigt het register niet. Ze lenen iemands sleutel ervoor.
- Publiceer onder een naam die ontwikkelaars al vertrouwen. Typosquatting is niet nodig als de echte pakketnaam werkt. Dit maakt deze aanvallen zo effectief tegen geautomatiseerde updates. pipelines: De update lijkt volkomen legitiem.
- Speel het uit voordat iemand het beoordeelt. Kwaadaardige installatiescripts, versleutelde payloads of verborgen code die alleen onder specifieke omstandigheden wordt geactiveerd, worden op dat moment uitgevoerd. npm installeren Het programma draait vaak op de laptop van een ontwikkelaar, lang voordat een geplande beveiligingsscan het zou detecteren.
- Volhard en verspreid je steeds meer. Shai-Hulud en zijn opvolgers gebruiken de gestolen inloggegevens om automatisch het volgende besmette pakket te publiceren, waardoor één inbreuk een kettingreactie in de hele afhankelijkheidsgrafiek veroorzaakt.
Waarom de gebruikelijke verdedigingsmechanismen het missen
De meeste AppSec-tools zijn ontworpen om te analyseren wat er al in de repository aanwezig is: bekende CVE's, statische code-patronen en licentieproblemen. Dat is noodzakelijk, maar structureel gezien komt het te laat voor dit type aanval. Tegen de tijd dat een scanner een afhankelijkheid detecteert, is het installatiescript mogelijk al uitgevoerd op de computer van een ontwikkelaar. Traditionele antivirus- en EDR-systemen bewaken het besturingssysteem, niet de pakketregisters, waardoor ze geen rekening houden met een "nieuwe npm-release" als risico-eenheid. En zoals de incidenten met TanStack en Red Hat aantonen, kunnen zelfs build-integriteitsverklaringen zoals SLSA provenance Ze bieden geen uitkomst als de aanvaller de identiteit van de ondertekenaar rechtmatig heeft bemachtigd: de handtekening is geldig, maar het pakket blijft schadelijk.
De kwetsbaarheid die deze npm-toeleveringsketenaanvallen uitbuiten, zit specifiek in het moment van publicatie en installatie, voordat er een signatuur voor de malware bestaat en voordat het pakket is uitgevoerd op een plek waar een traditionele scanner zou kijken.
Hoe voorkom je de volgende npm-toeleveringsketenaanval?
Een deel hiervan is procesdiscipline die elk engineeringteam vandaag de dag kan toepassen:
- Pin-afhankelijkheden en commit vergrendelbestandenEen automatische update kan dus niet ongemerkt een net gepubliceerde kwaadaardige versie binnenhalen.
- Schakel postinstallatiescripts uit of plaats ze in een sandbox. Standaard hoeven de meeste pakketten geen willekeurige code uit te voeren tijdens de installatie.
- Dwing hardwarematige MFA af voor npm-publicatieaccounts.waardoor precies het phishingpad werd afgesloten dat de accounts van chalk, debug en Qix had gecompromitteerd.
- Inzoomen en draaien CI/CD tokens agressiefEn behandel OIDC-tokens in het runnergeheugen als een waardevolle referentie, niet als een implementatiedetail.
- Let op het ontgrendel-inject-vergrendel-patroon. in CI/CD: een branchbeveiligingsregel uitgeschakeld, een commit De regel werd opnieuw geactiveerd, en dat allemaal binnen een kort tijdsbestek. Het is een terugkerend patroon. pipeline-niveau compromis in de toeleveringsketen.
Waar de procesdiscipline ophoudt
Procesdiscipline vermindert de kwetsbaarheid. Het detecteert geen kwaadaardig pakket op het moment dat het wordt gepubliceerd, en het detecteert ook geen worm die zich al sneller door de grafiek verspreidt dan een mens kan prioriteren. Dat is de laag waarvoor Xygeni's Supply Chain Security is ontworpen.
Xygeni's MEW (Malware Early Warning) Het analyseert continu nieuwe pakketten die op npm, PyPI en Maven worden gepubliceerd, waardoor malware wordt opgespoord voordat er een signatuur bestaat in plaats van erna, en bevestigde bedreigingen worden teruggekoppeld naar het systeem. Xygeni's eigen detectiemotor. De Afhankelijkheidsfirewall Het scant npm, PyPI, Maven, NuGet en RubyGems in realtime en blokkeert kwaadaardige installaties voordat ze de computer van een ontwikkelaar of een build bereiken. CI/CD onregelmatigheidsdetectie horloges pipelinevoor het exact in kaart brengen van het gedragspatroon achter incidenten zoals de TanStack-hack, inclusief de ontgrendel-inject-vergrendelsequentie, met een volledig auditspoor. En omdat Xygeni's Door AI ondersteunde triage en herstel Dit geldt ook voor bevindingen van scanners van derden; teams hoeven bestaande tools niet te vervangen om dit hiaat te dichten.
Veelgestelde vragen: npm supply chain-aanvallen
Wat is een npm supply chain attack?
Het is een aanval waarbij kwaadaardige code een doelapplicatie bereikt via een vertrouwde npm-afhankelijkheid in plaats van via de eigen code van het doelwit. Dit komt meestal doordat een aanvaller het account van een beheerder, een publicatietoken of een ander beveiligingsmechanisme heeft gecompromitteerd. CI/CD pipeline's identiteit.
Wat was de grootste aanval op de toeleveringsketen van npm?
Qua impactbereik behoort de kaping van chalk/debug in september 2025 tot de grootste: 18 pakketten met een gecombineerd aantal van 2.6 miljard wekelijkse downloads werden gecompromitteerd via één enkel phishingaccount van een beheerder. Technisch gezien was Shai-Hulud echter een belangrijkere doorbraak, als de eerste zelfverspreidende worm in de geschiedenis van npm.
Hoe begint een aanval op de toeleveringsketen van npm-pakketten doorgaans?
Vrijwel altijd met een gestolen identiteit: een via phishing verkregen beheerder, een gelekte publicatietoken of een gestolen account. CI/CD Een authenticatiemiddel zoals een OIDC-token dat uit het geheugen van een runner wordt gehaald, in plaats van een technische inbraak in npm zelf.
Kunnen antivirusprogramma's of EDR een npm-toeleveringsketenaanval stoppen?
Niet betrouwbaar. EDR bewaakt het besturingssysteem en begrijpt geen pakketregisters, en antivirussoftware is gebaseerd op signatures, wat tekortschiet bij malware die is gepubliceerd voordat er signatures bestaan. Om dit type aanval te stoppen, is monitoring nodig op het moment van publicatie en installatie, niet alleen op het eindpunt.
Doet SLSA provenance Of kan een build-attest dit voorkomen?
Het bewijst dat pipeline Het bestand zelf is tijdens de build niet gemanipuleerd. Dit bewijst echter niet dat de identiteit die de build heeft geactiveerd niet is gecompromitteerd, zoals de incidenten met TanStack en Red Hat beide hebben aangetoond met geldige attestaties die aan kwaadwillende pakketten waren gekoppeld.
Hoe kan een team een kwaadaardig npm-pakket detecteren voordat het wordt geïnstalleerd?
Door continu, vóórdat er signaturen worden gegenereerd, malware-analyses uit te voeren op nieuw gepubliceerde pakketten – wat een malware-waarschuwingssysteem en een dependency firewall immers doen – in plaats van uitsluitend te vertrouwen op achteraf uitgevoerde kwetsbaarheidsscans van code die al in een repository aanwezig is.
Waar te beginnen
De aanvallen op de toeleveringsketen van npm nemen niet af, en de trend sinds Shai-Hulud wijst eerder op meer dan minder automatisering. De teams die het best gepositioneerd zijn voor de volgende aanval, zijn de teams die zijn gestopt met het behandelen van elke npm-installatie als een routinegebeurtenis en in plaats daarvan de registry zijn gaan monitoren. pipelineen het eindpunt als één verbonden aanvalsoppervlak.
Het ontwikkelaarsabonnement van Xygeni omvat dekking voor MEW en Dependency Firewall. Voor maximaal 25 repositories, geheel gratis. Het is een handige plek om te zien wat er al in een afhankelijkheidsstructuur aanwezig is.
