Het nieuwe Trojaanse paard zit in je dependencies

De vraag is niet óf een van jouw dependencies (afhankelijkheden) ooit gecompromitteerd raakt, maar wanneer. In deze blog lees je hoe deze aanvallen werken, wat recente incidenten ons leren en welke maatregelen je vandaag nog kunt nemen.

Een routine-update met een addertje onder het gras 

Stel je voor: als ontwikkelaar voer je op een doordeweekse ochtend een routine-update uit. Je bent security-bewust, dus je rolt updates zo snel mogelijk uit. De build slaagt, de tests staan op groen. Je neemt een slok koffie en geniet even van een goed begin van de dag.
Wat je niet ziet, is dat de installatie zelf een script uitvoerde. Nog voordat de build begon, verzamelde dat script inloggegevens, cloud-tokens en sleutels uit je omgeving en stuurde het die naar een server van kwaadwillenden. Je tests draaiden pas daarna, en die controleren dit soort gedrag niet.
Dit is geen hypothetisch scenario. Het is precies wat de afgelopen maanden steeds vaker gebeurt.

Wat is een softwaresupplychain-aanval?

Bij een supplychainaanval compromitteert een aanvaller niet jouw organisatie, maar iets wat jij binnenhaalt en uitvoert: een software library, een build-script, een container-image, een pipeline-actie of een editor-extensie. Jij haalt die afhankelijkheid nietsvermoedend binnen en zet daarmee zelf de deur open. De aanvaller hoeft dus niet door jouw beveiliging heen te breken. (1)

Softwareontwikkeling berust op vertrouwen

Dat vertrouwen houdt niet op bij de pakketten die je installeert. Je CI/CD-pipeline gebruikt GitHub Actions van derden, je editor laadt externe extensies, je container haalt images uit een extern register, en de securityscanner die je code controleert heeft zelf ook weer afhankelijkheden. Elke schakel is een mogelijk punt van binnenkomst.

Juist pakketregisters als npm en PyPI worden nu als doelwit gekozen. Ten eerste is het bereik groot: met één gecompromitteerd pakket raakt een aanvaller alle projecten die dat pakket binnenhalen, vaak indirect als afhankelijkheid van een afhankelijkheid. Ten tweede is het misbruik van een buitgemaakt token volledig te automatiseren. Na overname van een account van een maintainer, worden alle pakketten van die maintainer geautomatiseerd besmet.

Wat recente incidenten laten zien

Een kleine greep uit de campagnes van het afgelopen jaar:

• September en november 2025, Shai-Hulud (npm). Via phishing gericht op maintainers werden publicatietokens buitgemaakt. Daarmee publiceerde de malware automatisch besmette versies van alle pakketten waarop de maintainer publicatierechten had. In de tweede golf verschoof de code van een postinstall- naar een preinstall-script, waardoor die al draaide vóórdat de installatie zelf was afgerond. Dat verbreedde het bereik en omzeilde detectie die vooral op postinstall-scripts let. Binnen enkele uren na ontdekking waren ruim 700 pakketten besmet en lagen zo'n 14.000 secrets van 487 organisaties op straat. (2)
• Maart 2026, van securityscanner naar hele ecosystemen. 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 gestolen gegevens werden hergebruikt om pakketten op Docker Hub, npm, PyPI en OpenVSX te compromitteren. (3)
• April en mei 2026, Mini Shai-Hulud. Het begon met vier besmette npm-pakketten uit het SAP-ecosysteem die bij installatie tokens en cloudcredentials stalen. Opvallend was de publicatieroute: de aanvaller misbruikte GitHubs OIDC-gebaseerde trusted publishing om kortlevende publicatietokens te bemachtigen, precies het mechanisme dat na 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. (4)
• Mei en juni 2026, verdere escalatie. Bij PyPI draaide de malware via padconfiguratiebestanden (".pth"-bestanden) 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. In juni bevatte een reeks PyPI-pakketten verborgen tekst die AI-gebaseerde scanners moest overtuigen de code als onschuldig te classificeren: een zogenoemde prompt-injectie. Diezelfde malware dreigde met destructieve acties zodra gestolen tokens werden ingetrokken, om rotatie te ontmoedigen. (5)

