Door Jasper Bakker

Nieuwsredacteur

Wat zijn npm-packages en waarom richten hackers zich erop?

19-09-2025 • 14:00

48

Wat zijn npm-packages en waarom richten hackers zich erop?

Voor de tweede keer in korte tijd hebben aanvallers malware verspreid via npm-packages. De daders weten daarmee zeer veel slachtoffers te maken: naast directe gebruikers van gecompromitteerde npm-packages ook indirecte gebruikers. Wat is npm eigenlijk en waarom hebben veel mensen te maken met packages daarvan?

Kort gezegd is npm is de standaardpackagemanager voor stukken JavaScript-code. Achter deze basale uitleg schuilt wat complexiteit, zeker in het licht van recente securityincidenten op dit gebied.

Malware-infecties

Eerst was er het nieuws dat npm-packages met meer dan twee miljard wekelijkse downloads zijn geïnfecteerd met malware. Deze infectie was niet het doel, maar slechts het middel. Via de besmette npm-packages wisten de onbekende aanvallers cryptovalutastelers te installeren op systemen van vele mensen.

Net meer dan een week later volgde het securitynieuws dat 187 npm-packages zijn geïnfecteerd met malware die credentials steelt. Bij de getroffen stukken software zaten ook packages van securityleverancier CrowdStrike. Volgens securityexperts zitten waarschijnlijk dezelfde daders achter deze twee aanvallen op en via npm-packages.

Disney, Spotify, Apple

Deze twee recente gevallen zijn niet uniek of gloednieuw. In juli dit jaar was een npm-package met 2,8 miljoen wekelijkse downloads al gecompromitteerd. En in oktober vorig jaar probeerden cybercriminelen cryptovaluta te stelen door kwaadwillige code toe te voegen aan de populaire animatietool Lottie Player.

Die infectie was mogelijk doordat aanvallers hadden ingebroken op het GitHub-account van LottieFiles. Dat bedrijf maakt animatietools die gebruikt worden door onder meer Disney, Spotify en Apple. Via het GitHub-account voegden de aanvallers kwaadwillige code toe aan de npm-package van Lottie Player.

LottieFiles animatietool

Bovenstaande materie kan bekende kost zijn voor developers en securitykenners. Niet iedereen weet echter wat npm is en waarom dat een domino-effect kan hebben. Het is hoe dan ook een techkwestie die securityzorgen geeft, want de aanvallen via npm-packages hebben niet alleen de makers van die software-elementen geraakt. Via die zogeheten maintainers zijn veel andere techgebruikende mensen geraakt.

Softwareontwikkeling en -distributie

Dat hangt samen met moderne manieren voor het ontwikkelen, distribueren, aanbieden en gebruiken van software. Npm is een beheertool voor zogeheten packages; dat zijn stukken software. Het packagen van software is het proces van het 'verpakken' van diverse code-elementen, die dan samen een functioneel geheel vormen. Dat geheel kan een volledige applicatie of app zijn, maar kan ook zelf weer een component zijn voor andere software.

Onder Linux-gebruikers kan het woord package bekend zijn. Het commando apt-get geeft na invoeren op de opdrachtregel een lijst van packages, afkomstig uit een zogeheten repository. Dat is een onlinebron van Linux-packages, die standaard van de maker van de gebruikte Linux-distributie is, zoals Ubuntu, Red Hat, Debian, SUSE, enzovoorts. Je kunt dit zien als de commandpromptgedreven voorloper van de bekende appstores. Linux had dit echter al vér voordat iOS, Android, macOS en Windows ieder appstores kregen van hun makers, respectievelijk Apple, Google, Apple en Microsoft.

NewTux logo (über)

Packagemanager voor developers

Packages zijn dus te beschouwen als een vrij normaal fenomeen in de softwarewereld, waarvan veel developers gebruikmaken. Npm-packages zijn dan weer specifieke softwarestukken: geschreven in de programmeertaal JavaScript. Npm is daarvoor een zogeheten packagemanager, waarmee stukken JavaScript-code zijn te downloaden, verwerken, gebruiken en weer verspreiden in andere software.

Oorspronkelijk was JavaScript lokaal draaiende code in een webbrowser op de computer van een websitebezoeker. Later is JavaScript doorontwikkeld: het kan nu ook zonder browser worden uitgevoerd met het Node.js-platform, wat een zogeheten runtimeomgeving voor softwarecode is. Npm is de standaardpackagemanager voor Node.js. Daarbij is 'npm' overigens niet een afkorting voor 'Node.js package manager'; het is een naar zichzelf terugverwijzend backronym, waarbij 'npm' staat voor 'npm is not an acronym'.

