supply chain

NCSC: wacht een week met dependency-updates

Het NCSC publiceerde gisteren een expertblog over supply chain-aanvallen via pakketregisters. De boodschap is direct: de vraag is niet óf een van uw afhankelijkheden gecompromitteerd raakt, maar wanneer. En de simpelste tegenmaatregel is verrassend laagdrempelig — gewoon even wachten.

Auteur Sander 31 juli 2026 5 min read

Dit is een vervolg op onze post over kwaadaardige Python-pakketten en ketenverantwoordelijkheid onder NIS2.

De kern in het kort

Onderwerp	Advies NCSC
Cooldown-periode	Circa 7 dagen voor reguliere updates
Beveiligingsupdates	Direct installeren — geen cooldown
Versiepinning	Pin op hash, niet op versienummer
Install-scripts	Standaard uitschakelen (`--ignore-scripts`)
GitHub Actions	Pin op commit-SHA, niet op tag
Advisories	Moeten teams binnen enkele uren bereiken

Het scenario dat het NCSC schetst

Een ontwikkelaar voert op een doordeweekse ochtend een routine-update uit. Beveiligingsbewust als hij is, rolt hij updates zo snel mogelijk uit. De build slaagt, de tests staan groen.

Wat hij niet ziet: de installatie voerde zelf een script uit. Nog vóórdat de build begon, verzamelde dat script inloggegevens, cloud-tokens en sleutels uit de omgeving en stuurde die naar een server van de aanvaller. De tests draaiden pas daarna — en die controleren dit soort gedrag niet.

Het NCSC benadrukt dat dit geen hypothetisch scenario is, maar precies wat de afgelopen maanden steeds vaker gebeurt.

Waarom pakketregisters het doelwit zijn

Het NCSC noemt twee redenen waarom npm en PyPI zo aantrekkelijk zijn voor aanvallers.

Het bereik is enorm. Eén gecompromitteerd pakket raakt alle projecten die het binnenhalen — vaak indirect, als afhankelijkheid van een afhankelijkheid. Ontwikkelaars weten meestal niet welke transitieve dependencies hun project meetrekt.

Het misbruik is volledig automatiseerbaar. Zodra een aanvaller het account van een maintainer overneemt, worden alle pakketten van die maintainer geautomatiseerd besmet. Er is geen handmatig werk meer nodig.

En het vertrouwen stopt niet bij pakketten. Uw CI/CD-pipeline gebruikt GitHub Actions van derden, uw editor laadt externe extensies, uw container haalt images uit een extern register — en de securityscanner die uw code controleert heeft zelf ook weer afhankelijkheden. Elke schakel is een mogelijk punt van binnenkomst.

De incidenten van het afgelopen jaar

Het NCSC zet vier campagnes op een rij die samen laten zien hoe snel dit veld evolueert.

Shai-Hulud (september en november 2025)

Via phishing gericht op maintainers werden publicatietokens buitgemaakt. De malware publiceerde vervolgens automatisch besmette versies van álle pakketten waarop die maintainer rechten had. In de tweede golf verschoof de code van een postinstall- naar een preinstall-script — waardoor die al draaide vóórdat de installatie was afgerond, en detectie die op postinstall let werd omzeild.

Binnen enkele uren na ontdekking waren ruim 700 pakketten besmet en lagen circa 14.000 secrets van 487 organisaties op straat.

Van securityscanner naar hele ecosystemen (maart 2026)

Via een verkeerd geconfigureerde GitHub Actions-workflow bemachtigden aanvallers een token van de leverancier van een veelgebruikte securityscanner. De leverancier roteerde de credentials — maar niet volledig. De aanvaller behield toegang.

Vervolgens werden versietags van de scanner-action overschreven, zodat bestaande verwijzingen in duizenden pipelines naar code van de aanvaller wezen. De kwaadaardige code draaide vóór de eigenlijke scan, waardoor pipelines er normaal uit bleven zien.

De les: onvolledige rotatie van credentials geeft schijnzekerheid. Dit incident kon zich voortzetten juist omdát de rotatie niet compleet was.

Mini Shai-Hulud (april en mei 2026)

Begon met vier besmette npm-pakketten uit het SAP-ecosysteem. Opvallend was de publicatieroute: de aanvaller misbruikte GitHubs OIDC-gebaseerde trusted publishing om kortlevende publicatietokens te bemachtigen — precies het mechanisme dat ná Shai-Hulud als verbetering was ingevoerd.

In een tweede golf groeide de campagne uit tot honderden malafide pakketten op npm en PyPI, waaronder packages van TanStack, Mistral AI, UiPath en OpenSearch.

Verdere escalatie (mei en juni 2026)

Bij PyPI draaide malware via padconfiguratiebestanden (.pth) die Python automatisch verwerkt zodra de interpreter start — geen import en geen installatiescript nodig.

In mei stond een besmette VS Code-extensie achttien minuten in de marketplace. Lang genoeg voor duizenden installaties, waaronder op het apparaat van een medewerker van een grote platformleverancier.

En in juni bevatte een reeks PyPI-pakketten verborgen tekst die AI-gebaseerde scanners moest overtuigen de code als onschuldig te classificeren — een prompt-injectie. Diezelfde malware dreigde met destructieve acties zodra gestolen tokens werden ingetrokken, om rotatie te ontmoedigen.

Uw beveiligingstooling is ook een afhankelijkheid

Dat laatste punt verdient aparte aandacht, want het raakt direct aan wat we eerder schreven over prompt injection.