Wat uit deze incidenten te leren is

• Eén gestolen token is genoeg om honderden pakketten te besmetten.
• Malafide code draait steeds vroeger: tijdens de installatie of zelfs bij het starten van de interpreter, dus vóór je tests en scans. 
• Aanvallen verspreiden zich automatisch. Na de eerste inbraak hoeft de aanvaller weinig meer zelf te doen.
• Veel verschillende ecosystemen worden geraakt: npm, PyPI, container-images, GitHub Actions en editor-extensies.
• Ook je beveiligingstooling is een afhankelijkheid, inclusief AI-gebaseerde scanners. Malware wordt inmiddels geschreven om die scanners te misleiden.
• Het roteren van credentials en andere secrets werkt alleen als je dat volledig doet. Onvolledige rotatie geeft schijnzekerheid.
• Snel updaten is goed, maar doe dat niet blind. Wie elke nieuwe versie direct binnenhaalt, loopt het hoogste risico op een besmette release; wie updates maandenlang uitstelt, op aanwezigheid van kwetsbaarheden.

Het is wachten op het volgende incident

De incidenten gaan door: begin juni werden ruim dertig pakketten onder een Red Hat-namespace gecompromitteerd en medio juli de releasepijplijnen van vier AsyncAPI-repositories. (6) De methoden worden simpeler en sneller. Daarbovenop is van één malwarecampagne zelfs de broncode openbaar gemaakt, waardoor die technieken nu ook voor andere kwaadwillenden beschikbaar zijn.

Elke organisatie kan slachtoffer worden, van klein ontwikkelteam tot organisatie met een volwassen ontwikkelproces. Neem daarom nu maatregelen om dit soort incidenten te voorkomen en waar mogelijk te mitigeren.

Handelingsperspectief

De onderstaande handelingsperspectieven zijn gebaseerd op de verstrekte informatie en bieden een gestructureerde aanpak voor het beveiligen van softwaresupplychains en CI/CD-omgevingen. Geen enkele maatregel hieronder dekt alle beschreven aanvallen. Samen verkleinen ze de kans dat een besmette release je omgeving bereikt en beperken ze wat een aanvaller kan doen als dat toch gebeurt.

Preventief