Node.js is opensource, gratis beschikbaar en draait op Windows, macOS, Linux en Unix. Developers kunnen met dat platform uiteenlopende soorten software maken: krachtige servertoepassingen, fraaie webapps, technische commandprompttools, handige scripts, nuttige bibliotheken (library's), enzovoorts. Ze doen dat door packages te gebruiken van andere developers.

Domino-effect

Daarin zit het nut van npm niet alleen voor softwareontwikkelaars, maar ook voor sluwe cybercriminelen. Die laatste kunnen met een stiekeme supplychainaanval op een maintainer van een veelgebruikte package automatisch vele andere stukken software bereiken, plus de gebruikers van die producten verderop in de softwareketen. De aanvallen op npm-packages zijn dus eigenlijk aanvallen vía npm-packages.

De vergelijking valt opnieuw te trekken met het fenomeen van appstores, de onlinewinkels waar gewone gebruikers applicaties kunnen vinden en downloaden. In de begintijd van appstores verschenen daarin nogal eens kwaadwillige apps. Dit was voordat bedrijven als Apple, Google en Microsoft strikter gingen kijken naar de digitale waar die via hun appwinkels werd verspreid. Technische keuringen en procedures voor het indienen van apps waren het gevolg.

Apple App Store

Security vereist waakzaamheid

Voor npm-packages zijn er zeker securityvoorzieningen, maar die blijken door de decentrale aard van het nuttige opensourceplatform niet sluitend genoeg te zijn. Aanvallers die de inloggegevens van een individuele ontwikkelaar buitmaken, kunnen een package voorzien van malware en dan digitaal ondertekenen, zodat het legitiem lijkt te zijn. Daarnaast lijkt het erop dat 'afnemers' van npm-packages niet altijd audits uitvoeren op de code die zij – soms volautomatisch – downloaden en gebruiken in hun eigen software.

Verschillende schakels in de ketens van softwareontwikkeling en -distributie kunnen dus zwak blijken te zijn. De Owasp Foundation waarschuwt dan ook voor de risico's van npm-packages en biedt best practices voor veilig npm-gebruik. Deze adviezen omvatten het uitvoeren van audits op code, maar ook basale zaken als het gebruik van tweefactorauthenticatie.

cybersecurity

De recente hackaanval op npm-packages met meer dan 2 miljard wekelijkse downloads had uiteindelijk geen enorme impact, maar moet mensen wel wakker schudden. De kern van het JavaScript-ecosysteem is geraakt, stelt cto Brian Fox van Sonatype, dat tools biedt voor veilige softwareontwikkeling.

Groot en groeiend

Hoewel dat bedrijf een commercieel motief heeft, valt niet te ontkennen dat hier een securityprobleem speelt. Dat probleem is niet gloednieuw, maar wel grotendeels ongezien en groeiend. Eind 2024 bleek een kwaadwillige npm-package al een jaar ongemerkt aan cryptomining en datadiefstal te doen. Eind 2018 schreef Tweakers over een npm-infectie waarmee cryptovaluta werd gestolen. De recente aanvallen via npm zijn van groter formaat en kunnen een voorbode zijn van massaler misbruik.

Redactie: Jasper Bakker • Eindredactie: Marger Verschuur

Reacties (48)

48
48
18
3
1
25
Wijzig sortering

Sorteer op:

Weergave:

Handige tips voor verhogen van beveiliging rond NPM packages:
  • Gebruik een NPM mirror die de code ook daadwerkelijk scanned en gebruik codescanners en antivirus om ze voor te zijn voordat ze überhaupt uitgevoerd worden
  • Gebruik in de pipeline alleen "npm ci" en zet de package-lock.json in je project. Hiermee zal je pipeline alleen packages binnenhalen waarvan je ze zelf getest hebt en waar je dus extra checks op kunt uitvoeren.
  • Stel een vertraging in voor dependabot of renovatebot als je packages automatisch bijwerkt. Maar gebruik ze wel weer om andere bugs eruit te patchen.
  • Gebruik PNPM of Yarn voor meer configuratie. Zo heeft PNPM sinds kort een setting die voorkomt dat je binnen x tijd nieuwe packages kunt installeren
  • Laat packages geen post-install gebruiken, regel zelf welke packages dat wel mogen of run de taken daarvan handmatig. Bij pnpm is het bijvoorbeeld de --ignore-scripts voor CLI waar je het mee regelt.
  • Zet versienummers vast in je package.json. Dus geen ~ of ^. Je hebt dependabot en renovatebot om die dingen automatisch bij te werken en je schept hiermee meer veiligheid voor wie je project gaat installeren.
  • Gebruik alleen vertrouwde packages. Kijk goed wie de maker is en analyseer hoe goed ze de packages bijwerken of beveiligd hebben. Een fork van een package kan snel gemist worden in dergelijke audits.
  • Draai regelmatig "npm audit" om te zien welke packages problemen hebben en kijk of je daar wat aan kunt doen
  • Stel bij elke package de vragen "heb ik deze wel nodig?", "bevalt het update-beleid?"/"vertrouw ik de makers?"/"wat voor packages gebruiken zij zelf eigenlijk en werken ze deze goed bij?". Genoeg packages waar het uiteindelijk niet echt verstandig is om erbij te blijven. Mocht je twijfelen over bepaalde functionaliteit, dan kun je die beter overzetten naar je eigen projecten en/of packages.
  • Ga met makers van packages in gesprek om hun lijst met dependencies te verkleinen, om beter bij te werken en de community te gebruiken om informatie over dit soort aanvallen snel te verspreiden. Ga ook in gesprek om de packages beter te beveiligen en sta niet toe dat alles automatisch in de pipeline gebeurt zonder ook maar enige menselijke validatie door minimaal 2 afzonderlijke personen.
  • Ga met NPM/Github in gesprek en laten we er samen voor zorgen dat de beveiliging wordt verbeterd
Op die manier houden we NPM toekomstbestendig.
Het klinkt tegenstrijdig maar altijd de nieuwste versie gebruiken is niet veiliger. Dependencies upgrades doe je als je last heb van (security*) bugs, en voor de grote frameworks als je uit de support cycle loopt voordat je nieuwe versie uit komt.

Het beste wat je kan doen is SBOMs maken van je software, huidige supported versies en de development versie, en deze tracken op potentiële security issues. Er zijn vele tools beschikbaar voor SBOM creatie en monitoring. CycloneDX is een van de belangrijke open standaarden voor SBOMs, en er is veel tool support voor. OWASP Dependency Track is een vrije server voor monitoring.

Dit gaat niet alleen op voor de Node wereld, Ook voor voor Java, Python, Docker images, etc.

Als software provider doet het je goed om naast de software ook SBOMs te leveren aan je afnemers.

*) als je SBOMs gaat tracken krijg je heel veel ruis (ook met dependabot/renovate) over packages met security issues. Je moet zelf bepalen of die packages exploitable zijn via jou software. Dit kost tijd, some best veel. Maar maak dit onderdeel van je "dagelijkse" taken. Upgraden naar een nieuwe versie is ook niet gratis, en ook niet perse veiliger.

