npm supply chain aanvallen: hoe de Miasma-campagne CI/CD-pipelines en Azure-referenties infiltreert

Aanvallers richten zich niet meer op kwetsbaarheden in uw eigen code, maar op de pakketten waarvan u afhankelijk bent. De Miasma-campagne compromitteerde in juni 2026 tientallen npm-pakketten met een zelfverspreidende worm die GitHub-tokens, Azure-referenties en CI/CD-secrets steelt. Hoe werkt dit, en wat doet u eraan?

Op 5 augustus 2026 presenteert Microsoft op Black Hat USA in Las Vegas het meest gedetailleerde beeld tot nu toe van een aanvalscategorie die IT-teams steeds vaker treft: supply chain aanvallen via npm. Aanvallers dringen niet meer rechtstreeks uw systemen binnen. Ze gaan een stap eerder zitten: in de softwarepakketten en ontwikkeltools waarop uw developers dagelijks vertrouwen.

De Miasma-campagne van begin juni 2026 is het bekendste recente voorbeeld. In één nacht werden 32 npm-pakketten van de @redhat-cloud-services-organisatie gecompromitteerd. Elke developer die daarna één van die pakketten installeerde, had ongemerkt een credential-stelende worm in zijn build-omgeving. Wat die campagne bijzonder maakt, is dat de aanvallers niet stoppen bij één slachtoffer. Het malwaregeval heeft een eigen voortplantingsmechanisme: het verspreidt zich zelf verder via gestolen rechten.

Hoe een npm supply chain aanval werkt

De aanvalsvector is technisch elegant maar moeilijk te stoppen. npm, de pakketbeheerder voor JavaScript en Node.js, ondersteunt zogenoemde lifecycle scripts: kleine shellcommando's die automatisch worden uitgevoerd op bepaalde momenten, zoals wanneer een pakket wordt geïnstalleerd. Een preinstall-script wordt zelfs uitgevoerd vóórdat het eigenlijke pakket beschikbaar is.

Bij de Miasma-campagne bevatte het preinstall-script een zwaar geobfusceerde payload van 4,2 megabyte. Zodra een developer of een CI/CD-systeem het gecompromitteerde pakket installeerde, startte de payload automatisch. Het script doorzocht de omgeving systematisch op waardevolle bestanden: GitHub-tokens, npm-authenticatietokens, inloggegevens voor Azure, AWS en Google Cloud, Kubernetes-configuratiebestanden, Docker-credentials en lokaal opgeslagen SSH-sleutels.

Alle gevonden referenties werden exfiltreerd naar infrastructuur van de aanvallers. Daarna begon het worm-gedrag: de payload gebruikte de gestolen npm-tokens om zich opnieuw te publiceren in andere pakketten die het gecompromitteerde account kon wijzigen. Zo bereikte de infectie in korte tijd tientallen extra pakketten, zonder dat de eigenlijke pakketbeheerders dat merkten.

Waarom CI/CD-pipelines het hoofddoelwit zijn

Build-omgevingen en CI/CD-pipelines zijn aantrekkelijker dan een individuele ontwikkelaarslaptop. De reden is eenvoudig: in een CI/CD-systeem liggen alle referenties gecentraliseerd. Een pipeline die applicaties bouwt en naar Azure deployt, heeft toegang tot service-principals, deployment-tokens, databasewachtwoorden en productiesleutels. Wie die pipeline compro­mitteert, heeft in één klap toegang tot veel meer dan de code zelf.

Bovendien werken build-agents doorgaans met brede rechten en in een vertrouwde netwerksegment. Beveiligingstools die op productieservers nauwlettend monitoren, kijken zelden even kritisch naar wat er in een build-pipeline gebeurt. Die asymmetrie maakt de build-omgeving tot de achteringang die aanvallers tegenwoordig bewust zoeken.

Een veelgemaakte veronderstelling is dat een organisatie die zelf geen kwaadaardig pakket installeert, veilig is. Die veronderstelling klopt niet. Moderne applicaties hebben soms honderden transitive dependencies: pakketten die niet direct in uw package.json staan, maar wel indirect worden meegeladen omdat een ander pakket ze nodig heeft. De aanvaller hoeft slechts één populair pakket te compro­mitteren. Via de transitieve afhankelijkheidsketen bereikt de payload vervolgens developers en CI/CD-systemen van organisaties die het geïnfecteerde pakket nooit zelf hebben gekozen.