• Voeg nooit blindelings nieuwe afhankelijkheden aan je project toe. Controleer voor elke package wie de maintainer is, hoe actief het project wordt onderhouden, hoe vaak de externe library is gedownload, hoelang het pakket al bestaat, en of de broncode daadwerkelijk overeenkomt met wat op bijvoorbeeld npm is gepubliceerd. Wees extra alert op typosquatting (pakketten met namen die sterk lijken op bekende libraries) en op pakketten die pas recent zijn gepubliceerd. Beoordeel ook of de functionaliteit die je nodig hebt het toevoegen van de externe afhankelijkheid daadwerkelijk rechtvaardigt. Met elke afhankelijk vergroot je immers je aanvalsoppervlak.
• Weeg bij elke update bewust af of je de nieuwe functionaliteit daadwerkelijk nodig hebt. Elke versie die je binnenhaalt, is een nieuw moment waarop een gecompromitteerde release je omgeving kan binnenkomen. Door niet automatisch naar de nieuwste versie te springen, maar te kiezen welke updates echt waarde toevoegen, verklein je je blootstelling. Reserveer snelle updates voor beveiligingsupdates en behandel reguliere feature-updates terughoudender.
• Hanteer een cooldown-periode voor dependency-updates. Installeer nieuwe versies van pakketten niet direct, maar dwing een minimale "leeftijd" af voordat een release wordt binnengehaald. De instelling "minimumReleaseAge" en de dependency cooldown-periode zijn hetzelfde principe: wat in sommige tools "minimumReleaseAge" heet, wordt in andere ecosystemen en package managers een "dependency cooldown" genoemd. Het achterliggende idee: de overgrote meerderheid van gecompromitteerde releases wordt binnen enkele uren opgemerkt en verwijderd, dus de simpelste mitigatie is om nieuwe versies niet meteen te installeren. Dit principe wordt inmiddels breed ondersteund door package managers (o.a. npm, en Yarn) en door update-tooling zoals Renovate en Dependabot.  Er bestaat geen formele standaard, maar omdat gecompromitteerde releases vrijwel altijd binnen zeven dagen worden ontdekt en verwijderd, geldt een cooldown van circa een week als effectieve richtlijn (7).
• Gebruik versiepinning wanneer jouw software externe libraries gebruikt. Pin waar mogelijk hashes van externe libraries in plaats van versienummers. Hiermee verklein je de kans dat je een gecompromitteerde versie van de externe library downloadt.
• Genereer en bewaar Software Bill of Materials (SBOM). Een SBOM beschrijft uit welke onderdelen en afhankelijkheden je applicatie bestaat. Een SBOM per build ondersteunt je incidentresponse-proces tijdens een incident. Je bent dan sneller in staat om vast te stellen of je applicatie een malafide afhankelijkheid gebruikt.
• Behandel elke wijziging in GitHub Actions-workflows als een hoog risico. Vereis altijd expliciete goedkeuring van een aangewezen security-reviewer voordat wijzigingen worden doorgevoerd. (8)
• Pas het principe van least privilege toe op accounts, sleutels en tokens. Geef elk account, elke key en elk token alleen de rechten en de scope die strikt noodzakelijk zijn voor de specifieke taak. Een token dat alleen hoeft te lezen, krijgt bijvoorbeeld geen schrijfrechten. Beperk daarnaast de impact van een eventuele compromittatie door tokens en secrets regelmatig te roteren en hun geldigheidsduur kort te houden. Richt processen in om tokens snel in te kunnen trekken wanneer dat nodig blijkt, bijvoorbeeld als uitkomst van je incidentresponse-proces. Hoe minder een buitgemaakt token kan, hoe kleiner de schade.
• Gebruik scansoftware voor CI/CD-omgevingen om malafide updates en packages te detecteren. Gebruik je AI-gebaseerde scanning? Zorg dan dat de te scannen pakketinhoud nooit de instructies van de scanner zelf kan overschrijven en behandel paketten die niet goed geanalyseerd konden worden niet automatisch als "veilig".
• Zet vulnerability- en supplychain-scanning breed in, niet alleen "npm audit". Dat commando signaleert bekende kwetsbaarheden in npm-pakketten, maar dekt slechts een deel van je keten. Gebruik aanvullend gespecialiseerde tooling die je afhankelijkheden over meerdere ecosystemen (zoals npm, PyPI, container-images, GitHub Actions) controleert op zowel bekende kwetsbaarheden als verdacht of malafide gedrag en die nieuwe releases beoordeelt vóórdat ze worden geïnstalleerd. Zie geautomatiseerde scanning als aanvulling op handmatige controle, versiepinning en een cooldown-periode, niet als vervanging daarvan.
• Schakel preinstall- en postinstall-scripts uit, bijvoorbeeld door de parameter '--ignore-scripts' van het 'npm ci'-commando te gebruiken. Dit soort scripts worden veelvuldig gebruikt bij het plaatsen en uitvoeren van malware.
• Beperk inkomend en uitgaand netwerkverkeer. Maak hierbij gebruik van een allowlist van vertrouwde (al dan niet interne) systemen en domeinen. Zo maak je het lastiger voor kwaadwillenden om na compromittatie data te exfiltreren of commando's naar de geplaatste malware te sturen.
• Laat pakketten binnenkomen via één gecontroleerd punt. Een interne registry of proxy geeft je één plek om te blokkeren, te quarantainen en achteraf vast te stellen wat er is binnengehaald. 
• Maak als maintainer gebruik van een "trusted publisher"-model voor het publiceren van npm-pakketten. Zo verloopt het publiceren via een vertrouwde, geautomatiseerde route in plaats van met vaste inloggegevens die door aanvallers gestolen kunnen worden.
• Schakel phishing-bestendige multifactorauthenticatie in (zoals FIDO2/WebAuthn of een hardwaresleutel) op accounts van maintainers en op platforms als npm, PyPI, GitHub en je cloudomgevingen. Bij verschillende campagnes onderschepten aanvallers via phishing live MFA-codes. 
• Stel eisen aan AI-gebaseerde scanning. Zorg dat de inhoud van een te scannen pakket nooit de instructies van de scanner zelf kan overschrijven, en dat pakketten die niet goed geanalyseerd konden worden niet automatisch als veilig worden bestempeld. Gebruik je een externe dienst, stel deze vragen dan aan je leverancier: hoe wordt pakketinhoud behandeld als bewijsmateriaal in plaats van als instructie, en wat gebeurt er bij een onbesliste analyse?