[Reactie gewijzigd door elmuerte op 19 september 2025 17:45]

Het beste wat je kan doen is SBOMs maken van je software, huidige supported versies en de development versie, en deze tracken op potentiële security issues. Er zijn vele tools beschikbaar voor SBOM creatie en monitoring. CycloneDX is een van de belangrijke open standaarden voor SBOMs, en er is veel tool support voor.
Wat is het verschil met de package-lock.json die door de NPM installer zelf wordt geleverd? Die bevat alle (te installeren) packages inclusief versienummer en security hash. Elke tool die voor node.js werkt kent dat ding.
OWASP Dependency Track is een vrije server voor monitoring.
Dependabot werkt via GitHub ook vrij goed is mijn ervaring. Vinkje aan in de security settings en het werkt. Veel simpeler kan volgens mij niet.
Een CycloneDX (of SPDX) is een standaard die door vele tools begrepen wordt. `package-lock.json` is slechts een npm ding. Binnen de Node wereld heb je ook pnpm en yarn, die hun eigen dependency lock file hanteren.

Dependabot levert geen tracing en monitoring op uitgeleverde versies. Die kijkt alleen naar the mainline branch. Het is ook alleen een feature voor de developer van een een project, op Github, niet voor een afnemer. Het is handig voor als je 1 project hebt waar je alleen naar de mainline kijkt. Maar het schaalt niet binnen je organisatie, of naar buiten.

Daar komen de SBOM dus te pas. Dus als je een node project beheert, voeg op z'n minst cyclonedx-npm toe, die een SBOM maakt en die je include in je published versies. Zeker voor end-user software (software dat direct gebruikt wordt ipv een library is om te importeren) zal dit steeds belangrijker worden. Vanuit de VS overheid is het al sinds 2022 een voorschrift om met SBOMs te werken. Wil je het vanuit NL oogpunt bekijken: https://www.ncsc.nl/documenten/publicaties/2023/juli/5/sbom-startersgids
Het klinkt tegenstrijdig maar altijd de nieuwste versie gebruiken is niet veiliger.
Klinkt opzich wel logisch, maar ik denk nu teveel aan consumentensoftware. Je ziet bijvoorbeeld tussen verschillende versies van Windows 10 dat functionaliteit ineens op een andere plek zit, het gaat dan om niet alleen een bugfix.

Ik las laatst iets over Linux en stables. Linux heeft geen echte stable versie, omdat bij een nieuwe versie niet alleen bugs gefixt worden, maar er worden tegelijkertijd nieuwe functies toegevoegd. Er komt dan wel een nieuwe stable, met bugfixes en zonder nieuwe features, maar die bugfixes zijn dan gebackport van de nieuwere versie (die wel features heeft). Die bugfixes op de stable zijn dus blijkbaar minder getest. Je moet dus kiezen tussen een nieuwe versie met nieuwe features (met mogelijke nieuwe problemen) of een versie met gebackporte bugfixes (minder getest). Althans zo begreep ik het.
Nog een mooi voordeel aan pnpm: enkel packages die handmatig zijn toegevoegd aan deze lijst in de package.json kunnen lifecycle hooks uitvoeren.

