Slopsquatting

Wat is Slopsquatting?

Slopsquatting is een supply-chain-aanval waarbij iemand packages registreert onder namen die AI-codingtools hallucineren, zodat developers die de verzonnen afhankelijkheid van een model installeren, de code van de aanvaller binnenhalen in plaats van een fout. Het werkt omdat modellen herhaaldelijk dezelfde aannemelijke packagenamen hallucineren, wat die namen voorspelbaar en de moeite waard maakt om te kraken.

De belangrijkste punten

• De aanvalsketen is simpel: een model verzint een packagenaam, een aanvaller heeft die naam al geregistreerd op npm of PyPI met kwaadaardige code, en een developer of agent draait het installatiecommando zonder te controleren.
• Het buit een herhaalbaar patroon uit, want modellen neigen over sessies heen dezelfde aannemelijk klinkende namen te hallucineren, wat aanvallers laat toe kandidaatnamen te oogsten door modellen op schaal te prompten.
• Agentic workflows verhogen de inzet. Een AI-coding-agent die zijn eigen afhankelijkheden installeert, kan de hele aanvalsketen voltooien zonder dat een mens de packagenaam leest.
• Mitigaties zijn gewone supply-chain-discipline toegepast op een nieuwe trigger: verifieer dat een package bestaat en legitiem is voor het installeren, gebruik lockfiles en private registries, en poort agent-geïnitieerde installaties achter goedkeuring of een allowlist.

Hoe het werkt

Taalmodellen genereren code door aannemelijke tokens te voorspellen, en importstatements zijn geen uitzondering. Wanneer een model functionaliteit nodig heeft die het niet precies onthoudt, kan het een afhankelijkheid afgeven die er goed uitziet, de naamgevingsconventies van het ecosysteem volgt, en niet bestaat. Beveiligingsonderzoekers die dit maten over 576.000 gegenereerde codevoorbeelden van 16 LLM's vonden dat gemiddeld 5,2% van de packages aanbevolen door commerciële modellen, en 21,7% door open-sourcemodellen, niet bestond [1]. Cruciaal: de fabricaties waren geen willekeurige ruis: in dezelfde studie herhaalde 43% van de gehallucineerde packagenamen in alle 10 herhalingen van de identieke prompt, en kwam 58% meer dan één keer terug over 10 iteraties [2].

Die voorspelbaarheid is de hele aanval. Een tegenstander promt populaire modellen met gangbare codingtaken, verzamelt de packagenamen die terugkomen, filtert op ongeregistreerde, en publiceert kwaadaardige packages onder die namen. De payload draait typisch bij installatie of eerste import: credentialdiefstal, exfiltratie van omgevingsvariabelen, of een backdoor. Vanaf daar rijdt de aanval mee op normaal developergedrag. Iemand accepteert een AI-suggestie, draait pip install of npm install, en de registry bedient bereidwillig de code van de kraker. De naam is geen typfout van iets, wat slopsquatting onderscheidt van klassiek typosquatting; de naam was nooit echt.

Verdedigingen stapelen. Individuele developers verifiëren onbekende packages voor installatie: controleer de registrypagina, de repositorylink, de downloadgeschiedenis, en de publicatiedatum, want een package gemaakt vorige week zonder repository is een rode vlag. Teams handhaven lockfiles, dependency-review op pull requests, private registries of proxies met allowlists, en scanners die nieuw gepubliceerde of laag-reputatie-packages signaleren. Voor agents is de guardrail structureel: de agent stelt afhankelijkheden voor maar een mens of een beleidscheck keurt ze goed, en de sandbox waarin de agent bouwt heeft geen credentials de moeite waard om te stelen.

Voorbeeld

Een developer vraagt een coding-agent retry-logica toe te voegen aan een Python-service die een flaky API aanroept. De agent schrijft schone code die een helperlibrary importeert met een perfect idiomatische naam die de taak en het framework mengt, voegt het dan toe aan requirements.txt en draait de installatie als deel van zijn lus. Het package bestaat op PyPI, drie weken eerder gepubliceerd, omdat een aanvaller het had geoogst uit modeloutputs. Zijn setup-script exfiltreert de CI-omgevingsvariabelen bij installatie. Het team vangt het in staging wanneer hun dependency-firewall een package signaleert jonger dan hun minimumleeftijdbeleid. De post-incident-wijziging: agent-geïnitieerde installaties resolven nu alleen via de interne registryproxy van het bedrijf, die goedgekeurde packages spiegelt en al het andere afwijst.