Malware wordt inmiddels geschreven om AI-gebaseerde scanners te misleiden. De aanvaller plaatst instructies in de pakketinhoud die de scanner interpreteert als commando in plaats van als te analyseren materiaal.

Het NCSC formuleert daarom twee concrete eisen aan AI-scanning:

De inhoud van een te scannen pakket mag nooit de instructies van de scanner zelf kunnen overschrijven
Pakketten die niet goed geanalyseerd konden worden, mogen niet automatisch als veilig worden bestempeld

Gebruikt u een externe scandienst? Dan zijn dit de twee vragen die u aan uw leverancier stelt.

De cooldown: waarom wachten werkt

De logica achter een cooldown-periode is eenvoudig. De overgrote meerderheid van gecompromitteerde releases wordt binnen enkele uren opgemerkt en verwijderd. Wie niet als eerste installeert, laat de rest van het ecosysteem het testwerk doen.

Het NCSC noemt circa een week als effectieve richtlijn, omdat gecompromitteerde releases vrijwel altijd binnen zeven dagen worden ontdekt en verwijderd. Er is geen formele standaard, maar het principe wordt breed ondersteund — door package managers als npm en Yarn, en door update-tooling als Renovate en Dependabot.

Belangrijk onderscheid: een cooldown geldt voor reguliere feature-updates, niet voor beveiligingsupdates. Een bekende kwetsbaarheid uitstellen is het risico laten bestaan. Het NCSC is daar helder over: reserveer snelle updates voor beveiligingsupdates en behandel reguliere updates terughoudender.

En wat een cooldown níét doet: hij beschermt niet tegen typosquatting, niet tegen een maintainer die maandenlang wordt gecompromitteerd (zoals bij xz-utils), en niet tegen kwetsbaarheden in pakketten die u al heeft geïnstalleerd. Het is één laag, geen oplossing.

De drie maatregelen om vandaag te beginnen

Het NCSC sluit af met drie maatregelen die de beste verhouding tussen inspanning en effect hebben — en die alle drie binnen een dag zijn in te voeren:

1. Stel een cooldown-periode in voor dependency-updates
In Renovate en Dependabot is dit een configuratie-instelling (minimumReleaseAge). GitHub hanteert inmiddels standaard drie dagen voor Dependabot version updates; beveiligingsupdates blijven direct openen.

2. Pin GitHub Actions op een volledige commit-SHA in plaats van op een tag
Tags kunnen worden overschreven — dat is precies wat er in maart 2026 gebeurde. Een commit-SHA kan dat niet.

3. Schakel installatiescripts standaard uit
Gebruik npm ci --ignore-scripts en werk met een expliciete uitzonderingslijst voor pakketten die de scripts echt nodig hebben. Pre- en postinstall-scripts zijn het meest gebruikte vehikel voor deze malware.

Monitoring: waar u op let

Preventie is niet genoeg. Het NCSC noemt een aantal signalen die u actief zou moeten monitoren:

Onverklaarbare versieverhogingen en wijzigingen in publicatiegemachtigde accounts
Nieuw aangemaakte publieke repositories onder uw organisatie- of medewerkersaccounts
Registratie van onbekende self-hosted runners — een bekend persistentiemechanisme
Afwijkend gebruik van authenticatietokens binnen CI/CD-pijplijnen
Wat uw pipeline daadwerkelijk installeerde en met welke bestemmingen hij verbinding maakte — niet alleen wat het manifest voorschrijft

Eén punt springt eruit: het NCSC stelt dat security advisories de juiste teams binnen enkele uren moeten bereiken. De blootstellingsvensters in de beschreven incidenten liepen van achttien minuten tot enkele uren. Een wekelijkse securitynieuwsbrief is dan te traag.

De NIS2-verbinding: over 15 dagen

De timing van deze publicatie is relevant. Op 15 augustus treedt de Cyberbeveiligingswet in werking, met een expliciete zorgplicht voor beveiliging van de toeleveringsketen als een van de tien verplichte maatregelen.

Wat dat concreet betekent voor softwareontwikkeling binnen NIS2-plichtige organisaties:

U moet aantoonbaar grip hebben op ketenrisico's — een SBOM per build is daarvoor het meest praktische instrument
Uw incidentresponsproces moet supply chain-scenario's dekken, inclusief de meldplicht binnen 24 uur
De maatregelen die u treft moeten gedocumenteerd zijn, niet alleen geïmplementeerd

Het NCSC noemt de SBOM expliciet als ondersteuning van het incidentresponsproces: bij een incident stelt u daarmee snel vast of uw applicatie een malafide afhankelijkheid gebruikt. Zonder SBOM begint dat onderzoek bij nul.

Als het toch misgaat

Het NCSC geeft ook een responsvolgorde. Vier punten die opvallen:

Bewaar eerst bewijsmateriaal, bouw daarna opnieuw op. Niet opschonen — herbouwen.

Roteer volledig. Inventariseer eerst álle plekken waar een blootgestelde credential kan liggen, roteer daarna, en controleer vervolgens of er niets is overgeslagen. Niet alleen omgevingsvariabelen, maar alles wat een proces kan opvragen — inclusief secrets uit een vault.

Zoek naar persistentie voordat u afsluit. Nieuwe deploykeys, nieuwe tokens, gewijzigde workflows, onbekende self-hosted runners, toegevoegde configuratiebestanden.

Controleer of u zelf iets heeft gepubliceerd tijdens de compromittatie. Zo ja, dan bent u van slachtoffer een schakel geworden — en verandert het informeren van klanten van hoffelijkheid in noodzaak.