[Reactie gewijzigd door Jamie4242 op 20 september 2025 10:47]

Ja ik vind PNPM wel een fijne tool. Ik vind het zelf wel prettig dat ie packages hergebruikt om te installeren en dat ie geen conflicten geeft als je een package gaat wijzigen die aan anderen vast zit. Bij NPM moet je dan vaak je node_modules weggooien en/of je package-lock file, maar bij pnpm dus geen last van. Wel is het nog wat onduidelijk hoe het in de toekomst moet werken, want er was sprake van een migratie weg van corepack, maar vreemd genoeg is dat nog niet echt doorgezet. Al heb ik voor de zekerheid mijn pipeline er wel op aangepast. Ook dat je nu kunt instellen om niet op de bleeding edge te zitten maar met een paar uur vertraging als je pnpm install doet, vind ik een goede verbetering. Want dan filter je eigenlijk de meeste problemen er wel uit en heb je vaak ook al de bugfixes van de laatste update erin zitten voor als er toch net effe wat mis gaat met een nieuwe release.

Wel moet NPM zelf gewoon echt meer doen om de packages te testen en de community beter helpen door sneller te vermelden om wat voor malware iets gaat. Bovendien verwijderen ze nu vaak alle packages, terwijl dat helemaal niet nodig is, wat ook vaak meteen de hele pipeline stuk maakt van veel afhankelijkheden.

Daarnaast is die whitelist wel aardig, maar nog steeds een manier om op veel systemen te komen, al zal er natuurlijk beter op gelet worden.
Dank je voor deze chatgpt bijdrage. (kreeg exact dezelfde output, toen ik het over seucirty practices had in chatgpt, maar dan in het Engels)
Dit was anders gewoon zelf uit eigen ervaring samengesteld, daar heb ik voorlopig geen chatgpt voor nodig...
toch wel heel toevallig dan dat het precies hetzelfde is (maar dan in NL).
Echt op de zin af.
Haha. Leuk geprobeerd, maar nee. Als het ChatGPT was, had er op zijn minst 1 bullshit regel tussen gestaan en naar bronnen verwezen die niet bestaan...
Zelfs in de reguliere app stores van de Big IT bedrijven, die de meesten vertrouwen, zat tot voor kort heel wat malware. Tegenwoordig is dit beter.

Nu de de npm-packages in het vizier komen zal men hier meer beveiliging in moeten bouwen. Het is altijd al een kat en muis spelletje geweest.
En niet alleen voor IT, maar voor alle criminele activiteit.
Tbh: ik vind dat het nog lang duurde voor we dit zagen gebeuren. het blindelings overnemen van packages heb ik altijd al moeilijk begrepen. Niet vanuit de klanten die keuze voor de 'goedkoopste proposal' gaan, maar vanuit de markt die de oplossingen bouwt en voglens mij toch bewust moet zijn van het risico.
Vibe-coding helpt natuurlijk ook niet...
Blindeling overnemen ben ik het helemaal mee eens. De andere kant is dat er goede libraries zijn waarvan het zelf opnieuw ontwikkelen ook weer heel veel werk zou zijn. En elke keer de source code van a tot z checken is ook niet te doen.
Laat het effe binnenkomen 1 enkel geinfecteerd npm package heeft 2.8 miljoen downloads.

Eigenlijk is het gewoon omdat bedrijven hiermee wegkomen …

Waarom is een codereview niet mogelijk ? Zeker in deze AI tijden met blijkbaar ongekende hoeveelheden rekenkracht zou het hercompileren van packages vanaf de sourcecode perfect mogelijk moeten zijn. AI routines controleren dan op wijzigingen Ivm vorige versies.

Geen bestanden meer downloaden van online repositories maar wel de ongecompileerde sourcecode die je dan inhouse compileert voor jou applicaties

[Reactie gewijzigd door klakkie.57th op 19 september 2025 14:51]

Waarom is een codereview niet mogelijk ?
Heb je wel eens andermans code gereviewed? In packages die iets doen wat je zelf niet kunt/wilt bouwen? En sommige NPM's zijn er omdat vrijwel niemand de onderliggende ellende snapt. Ik ben erg grote voorstander van een grondige due dilligence, maar ik zie mijzelf de Bluetooth packages niet reviewen (terwijl ik 15 jaar professioneel code heb gereviewed), zelfs niet diegene die een "simpele" javaacript abstractie zijn over BlueZ.
Zeker in deze AI tijden met blijkbaar ongekende hoeveelheden rekenkracht zou het hercompileren van packages vanaf de sourcecode perfect mogelijk moeten zijn.
Compileren? Dit is Javascript, volgens mij is dit niet standaard precompiled maar wordt dat pas op het targetplatform door de JIT compiler gedaan ...

[Reactie gewijzigd door J_van_Ekris op 19 september 2025 15:21]