Veelvoorkomende misvattingen

De misvatting is dat slopsquatting gewoon typosquatting is met een trendy naam, al gedekt door bestaande tooling. Typosquatting verdedigt tegen menselijke vingers: tools vergelijken namen met populaire packages en vangen afwijkingen van één teken. Slopsquatted namen liggen nergens dichtbij. Het zijn nieuwe, aannemelijke, conventievolgende namen die geen enkele gelijkenischeck zal signaleren, en de installer is steeds vaker een agent in plaats van een persoon die zou kunnen aarzelen. De verdediging moet verschuiven van "lijkt deze naam op een typfout" naar "heeft dit package een verifieerbare geschiedenis."

Package-hallucinatie

Package-hallucinatie is de modelzijdige helft van het probleem: een AI-systeem dat zelfverzekerd verwijst naar een library, module, of API die niet bestaat. Het is een specifiek geval van AI-hallucinatie, en het gebeurt het meest bij niche-taken, nieuwere ecosystemen, en aannemelijk klinkende combinaties van echte projectnamen. Op zichzelf is een gehallucineerd package een buildfout en een paar verspilde minuten. Het wordt een beveiligingsprobleem op het moment dat iemand de naam registreert, wat precies is wat slopsquatting doet. De poel namen is niet klein: de USENIX Security 2025-metingsstudie registreerde 440.445 package-hallucinaties in totaal, inclusief 205.474 unieke niet-bestaande namen die een aanvaller kon registreren [3]. Het percentage varieert per model en ecosysteem, maar geen huidig model is immuun, en agents die installatiecommando's genereren en uitvoeren in één lus, zetten elke hallucinatie om in een geprobeerde download. Verlagen helpt: retrieval tegen een echte packageindex, verificatiestappen in de agentlus, en prompts die het model vereisen elke nieuwe afhankelijkheid te rechtvaardigen, verlagen allemaal het percentage. Eliminatie staat niet op tafel met huidige architecturen, dus dragen de registryzijdige en pipelinezijdige verdedigingen het echte gewicht.

FAQ

Waar komt de naam slopsquatting vandaan? Het mengt AI slop, de denigrerende term voor onzorgvuldige machinaal gegenereerde output, met typosquatting, de oudere aanval van bijna-identieke domein- en packagenamen registreren. De term verspreidde zich door de beveiligingsgemeenschap in 2025 nadat onderzoek kwantificeerde hoe vaak codingmodellen afhankelijkheden fabriceren.

Welke ecosystemen zijn het meest blootgesteld? Elke registry met open, instant publiceren: npm en PyPI zijn de primaire doelen omdat publiceren wrijvingsloos is en installatiescripts code draaien. Ecosystemen met gecureerde of namespaced registries zijn moeilijker aan te vallen, en interne mirrors met allowlists sluiten de deur bijna volledig.

Hoe controleer ik of een door AI voorgesteld package echt en veilig is? Zoek het direct op in de registry, niet via zoeken. Controleer dan leeftijd, downloadaantallen, een gelinkte bronrepository die daadwerkelijk de code bevat, en een maintainer met geschiedenis. Als AI-codegeneratie het voorstelde en het faalt een van die checks, behandel het als vijandig tot het tegendeel bewezen is.

Bronnen

1. arXiv / USENIX Security 2025 (Spracklen et al.). "5,2% van de commerciële-model- en 21,7% van de open-source-model-packageaanbevelingen bestond niet, over 576.000 codevoorbeelden van 16 LLM's." https://arxiv.org/abs/2406.10279. Geraadpleegd augustus 2026.
2. arXiv / USENIX Security 2025 (Spracklen et al.). "43% van gehallucineerde packagenamen herhaalde in alle 10 herhalingen van dezelfde prompt; 58% kwam meer dan één keer terug." https://arxiv.org/html/2406.10279v3. Geraadpleegd augustus 2026.
3. arXiv / USENIX Security 2025 (Spracklen et al.). "440.445 totale package-hallucinaties, inclusief 205.474 unieke niet-bestaande packagenamen." https://arxiv.org/abs/2406.10279. Geraadpleegd augustus 2026.