In december 2025 voltooide npm, als reactie op het Sha1-Hulud-incident, een grote revisie van de authenticatie, bedoeld om aanvallen op de toeleveringsketen te verminderen. Hoewel de revisie een solide stap voorwaarts is, zorgen de veranderingen er niet voor dat npm-projecten immuun zijn voor aanvallen in de toeleveringsketen. npm is nog steeds gevoelig voor malware-aanvallen. Dit is wat u moet weten voor een veiligere Node-gemeenschap.
Laten we beginnen met het oorspronkelijke probleem
Historisch gezien vertrouwde npm op klassieke tokens: referenties met een lange levensduur en een breed bereik die voor onbepaalde tijd konden blijven bestaan. Als ze worden gestolen, kunnen aanvallers rechtstreeks kwaadaardige versies naar de pakketten van de auteur publiceren (geen openbaar verifieerbare broncode nodig). Dit maakte npm tot een belangrijke vector voor aanvallen op de toeleveringsketen. In de loop van de tijd hebben talloze incidenten uit de echte wereld dit punt aangetoond. Shai-Hulud, Sha1-Hulud en chalk/debug zijn voorbeelden van recente, opmerkelijke aanvallen.
NPM’s oplossing
Om dit aan te pakken heeft npm de volgende wijzigingen aangebracht:
- npm heeft alle klassieke tokens ingetrokken en is in plaats daarvan standaard op sessiegebaseerde tokens overgegaan. Het npm-team heeft ook het tokenbeheer verbeterd. Interactieve workflows maken nu gebruik van sessietokens van korte duur (doorgaans twee uur) die zijn verkregen via npm-login standaardinstellingen aan MFA voor publicatie.
- Het npm-team moedigt ook OIDC Trusted Publishing aan, waarbij CI-systemen kortstondige inloggegevens per run verkrijgen in plaats van geheimen in rust op te slaan.
In combinatie verbeteren deze praktijken de veiligheid. Ze zorgen ervoor dat inloggegevens snel verlopen en vereisen een tweede factor tijdens gevoelige operaties.
Er blijven nog twee belangrijke kwesties over
Ten eerste moeten mensen niet vergeten dat de oorspronkelijke aanval op tools als ChalkJS een succesvolle MFA-phishing-poging was op de console van npm. Als je naar de originele e-mail kijkt die hieronder is bijgevoegd, kun je zien dat het een op MFA gerichte phishing-e-mail was (er gaat niets boven proberen het goede te doen en toch verbrand te worden). De campagne heeft de beheerder ertoe verleid zowel de gebruikersnaam als het eenmalige wachtwoord te delen. Dit betekent dat soortgelijke e-mails in de toekomst tokens van korte duur kunnen krijgen, waardoor aanvallers nog steeds voldoende tijd hebben om malware te uploaden (aangezien dat slechts enkele minuten zou duren).
Ten tweede is MFA bij publicatie optioneel. Ontwikkelaars kunnen nog steeds tokens voor 90 dagen maken met MFA-bypass ingeschakeld in de console, die sterk lijken op de klassieke tokens van voorheen.
Met deze tokens kunt u lezen van en schrijven naar de onderhouden pakketten van een tokenauteur. Dit betekent dat als kwaadwillenden met deze tokeninstellingen toegang krijgen tot de console van een beheerder, zij namens die auteur nieuwe, kwaadaardige pakketten (en versies) kunnen publiceren. Dit brengt ons terug naar het oorspronkelijke probleem met npm voordat ze hun referentiebeleid aanpasten.
Voor alle duidelijkheid: meer ontwikkelaars die MFA gebruiken bij het publiceren is goed nieuws, en toekomstige aanvallen zouden minder en kleiner moeten zijn. Echter, OIDC en MFA on-publiceren optioneel Het kernprobleem blijft nog steeds onopgelost.
Concluderend: als (1) MFA-phishing-pogingen op de console van npm nog steeds werken en (2) toegang tot de console gelijk staat aan toegang om nieuwe pakketten/versies te publiceren, dan moeten ontwikkelaars zich bewust zijn van de risico’s voor de toeleveringsketen die nog steeds bestaan.
Aanbevelingen
In de geest van open source-beveiliging zijn hier drie aanbevelingen waarvan we hopen dat GitHub en npm deze in de toekomst zullen overwegen.
- Idealiter blijven ze op de lange termijn aandringen op de alomtegenwoordigheid van OIDC. OIDC is zeer moeilijk te compromitteren en zou de problemen rondom aanvallen op de toeleveringsketen bijna volledig uitwissen.
- Realistischer gezien zou het afdwingen van MFA voor lokale pakketuploads (via een e-mailcode of een eenmalig wachtwoord) de explosieradius van wormen als Shai-Hulud verder verkleinen. Met andere woorden: het zou een verbetering zijn niet toestaan aangepaste tokens die MFA omzeilen.
- Het zou op zijn minst leuk zijn om metagegevens toe te voegen aan pakketreleases, zodat ontwikkelaars voorzorgsmaatregelen kunnen nemen en pakketten (of beheerders) kunnen vermijden die geen beveiligingsmaatregelen in de toeleveringsketen nemen.
Kortom, npm heeft een belangrijke stap voorwaarts gezet door permanente tokens te elimineren en de standaardinstellingen te verbeteren. Totdat van korte duur identiteitsgebonden inloggegevens de norm worden – en MFA-bypass niet langer vereist is voor automatisering – blijft het supply chain-risico van gecompromitteerde bouwsystemen materieel aanwezig.
Een nieuwe manier om het te doen
De hele tijd hebben we het gehad over supply chain-aanvallen door namens een beheerder pakketten naar npm te uploaden. Als we elk npm-pakket zouden kunnen bouwen op basis van verifieerbare upstream-broncode in plaats van het artefact van npm te downloaden, zouden we beter af zijn. Dat is precies wat Chainguard voor zijn klanten doet met Chainguard Libraries voor JavaScript.
We hebben de openbare database doorzocht op gecompromitteerde pakketten binnen npm en ontdekten dat bij 98,5% van de kwaadaardige pakketten de malware niet aanwezig was in de upstream-broncode (alleen het gepubliceerde artefact). Dit betekent dat een benadering van bouwen vanaf de bron je aanvalsoppervlak met zo’n 98,5% zou verkleinen, gebaseerd op gegevens uit het verleden, omdat Chainguard’s JavaScript-repository nooit de kwaadaardige versies zou publiceren die beschikbaar zijn op npm.
In een ideale wereld zijn klanten het veiligst als ze Chainguard-bibliotheken gebruiken en de bovenstaande aanbevelingen toepassen. Volgens het ‘Zwitserse kaasmodel van beveiliging’ zijn al deze kenmerken lagen van aanvullende beveiligingsmaatregelen, en bedrijven zouden het beste af zijn als ze een combinatie hiervan zouden gebruiken.
Als u meer wilt weten over Chainguard-bibliotheken voor JavaScript, neem dan contact op met ons team.
Opmerking: Dit artikel is zorgvuldig geschreven en bijgedragen voor ons publiek door Adam La Morre, Senior Solutions Engineer bij Chainguard.