Het probleem is breder dan enkel javascript natuurlijk, men download maar wat van repositories en gaat die zonder nakijken gebruiken in eigen ontwikkelingen.
Dat is het anderste uiterste. Maar de meesten zijn niet zo naief. Maar wat jij voorstelt is totaal onrealistisch. Ik ben zelf package maintainer van een matig populair package en we leunen op best wel op wat geavanceerdere NPM packages, waaronder een Bluetooth en een Ant+ package. Ja, we kijken naar wie het gebruikt, en hoeveel downloads er zijn. We kijken zelfs naar de versiehistorie en GitHub om te zien wat de ontwikkeling zoal doet en hoe actief men issues oppakt. En we kijken welke GitHub security checks ze aan hebben staan.

Maar vervolgens ook nog eens andermans code op security issues gaan reviewen, eventueel met tools? Totaal onrealistische verwachting. Het is belachelijk veel werk, en toen ik er nog (per uur) voor betaald was het nog doenbaar. Maar een simpel project als het onze heeft al 631 onderliggende NPM dependencies. Het overgrote deel wordt weer door een ander NPM package indirect geinstalleerd. Sommige zijn klein, sommige zijn megacomplex. Maar voor een hobbyproject elk top-level NPM package, en zijn honderden dependencies, doorspitten is niet te doen.

En dat bij elke versiewijziging weer doen is gewoon helemaal niet te doen. Bij elke release werken wij onze dependencies met de hand bij, wat al veel werk is. Alleen de package list bijwerken en kijken of de boel niet instort met (combinaties van) nieuwe NPM packages is vaak toch al een dag werk. En daarna moeten we nog veel hardware gebonden testen doen om zeker te stellen dat we echt niets gesloopt hebben (en ja, dit gebeurt regelmatig).

Voor apt-get packages geldt eigenlijk hetzelfde: als je iets van x-windows installed (browser voor kiosk mode...) krijg je gelijk een complete desktop. Ga je ook verwachten dat we de gehele X-windows desktop omgeving gaan reviewen?

Je vraag is theoretisch een leuk idee, maar in praktijk een totaal onzinnige verwachting.

[Reactie gewijzigd door J_van_Ekris op 19 september 2025 16:19]

Dus we aanvaarden het risico ?
Dan moeten afnemers van een software of tool ook compleet vergoed worden als het misloopt lijkt me ? Wat niet zo is …

Maw de eindgebruiker is altijd de pineut.. het zullen jouw medische gegevens maar zijn die op straat liggen, of jouw bitcoinwallet die van de ene op de andere dag leeg is ….

🤯
Geen pc gebruiken of alleen eigen (volledige) geschreven software gebruiken inclusief je os en voila.
Je maakt het gewoon belachelijk maar totaal naast de kwestie …

Een leven zonder software kan niet meer, bedrijven zouden er ALLES aan moeten doen om hun eindgebruikers te beschermen maar ze komen er steeds mee weg. Het risico op een monsterboete is nagenoeg onbestaande, laat staan dat verantwoordelijken in de gevangenis zouden belanden

wat is het verschil tussen een arts die een medische fout maakt of een bedrijf die door een geldzucht bespaart op “security” en hierdoor iemands levensspaargeld ziet verdwijnen 🤷🏻‍♂️

[Reactie gewijzigd door klakkie.57th op 20 september 2025 16:35]

wat is het verschil tussen een arts die een medische fout maakt of een bedrijf die door een geldzucht bespaart op “security” en hierdoor iemands levensspaargeld ziet verdwijnen 🤷🏻‍♂️
Klinkt hard, maar mensen die denken dat ze een ongelimiteerd budget/tijd hebben zullen nooit de eindstreep halen. Het is misschien teleurstellend, maar er is altijd een stap extra die gezet kan worden. Waarom stoppen bij een enkele code review? Waarom niet tien reviews? Waarom niet 10 keer zoveel testen?

Op een gegeven moment is het goed genoeg. Dit geldt zelfs als het letterlijk om leven of dood gaat. Professioneel zit ik nu zo'n 30 jaar in de zeer veiligheidskritische software ontwikkeling in verscheidene domeinen (denk kerncentrales, treinbeveiliging, avionica, etc..). Daar is per domein vastgesteld wanneer de industrie en stakeholders vinden dat het grondig genoeg is. In veel gevallen kun je meer doen, maar op een gegeven moment moet een veiligheidssysteem ook in productie, want je hebt niets aan veiligheidsfuncties als ze niet on-site actief zijn.

En dat geldt voor de meeste domeinen. Een arts die kan altijd een extra test doen voor de diagnose. Maar op een gegeven moment moet de patient behandeld worden en de moet de zorg betaalbaar blijven. En dus wordt een arts wordt beoordeeld op het volgen van het behandelvoorschrift.

[Reactie gewijzigd door J_van_Ekris op 20 september 2025 19:08]

Zelf ooit software geschreven (buiten "Hello World") dan zou je weten dat het niet zo simpel is als je met wat uitgebreide programma's komt (en nee die webpagina met wordpress of wix telt niet mee).


