Het vastzetten van je dependencies helpt hier ook goed tegen. Niet automatisch zomaar minor/bugfixes naar binnen trekken.

Ik heb nooit begrepen waarom het gemak van package managers vaak belangrijker wordt gevonden dan de veiligheid van je systeem.

Een docent van mij zei ooit: "Een luie ontwikkelaar is een goede ontwikkelaar," nadat ik aangaf dat ik liever mijn eigen softwareoplossingen schrijf dan simpelweg npm install te gebruiken (en duizend extra onbekende afhankelijkheden naar binnen trek).

Worden niet met een private key gesigned ?

Als ervaren software ontwikkelaar kan ik je zeggen dat het gebruiken van kwalitatief goede bibliotheken en frameworks het mogelijk maakt om zowel sneller als beter software te ontwikkelen. (Met het voordeel dat programmeurs sneller ingewerkt raken als ze bibliotheken en frameworks al kennen.)
Daar tegenover staat dat je de externe code ook moet bijhouden, "Dependency management" kost ook tijd. Je zult per project de gouden middenweg moeten vinden tussen zelf schrijven en downloaden. Veiligheids- en kwaliteitseisen zijn belangrijke overwegingen bij het bepalen van de juiste balans.

Ik dacht dat het project altijd op github stond.

ChatGPT zei:
Dus weer een supply-chain-klassieker: een npm-package met 2,8 miljoen downloads per week wordt geïnfecteerd omdat iemand zijn 2FA niet had ingeschakeld. In 2025. Voor een package-manager die miljarden projecten voedt. Dat is alsof je de deur van een goudkluis openlaat en zegt: “Maar ik vertrouw de buurt.”

Het bizarre is hoe dit ging: de maintainer krijgt een bericht van de “vorige eigenaar”, gelooft het verhaal, voegt hem toe aan het project, en bam: de volgende ochtend een besmette release. Dit is social engineering op maintainer-niveau. En opnieuw blijkt: supply-chain security hangt aan het dunne draadje van menselijk vertrouwen.

De malware zelf is platform-onafhankelijk en steelt alles wat los en vast zit. Niet verrassend, maar wel pijnlijk voor miljoenen developers die blind npm install draaien.

Het wrange? Dit is geen uniek incident. Phishing, gekaapte accounts, en een gebrek aan verplichte 2FA blijven de achilleshiel van open-source ecosystems. Npm heeft wel 2FA-opties, maar als het niet standaard verplicht is voor populaire packages, is dit wachten op ellende.

Het goede nieuws: er zijn opgeschoonde versies. Het slechte nieuws: wie checkt bij een CI/CD-pipeline vol automatische builds of die besmette versie al gedraaid heeft?

Als er één takeaway is: blind vertrouwen op de open-source keten zonder security policies is geen “move fast and break things” meer. Het is “move fast and get owned.”

Dat geldt net zo goed voor closed source... En dan kun je niets controleren.
Les je zult altijd version management moeten doen, weet wat je gebruikt hetzij door grondig onderzoek, danwel door zelfbouw.

Het is allemaal open source, publiek repositories - waarom zoek je zelf niet het antwoord op je vraag, en _geef_ je het antwoord ?

Stel nou's dat je een echte baan hebt , als security officer ergens, en wordt software ontwikkeld (met npm) , en JIJ moet een risico analyse maken - dan is het AAN JOU om dit soort dingen uit te zoeken, en dat mee te tellen in je rapport qua risico's .

Dus ga nu dat eens oefenen.

+

Precies. Een gehackt account hoeft niet erg te zijn, Uiteindelijk wordt het door maintainers gereviewd alvorens het voor productie wordt goedgekeurd als het project goed wordt opgezet. Discipline is belangrijk. Ik heb voor een closed source bedrijf gewerkt waar 1 persoon de boel had gesaboteerd en dit door mij ontdekt kon worden door de diffs achteraf goed te bekijken.
Het was al in productie omdat de saboteur alle rechten had en zonder medeweten van anderen nieuwe releases kon maken.