AI agents als nieuw aanvalsoppervlak

Een thema dat Microsoft op Black Hat 2026 nadrukkelijk bespreekt, is het groeiende risico voor organisaties die AI-agents inzetten in hun ontwikkelprocessen. Agents die code genereren, repositories doorbladeren of autonome npm-installaties uitvoeren, opereren met brede privileges in een vertrouwde omgeving. Als zo'n agent via een geïnfecteerd pakket wordt geraakt, kan de impact groter zijn dan bij een menselijke developer: de agent heeft mogelijk directe toegang tot cloud-APIs, databases of interne diensten zonder de extra handmatige controles die een mens nog zou toepassen.

Dit is geen hypothetisch risico. De aanvallers achter Miasma gebruikten gestolen tokens om geautomatiseerd nieuwe kwaadaardige versies van pakketten te publiceren. Een AI-agent met schrijfrechten op een npm-organisatie is een directe amplifier voor dat soort aanvallen.

Hoe u uw omgeving beschermt

Vijf maatregelen die elke IT- of DevOps-afdeling op korte termijn kan implementeren. Ten eerste: schakel over van long-lived tokens naar OIDC-gebaseerde authenticatie in CI/CD-pipelines. Bij OIDC-tokens voor trusted publishing ontvangt elke build-run een tijdelijk token met een korte levensduur. Wordt zo'n token gestolen, dan is het vrijwel direct verlopen en biedt het de aanvaller geen blijvende toegang.

Ten tweede: stel npm in om lifecycle scripts standaard niet te draaien in uw CI/CD-systeem. Dit doet u door de flag --ignore-scripts toe te voegen aan npm install-commando's in uw pipeline. Hierdoor worden preinstall- en postinstall-scripts niet meer automatisch uitgevoerd. Voor de meeste applicaties verandert dit niets aan de werking; de risk-surface neemt drastisch af.

Ten derde: pin uw pakketversies expliciet in package.json en gebruik een lockfile die bij elke build wordt gevalideerd. Aanvallers publiceren gecompromitteerde versies als een nieuw versienummer. Wie patchversies automatisch laat updaten, haalt ongemerkt de geïnfecteerde versie binnen. Handmatige versie-upgrades met een code-review vergen meer discipline maar sluiten dit risico voor een groot deel af.

Ten vierde: gebruik een private package registry als proxy. Tools zoals Azure Artifacts of JFrog Artifactory staan tussen uw CI/CD-systeem en het publieke npm-register. U kunt pakketten op die manier eerst vetten voordat ze de build-omgeving bereiken, en u behoudt controle over welke versies worden toegestaan. Dit is met name waardevol voor productieomgevingen.

Ten vijfde: voer periodieke audits uit op de rechten die aan CI/CD-systemen en service-accounts zijn verleend. Hoe minder rechten een build-agent heeft, hoe beperkter de schade als dat systeem wordt gecompromitteerd. Verwijder rechten voor productie-deployments uit build-agents die ook voor tests worden gebruikt. Scheid test-pipelines van deploymentpipelines.

Wat de bredere trend aangeeft

De Miasma-campagne en de typosquatting-golf die er vlak voor plaatsvond, passen in een duidelijker patroon. Aanvallers optimaliseren hun inspanning: één succesvol gecompromitteerd pakket met tienduizenden downloads levert meer slachtoffers op dan honderden individuele phishing-pogingen. De term die Microsoft op Black Hat gebruikt, is veelzeggend: aanvallers richten zich niet meer op CVEs maar op vertrouwenspaden. Ze misbruiken het vertrouwen dat developers en systemen hebben in gevestigde pakketten van bekende organisaties.

Dat maakt software supply chain beveiliging tot een IT-verantwoordelijkheid die verder reikt dan de developers zelf. Het gaat om het beheer van geheimen en referenties, om de privileges die aan geautomatiseerde systemen worden verleend, en om de monitoring van wat er in build-omgevingen gebeurt. Microsoft Defender for Cloud biedt ondersteuning voor het detecteren van verdachte activiteit in CI/CD-omgevingen, inclusief signals op onverwachte netwerkverbindingen vanuit build-agents en anomalieën in publicatiegedrag op pakketregisters. Wilt u weten hoe u uw ontwikkelomgeving en Azure-tenant beter beveiligt tegen supply chain risico's? Neem contact op met Zarioh voor een gesprek over uw concrete situatie.