Dan is er nog wat is goed genoeg ? Je kan eens testen, en nog eens testen en nog eens testen. Je kan dat ook 100x doen. Je kan 10 codereviews doen, je kan er 100 doen en dan nog ben je niet zeker. Er worden zelfs nog dingen gevonden die soms al 10 jaar aanwezig zijn en voor sommige exploits moet je echt "een fucked up mindset hebben" om al deze dingen te doen en te vinden.

Dat wilt niet zeggen dat domme fouten nog zouden mogen gebeuren zoals bijvoorbeeld wachtwoorden zonder encryptie opslagen. Maar langs de andere kan, als iemand mijn databank kan bemachtigen, dan kunnen ze nadien ook wel bruteforcen hoor, want ongetwijfeld hebben ze tijd. En als iemand jou wilt hacken dan zal je gehacked worden. Je kan je alleen maar zo onaantrekkelijk mogelijk maken. Maar als jij nu bijvoorbeeld functie x gebruikt en daar is een 0 day voor ... wel dan is al actief misbruikt geweest in het verleden.

Heb je al ooit eens gezien wat je soms allemaal moet doen voor een bepaalde exploit ... sorry maar daar test echt niemand op hoor. Daar is in 99% van de bedrijven geen tijd en/of geld voor. Als ik al gewoon mij logs bekijk ... dan zie ik heel veel "penetration test" voor vanalles en nog wat. Het grote probleem is dat er veel geld mee te rapen valt.
Bedrijven nemen hun “due dilligence” gewoon maar al te vaak niet serieus, de gevolgen ach ja dat is dan maar zo het gros van de particulieren heeft toch niet de financiële armslag om hen aan te klagen

Dus laten we het gewoon oneens zijn met mekaar, dat kan ook 🤷🏻‍♂️
bedrijven zouden er ALLES aan moeten doen om hun eindgebruikers te beschermen
Als ze ALLES er aan moeten doen wordt er nooit software gereleased. Dan ben je namelijk tot het eind der tijden bezig. Je mag zeker enige due diligence verwachten, maar feilloze software bestaat alleen in sprookjesland.

Er is altijd een bepaalde mate van risico als je software gebruikt. Als eindgebruiker heb je daar ook een verantwoordelijkheid bij. Je kan zelf ook er voor kiezen geen op Javascript gestoelde applicaties meer te draaien.
95% van de programmeurs doen maar op hoor. Ik programmeer professioneel sinds 1999 maar eigenlijk al vanaf ik +- 10 jaar ben en ben er nu 46. Package downloaden, doe maar en gelijk gebruiken, zonder ook maar eens te kijken wat het doet. Maar het is allemaal gemakkelijk om te roepen ja maar en je moet dit checken etc. De gemiddelde programmeur is niet zo denderend hoor en blijft echt wel bij de basis. En ga maar eens van complexe libraries alles even scannen. Bekijk maar eens een module over ssl of iets dat moet interface met hardware zoals bluetooth. Dan is er de tijdsdruk, het moest gisteren klaar zijn, niet morgen. En dan krijg je dus deze dingen. Als ik externe packages gebruik, dan bekijk ik deze wel altijd even. Maar er is een verschil tussen bepaalde dingen. En dan zijn er nog dingen zoals bijvoorbeeld google maps ofzo, componenten die je gaat gebruiken. Er zijn altijd mensen die dat scannen.

Maar ik geef je volledig gelijk, er is een punt dat het niet meer haalbaar is. Ik gebruik trouwens ook linux en apt-get tsja dat doe je als het nodig is et voila. Ken gerust C++/C maar dat ga ik echt niet helemaal uitspitten. En 20-25 jaar geleden gingen mensen ook zips/exes downloaden en gewoon uitvoeren op hun machine. Doen ze vandaag nog. Alleen als jij in een simpel package iets kan injecteren en vele andere projecten maken daar gebruik van, tsja dan hebben die andere projecten pech om het zo te zeggen.

Wat ik de afgelopen jaren wel ben beginnen te doen is kijken, heb ik dit nou echt nodig en als het niet echt veel is, dan schrijf ik het zelf wel. Maar is dat altijd beter ... nee want je kan ook niet van alles up to date blijven
Beetje project heeft zo honderden als niet meer packages. Ga jij echt alle code doorlopen met elke update?

Het probleem is dat je tegenwoordig zo verschrikkelijk veel packages nodig hebt zodra is iets met frontend gaat doen. Nouja perse nodig misschien niet maar het hele ecosysteem stuurt je die kant op. Moet je maar eens kijken in je package lock json wat daar allemaal wel niet in staat.

Veel populaire packages worden dan ook nog eens door een enkeling onderhouden. Bedrijven verwachten dat men dat maar gratis doet en staan niet echt open om OSS financieel te ondersteunen.

Wat ik vooral probeer te zeggen is dit is een veel dieper probleem dan ff zelf een check doen.