Monitoring

• Controleer op onverwachte pakketreleases. Let op onverklaarbare versieverhogingen en op wijzigingen in de accounts die gemachtigd zijn om te publiceren.
• Signaleer nieuw aangemaakte publieke repositories onder je organisatie- en medewerkersaccounts. 
• Signaleer registratie van onbekende self-hosted runners. Dat is een bekend persistentiemechanisme.
• Analyseer het gebruik van authenticatietokens binnen CI/CD-pijplijnen en stel alerts in op afwijkend gedrag in automatisering en op toegang tot secrets.
• Log wat je pipeline daadwerkelijk heeft geïnstalleerd en met welke bestemmingen hij verbinding maakte, niet alleen wat je manifest voorschrijft.
• Houd toezicht op het aanmaken van repositories en op afwijkende workflow-uitvoeringen. Onverwachte uitvoeringen en automatische uploads kunnen wijzen op data-exfiltratie.
• Zorg dat security advisories de juiste teams binnen enkele uren bereiken. De blootstellingsvensters in de incidenten hierboven liepen van achttien minuten tot enkele uren. Een wekelijkse securitynieuwsbrief bijvoorbeeld is dan te traag.

Respons

Onderneem direct de volgende stappen wanneer sprake is van een vermoedelijke of bevestigde inbreuk:

• Start je incidentrespons-proces op. Schakel eventueel een gespecialiseerde IR-dienstverlener in om de omvang en impact van de compromittatie vast te stellen. Stem de onderstaande acties met hen af.
• Scan alle systemen en endpoints op de aanwezigheid van de getroffen pakketten en verwijder gecompromitteerde versies onmiddellijk. Bewaar eerst bewijsmateriaal, en bouw je omgeving daarna opnieuw op in plaats van slechts op te schonen.
• Roteer credentials en andere secrets volledig. Inventariseer eerst alle plekken waar een blootgestelde credential kan liggen, roteer daarna, en controleer vervolgens of er niets is overgeslagen. Onvolledige rotatie was in maart 2026 de reden dat het incident zich kon voortzetten. Roteer niet alleen wat in omgevingsvariabelen staat, maar alles wat een proces kan opvragen, inclusief secrets uit een vault.
• Zoek naar persistentie voordat je je onderzoek afsluit. Denk aan nieuwe deploykeys, nieuwe tokens, gewijzigde workflows, onbekende self-hosted runners en toegevoegde configuratiebestanden.
• Controleer of je in de periode van compromittatie zelf iets hebt gepubliceerd. Als dat zo is, ben je van slachtoffer een schakel geworden en verandert de volgende stap van hoffelijkheid in noodzaak.
• Informeer je klanten zodat ook zij gepaste maatregelen kunnen treffen. Ook zonder directe impact is informeren vaak verstandig: je voorkomt onrust en laat zien dat je op incidenten bent voorbereid.

Bronnen 

(1) https://www.ncsc.gov.uk/blogs/software-supply-chain-attacks-check-your-dependencies

(2) https://www.zscaler.com/blogs/security-research/shai-hulud-v2-poses-risk-npm-supply-chain

(3) https://phoenix.security/teampcp-supply-chain-attack-trivy-checkmarx-github-actions-npm-canisterworm/

(4) https://socket.dev/supply-chain-attacks/mini-shai-hulud

(5) https://www.stepsecurity.io/blog/the-hades-campaign-pypi-packages

(6) https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

(7) https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns

(8) https://www.wiz.io/blog/github-actions-security-guide

Begin hier

Kom je uit op een lange lijst en weinig tijd? Deze drie maatregelen hebben de beste verhouding tussen inspanning en effect, en zijn alle drie binnen een dag in te voeren.

1. Stel een cooldown-periode in voor dependency-updates.
2. Pin GitHub Actions op een volledige commit-SHA in plaats van op een tag.

Schakel installatiescripts standaard uit en werk met een expliciete uitzonderingslijst.