Het probleem in één zin
Volgende keer een De AI-assistent beveelt een te installeren pakket aan.Ga je daadwerkelijk controleren of dat pakket bestaat? De meeste ontwikkelaars doen dat niet. Die kloof tussen suggestie en verificatie is precies waar slopsquatting-aanvallen beginnen, en daarom is het begrijpen van zowel de evolutie van slopsquatting als praktische preventie ervan een echte prioriteit geworden voor AppSec- en DevSecOps-teams.
Wat is een slopsquatting-aanval?
Een slopsquatting-aanval is een variant van typosquatting (de praktijk van het registreren van een domein- of pakketnaam die een legitieme naam nabootst door middel van een veelvoorkomende spelfout, zoals verzoeken in plaats van verzoeken(in de hoop dat een typefout van de gebruiker hen er direct naartoe leidt), maar met een belangrijk verschil in waar de fout ontstaat. Typosquatting maakt gebruik van menselijke typefouten. Een slopsquatting-aanval maakt gebruik van de fouten die grote taalmodellen maken: een LLM "hallucineert" een pakketnaam die volkomen legitiem klinkt, maar niet bestaat in een openbaar register, en een aanvaller is hem voor door precies die naam te registreren voordat iemand met goede bedoelingen dat doet.
Het mechanisme achter een typische slopsquatting-aanval is eenvoudig, en juist die eenvoud maakt hem effectief:
- Een ontwikkelaar vraagt een AI-assistent om te helpen bij het oplossen van een programmeerprobleem.
- Het model genereert een oplossing die een pakket importeert of aanbeveelt te installeren dat nooit heeft bestaan.
- Een aanvaller die opmerkt dat verschillende modellen steeds dezelfde verzonnen naam herhalen, registreert dat pakket op npm, PyPI of een andere openbare registry, met kwaadaardige code erin. Dit is het moment waarop de hallucinatie overgaat in een daadwerkelijke slopsquatting-aanval.
- De volgende ontwikkelaar die dezelfde suggestie krijgt en deze niet controleert, installeert het nu daadwerkelijke pakket, wat een achterdeur vormt naar hun omgeving.
De term "slopsquatting" werd bedacht door Seth Larson, Security Developer-in-Residence bij de Python Software Foundation, en gepopulariseerd door Andrew Nesbitt, om precies dit patroon te beschrijven: een "pakketillusie" die verandert in een aanvalsvector.
De evolutie van slopsquatting: hoe een onderzoeksvraagstuk uitgroeide tot een echte bedreiging.
Wat opmerkelijk is aan de evolutie van slopsquatting, is niet alleen het concept zelf, maar ook hoe snel het zich ontwikkelde van een observatie uit onderzoek tot een gedocumenteerde, meetbare vorm van geweld.
2023: Het eerste waarschuwingssignaal. Beveiligingsonderzoeker Bar Lanyado Ik merkte op dat verschillende LLM-studenten herhaaldelijk een pakket aanbevolen genaamd knuffelgezicht-cli, wat niet bestaat (het echte pakket wordt geïnstalleerd met pip install -U “huggingface_hub[cli]”Om het risico aan te tonen, uploadde hij een lege versie van dat pakket naar een openbaar register. Binnen drie maanden was het meer dan 30,000 keer gedownload, zonder enige promotie. De verzonnen naam dook zelfs op in de README van een repository die gekoppeld was aan onderzoek van Alibaba, wat al vroeg aantoonde hoe deze "nepnamen" in echte documentatie konden terechtkomen en de weg vrijmaakten voor de slopsquatting-aanvallen die zouden volgen.
2024: Het risico verschuift van een blogpost van een onderzoeker naar de reguliere berichtgeving over technologie. In maart 2024, Het register Er werd bericht over hoe AI-modellen vol zelfvertrouwen namen voor softwarepakketten bedachten die ontwikkelaars vervolgens downloadden, waarvan sommige mogelijk besmet waren met malware. Die berichtgeving was minder belangrijk vanwege wat het technisch onthulde, maar meer vanwege wat het aankondigde: de huggingface-cli-zaak was niet langer een incidenteel geval; het was het eerste teken van een patroon dat ernstig genoeg was om door de reguliere techpers te worden aangekaart, nog voordat een jaar later een grootschalig academisch onderzoek zou volgen dat de omvang ervan zou bevestigen.
2025: De eerste grondige, grootschalige meting van het probleem. Het papier “Wij hebben een pakket voor u! Een uitgebreide analyse van pakketgerelateerde hallucinaties door codegenererende LLM’s” (Spracklen et al., gepresenteerd op de USENIX-beveiliging Het onderzoeksteam van Symposium testte 16 code-generatiemodellen, zowel commerciële (GPT-4, GPT-3.5) als open-source (CodeLlama, DeepSeek, WizardCoder, Mistral), aan de hand van 576,000 Python- en JavaScript-codevoorbeelden. De bevindingen markeren een duidelijk keerpunt in de evolutie van slopsquatting, waarbij het van anekdote naar data verschuift:
- 19.7% De door de modellen aanbevolen pakketten bestonden niet.
- Open-source modellen vertoonden veel vaker hallucinaties (21.7% gemiddeld) dan commerciële modellen (5.2%).
- De ergste overtreders, CodeLlama 7B en CodeLlama 34B, vertoonden hallucinaties in meer dan een derde van hun output.
- Bij alle geteste modellen registreerden de onderzoekers meer dan 205,000 unieke, verzonnen pakketnameneen reservoir dat groot genoeg is om aanhoudende slopsquatting-aanvallen in meerdere ecosystemen te voeden.
- Een detail dat met name relevant is voor preventie: ongeveer 38% De namen van de verzonnen pakketten leken sterk op echte pakketten, waardoor de kans kleiner was dat iemand ze in één oogopslag zou opmerken.
Een cruciaal detail uit het onderzoek, en waarschijnlijk de reden waarom de evolutie van slopsquatting is versneld in plaats van afgezwakt, is dat de verzonnen namen niet willekeurig zijn en niet bij elke poging veranderen. Dezelfde modellen herhalen vaak dezelfde verzonnen namen wanneer ze vergelijkbare prompts krijgen, wat betekent dat een aanvaller niet hoeft te raden. Ze hoeven alleen maar het gedrag van de modellen te observeren, de namen te identificeren die steeds terugkomen en deze te registreren voordat een echte ontwikkelaar dat doet. Vervolgonderzoek naar deze herhaalbaarheid wees uit dat toen onderzoekers identieke prompts tien keer herhaalden, 43% van de verzonnen pakketnamen bij elke run verscheen en 58% meer dan eens terugkeerde. Dit bewijst dat de meeste hallucinaties herhaalbare artefacten zijn in plaats van eenmalige ruis. Die herhaalbaarheid maakt van een eenmalige hallucinatie een schaalbare slopsquatting-aanval.
2026: Van geïsoleerde pakketten naar autonome agenten. Dit jaar is het duidelijkste bewijs tot nu toe geleverd dat slopsquatting niet langer beperkt is tot een ontwikkelaar die een voorgesteld ontwerp kopieert en plakt. pip installeren or npm installeren commando. In januari 2026, onderzoeker Charlie Eriksen Bij Aikido Security werd ontdekt dat AI-programmeurs al instructies hadden verspreid die verwezen naar een verzonnen npm-pakket. react-codeshift (een naam die op plausibele wijze twee echte gereedschappen combineert, jscodeverschuiving en react-codemod), verspreid over 237 repositories, waarbij agents nog steeds dagelijks proberen het te installeren. Eriksen registreerde de naam zelf, uit voorzorg, voordat een aanvaller er misbruik van kon maken. Daarnaast is er een echt kwaadaardig pakket met de naam ongebruikte importen, gehallucineerd in plaats van het legitieme eslint-plugin-unused-importsDe app registreerde begin 2026 nog steeds ongeveer 233 wekelijkse downloads, ondanks dat npm de app onder een beveiligingsblokkade had geplaatst. Dit is een teken van hoe lang een slopsquatting-aanval slachtoffers kan blijven maken, zelfs nadat deze is gemarkeerd. Meer recent, in juli 2026, beschreven onderzoekers een verwante techniek, genaamd "HalluSquatting", die een AI-hallucinatie combineert met een promptinjectie, waardoor een AI-codeagent die namens een gebruiker een gehallucineerde bron ophaalt, kan worden gekaapt om door de aanvaller aangeleverde code uit te voeren. Dit breidt de evolutie van slopsquatting uit van een passief installatierisico naar een actieve vector voor het uitvoeren van code op afstand binnen agentische ontwikkelworkflows.
Waarom "vibe coding" de weg vrijmaakte voor slopsquatting-aanvallen
Slopsquatting-aanvallen zouden weinig uitmaken als door AI gegenereerde code een nichepraktijk was. Dat is het echter niet. De opkomst van codeerassistenten, autonome agenten en 'vibe coding'-workflows, waarbij ontwikkelaars steeds minder code controleren voordat ze deze uitvoeren, heeft het aanvalsoppervlak van software op twee concrete manieren veranderd, en beide versnellen de evolutie van slopsquatting:
- Het toegangspunt is niet langer alleen de ontwikkelaar. Een typosquatting-aanval was vroeger afhankelijk van één persoon die een typefout maakte. Nu kan de fout in het model zelf ontstaan en zich verspreiden naar honderden verschillende ontwikkelaars die soortgelijke vragen stellen en dezelfde misleidende aanbeveling krijgen, waardoor het bereik van een enkele slopsquatting-aanval enorm toeneemt.
- Het aanvalsoppervlak is verder omhoog in de keten verschoven. Het is niet langer voldoende om alleen de code te bekijken die een mens schrijft. Teams moeten ook de afhankelijkheden in de gaten houden die een AI-assistent voorstelt, de MCP-servers waarmee deze verbinding maakt en de agents die pakketten autonoom installeren zonder directe menselijke controle. Traditionele AppSec is ontworpen om repositories en menselijke controle te beoordelen. commits was nooit ontworpen om deze nieuwe interactie tussen ontwikkelaar, AI en pakketregister te observeren, precies waar slopsquatting-aanvallen zich nu verschuilen.
Dit alles betekent niet dat generatieve AI inherent onveilig is. Het betekent wel dat het een nieuw soort risico in de toeleveringsketen introduceert waarvoor traditionele beveiligingsinstrumenten niet zijn ontworpen, en dat dezelfde verificatieprincipes vereist die we al toepassen op elke externe afhankelijkheid: vertrouw niet zomaar, controleer de bron en automatiseer die verificatie in plaats van te vertrouwen op het geheugen of de waakzaamheid van elke ontwikkelaar. Die automatisering vormt de basis van elke effectieve strategie ter voorkoming van slordig coderen.
Slopsquatting voorkomen: wat teams vandaag nog kunnen doen.
Het goede nieuws is dat het voorkomen van slopsquatting geen exotische tools vereist. Het vereist het systematisch toepassen van bestaande, maar door veel teams genegeerde, afhankelijkheidshygiëne-praktijken zodra een AI die ze vertrouwen de code "suggereert". Een effectieve aanpak om slopsquatting te voorkomen combineert doorgaans de volgende elementen:
- Controleer elk nieuw pakket handmatig voordat u het installeert.Vooral als het een suggestie van een AI-assistent is. Controleer of het in het officiële register staat, wie het beheert, wanneer het is gepubliceerd en of de downloadcijfers kloppen. Deze ene gewoonte is de goedkoopste manier voor elk team om slopsquatting te voorkomen.
- Ga er nooit vanuit dat door AI gegenereerde code per definitie veilig is. Een codefragment dat "werkt" betekent niet dat de afhankelijkheden ervan legitiem zijn. Het controleren van afhankelijkheden moet onderdeel zijn van de codebeoordeling, en geen uitzondering daarop.
- Gebruik lockfiles en hashverificatie. Om exacte versies vast te leggen en te voorkomen dat een stille update een ander pakket installeert dan het pakket dat oorspronkelijk is gecontroleerd.
- Implementeer afhankelijkheidsscans die risicopatronen signaleren die verder gaan dan de bekende CVE's.: afwijkende pakketten, namen die verdacht veel lijken op bestaande, nieuwe beheerders zonder trackrecord, of installatiescripts met ongebruikelijk gedrag. Een nieuw gepubliceerd pakket met vrijwel geen geschiedenis dat sterk lijkt op de naam van iets dat "bijna" bekend is, is precies het patroon achter de meeste slopsquatting-aanvallen die tot nu toe zijn gedocumenteerd.
- Behandel openbare registers met dezelfde scepsis.cisnet als elke andere niet-geverifieerde externe bron. Dat pip installeren or npm installeren Het feit dat er geen foutmelding wordt gegeven, is geen bewijs van legitimiteit.
- Train ontwikkelingsteams Het gaat erom dat AI-ondersteunde codering de verantwoordelijkheid voor het controleren van wat er geïnstalleerd wordt niet wegneemt; het voegt alleen een stap toe die in de workflow moet worden ingebouwd als onderdeel van elk serieus plan om slordig installeren te voorkomen.
Geen van deze maatregelen is op zichzelf nieuw. Wat wel veranderd is, is de schaal: wanneer een suggestie voor een afhankelijkheid niet langer van Stack Overflow of een collega komt, maar van een model dat dezelfde fout kan herhalen bij duizenden verschillende ontwikkelaars, is handmatige verificatie, hoewel nog steeds nodig, op zichzelf niet meer voldoende. Daarom automatiseren steeds meer teams deze laag van preventie van slopsquatting binnen hun code. Analyse van softwaresamenstelling (SCA) gereedschapin plaats van het over te laten aan de individuele discipline van de ontwikkelaar.
Dit is voorafcisely waarom ASPM platforms als Xygeni Integreer de detectie van verdachte afhankelijkheden, inclusief typosquatting, verwarring tussen afhankelijkheden en bekende kwaadaardige pakketten, in dezelfde open-source en AI-afhankelijkheidsanalyse. pipelineHet voorkomen van slopsquatting is dus niet afhankelijk van het feit dat elke ontwikkelaar eraan denkt om dit te controleren telkens wanneer een AI-assistent een nieuwe afhankelijkheid voorstelt.
FAQ
Is een slopsquatting-aanval hetzelfde als een typosquatting-aanval?
Niet helemaal. Beide aanvallen houden in dat een valse pakketnaam wordt geregistreerd om de installateur te misleiden, maar de oorzaak van de fout verschilt. Typosquatting maakt gebruik van menselijke typefouten. Een slopsquatting-aanval maakt gebruik van pakketnamen die door AI-modellen zijn bedacht (gehallucineerd) en die een aanvaller vervolgens registreert voordat het pakket legitiem bestaat.
Kan een pakketbeheerder dit soort aanvallen automatisch voorkomen?
Niet helemaal, en dat is precies de reden waarom preventie van slopsquatting niet kan stoppen bij het niveau van de pakketbeheerder. Als een aanvaller het gefingeerde pakket registreert voordat een ontwikkelaar het probeert te installeren, zal de installatie zonder fouten worden voltooid omdat het pakket daadwerkelijk bestaat, ook al is het kwaadaardig. Effectieve preventie vereist aanvullende verificatie van de herkomst en het gedrag van het pakket.
Heeft dit alleen gevolgen voor open-source modellen?
Nee. De studie van Spracklen et al. toonde hallucinaties aan bij alle geteste modellen, inclusief commerciële modellen, zij het in een aanzienlijk lager percentage (5.2% versus 21.7% voor de geëvalueerde open-source modellen). Geen enkel model is volledig vrij van het probleem, wat deels verklaart waarom de ontwikkeling van slopsquatting gelijke tred houdt met de groei van AI-ondersteund programmeren in het algemeen.
Is dit een theoretisch risico, of is het al uitgebuit?
De knuffelgezicht-cli Het geval van een leeg pakket dat door een onderzoeker was geüpload en in drie maanden tijd meer dan 30,000 keer werd gedownload zonder enige promotie, laat zien dat het risico niet alleen theoretisch is: een verzonnen naam hoeft slechts consistent genoeg te zijn in verschillende prompts om door iemand te worden gebruikt voor een daadwerkelijke slopsquatting-aanval.