[Reactie gewijzigd door Barsonax op 19 september 2025 15:22]

Beetje project heeft zo honderden als niet meer packages. Ga jij echt alle code doorlopen met elke update?
Neen dat moet een AI agent automatisch doen, dat was net mijn punt
Een AI kan helpen maar is echt niet genoeg om hiertegen te helpen.
Verplaatsing van het probleem. Wie zal de Ai agent reviewen?
Lol ... een projectje van 2500 lijnen slaagt dit al dikwijls tilt op. Zeker als je een paar trucjes links en rechts gaat uithalen voor snelheid etc, waar zo een ai in de verste verte niet mee omkan.

Zelfs testen schrijven werkt voor geen meter. En heb je al ooit eens bepaalde exploits gezien, daar moet je een fucked up mindset voor hebben (althans zo noem ik het toch). Vergeet dit AI dus maar.

Zelfs nu worden er nog dingen gevonden die soms al jaren of meer dan 10 jaar aanwezig zijn
Malicious code injecteren in en package, heeft niets te maken met de moeilijkheid van een exploit waarmee ze dit gedaan hebben.

Bij mijn weten verandert een file nog altijd wanneer je extra code injecteert, deze wijziging zou alle alarmbellen moeten doen afgaan. AI kan hier ook perfect helpen , door de wijzigingen tussen verschillende files te vergelijken en hier patronen in te gaan herkennen. 4/6/8 eyes principle toepassen vooraleer code approved wordt Zou ook al een groot verschil kunnen maken

Je kan vanalles bedenken, maar de meeste “developers” vinden alles al snel te moeilijk of teveel overhead, en dan zijn we weer bij af want deze onverschilligheid heeft toch geen gevolgen.

[Reactie gewijzigd door klakkie.57th op 21 september 2025 00:13]

Das juist, de meeste programmeurs hebben weinig kaas gegeten van veel dingen en houden zich gewoon bezig met "code rammen". OS kennis: dikwijls een ramp (of het nu Windows/Linux/Macos is), netwerk ... das te ingewikkeld. Het grote probleem is: de essentie. Ik geef ook zo een cursus voor volwassenen van 0 tot volledige (web)applicaties bouwen. Nu zijn daar ook nog andere opleidingen en daar is zo een docent die een stuk van een vak geeft ... Hij kent veel termen en het enige wat telt is zijn uurloon, maar daarbuiten is het volgend mij weinig soeps, want zo te zien heeft hij nog nergens langer dan 6 maanden volgehouden. Uiteraard kan het zijn dat je altijd kleine projecten doet, maar lijkt me bizar. Maar hij "kent" de populaire dingen, hij kan ze gebruiken, maar de essentie of wat er allemaal achter zit heeft hij geen flauw benul van. Moet dit nu altijd, nee maar het is toch wel handig. Maar dit is zo bij zeer veel programmeurs die ik ben tegengekomen.
Javascript is ongecompileerde sourcecode. ;)

Maar Rust doet dat ook, een ongecompileerde library downloaden. Maar daar krijg je weer het commentaar "compileren doet er lang over". Dus dat komt zeker met nadelen. Het gaat ten koste van de ontwikkel snelheid. En tijd is geld. Of nieuwe features.

Het kán wel, maar kost wel veel van een organisatie. Een lokale kopie, deze continue bijhouden, reviewen van de wijzigingen (zonder dat je kennis over die library hebt), compileren. Daar gaat veel tijd (en geld) in zitten. Vervang je dat door een lokale package manager die claimt te controleren op veiligheid, dan is dat voor de meeste bedrijven al voldoende. Of je update je libraries niet. Maar daar zitten ook weer risico's aan en heb je problemen met developers die niet met oude zooi willen werken.
Overigens zijn beide gevallen in een paar uur opgelost. Dus dat blindelings is niet bepaald het geval. Want er word dus daadwerkelijk naar gegeken.
Alles zelf schrijven heeft buiten de kosten in tijd ook enorme risico's. Neem bijvoorbeeld cryptografische/authenticatie libraries. De open source versies daarvan worden door duizenden zo niet meer gebruikers bekeken en getest, ze zijn niet foutloos, maar wel veel zwaarder getest dan iets wat je zelf maakt en elke fout die de rest al heeft opgelost nog een keer doorloopt.

Een software project komt als het goed is met een test suite (lang niet altijd natuurlijk, kosten tijd etc), Maar als je test dan ga je de vreemde gedragingen van malware gewoon zien. De performance van je software is ineens lager, vreemde porten gaan open. Andere payloads. Er zijn vele triggers. Nog buiten virusscanners die triggeren op de malware die de packages installeren.

Ja, we (developers) zullen wat voorzichtiger worden. Maar de voordelen van npm en soortgenoten zijn vele malen groter dan de nadelen.

Oh en je kan ook nog een eigen repo voor packages opzetten. Dan trek je alleen de door jou bedrijf "approved" versie naar binnen en laat je de nieuwste versie even voor wat het is tot die een tijdje uit is. Nog een mogelijk laagje om problemen te vermijden.


Vibe coding is een interessante. Als je capabel bent en weet wat je vraagt en doet, kan het resultaat prima zijn. Niet meer dan een spraakgestuurde assistent voor je werk. Kan een verlamde ook programmeren. Een betere versie van bv de Talon programing voice recognition tool. Helaas is vibe coding een tool waar vaak juist door noobs naar gegrepen word.... Met alle gevolgen van dien.

[Reactie gewijzigd door bzuidgeest op 19 september 2025 14:58]

Ja, we (developers) zullen wat voorzichtiger worden. Maar de voordelen van npm en soortgenoten zijn vele malen groter dan de nadelen.
Ik lees dat niet in je onderbouwing en het nieuws. De praktijk is namelijk niet dat de nadelen zomaar acceptabel risico zijn als het mis gaat. Dat gaat vooral op als je niet tot nauwelijks aansprakelijk gesteld kan worden of als slachtoffers of het openbaar ministerie je niet verantwoordelijk stellen. Dat is waarschijnlijk leuk voor amateur ontwikkelaars met enkele gebruikers, maar niet voor professionals en zakelijke leveranciers. Omdat een deugdelijk product of dienst leveren tegenwoordig niet meer de betekenis heeft dat je dan maar slechts een beetje moeite hoeft te doen om verantwoordelijkheid af te schuiven op onbekenden of op een aankoop.
Ik kan niet veel maken van je reactie, waar heb je het over?
Ik denk dat wordt bedoeld dat wij zijn verplicht om zaken via het web te regelen. Veiligheid moet gegarandeerde zijn en iemand zal toch wettelijk aansprakelijk zijn voor eventueel schade.

[Reactie gewijzigd door moimeme op 20 september 2025 19:50]

Het heeft zeker lang geduurd en het zal alleen maar erger worden gok ik. Toen ik 15 jaar geleden als webdeveloper begon werd bijna elke regel code die in een project zat zelf geschreven. Van alle code die tegenwoordig nog in projecten aanwezig is wordt meestal maar minder dan 1% zelf geschreven. Van die 99% weet je dan voor een deel nog hoe het werkt en waarom het er zit, maar er zitten zoveel packages diep verscholen in de dependency hell dat je van het meerendeel echt niet weet wat ze doen en waarom ze er zitten, laat staan van wie ze zijn en wie ze onderhoud.

Projecten met 1000 dependencies zijn niet zo gek, dus dat daar eens iets fout gaat doordat ergens in de keten er iets gecompromitteerd wordt zal zeker vaker gebeuren. Het zou al helpen als de dependency hell wordt aangepakt. Sommige packages bieden een functie van slechts 1 tot 10 regels, dat is je reinste onzin.

Het is ook niet fijn dat MBO's maar zeggen 'Bouw je applicatie maar op Laravel en Next' zonder dat jonge ontwikkelaars precies weten wat ze nou doen.
Wat dit betreft hebben we echt nog heel veel stappen te zetten. Menig bedrijf vind security test tooling (SCA/SAST/DAST) te duur. Laten we hopen dat NIS2/Cyberbeveiligingswet hier stappen in gaat zetten dat het een verplichting gaat worden. Verhelpt dit dan het probleem? Nee maar het creëert wel meer inzicht.

GenAI-coding assistenten gaan hier ook niet mee helpen doordat de cut-off datum van modellen in een (ver) verleden ligt. 'Scaffold a NodeJs application that does ...' trekt al gauw dependencies van tig maanden oud naar binnen.

[Reactie gewijzigd door Joost1981_2 op 19 september 2025 14:47]

Ik denk dat je de AI kan vertellen om van elke package de meest recente versie te pakken... Dat doet hij bij mij tenminste. Zijn index gaat wellicht over de oudere versie, maar de package manager kent vast een equivalent van "latest" in elk geval. En je kan altijd nog naar specifieke versie vragen.
De JS cultuur wat betreft dependencies helpt ook niet mee. Het is bijna tien jaar na left-pad en nog steeds heeft men niets geleerd: een "hello world" app in React heeft al duizenden dependencies. Krankzinnig amateurisme.
Ik lees eigenlijk nergens echt hoe je nu hier mee om moet gaan. Vaak zitten die dependencies zo diep dat je moeilijk kunt achterhalen of je risico loopt en/of npm install in dat geval veilig is… zo’n monitor is leuk maar dan moet je vaak al een install gedaan hebben.
Dank voor het interessante stuk. _/-\o_
Deel van het probleem is Node zelf: gedownloade packages (in de node_modules folder) hebben out of the box heel veel (te veel) permissies op het file-system.

Er is een alternatief : Deno, the next-generation JavaScript runtime welke standaard alleen lees rechten zet, en waar je zelf actiever aan de slag moet met rechten beheer. Ben zelf al een tijdje uit de Javascript game, geen idee wat de adoptie is.


Om te kunnen reageren moet je ingelogd zijn