Problemet i én sætning
Næste gang en AI-assistent anbefaler en pakke at installere... vil du rent faktisk tjekke, om den pakke findes? De fleste udviklere har ikke. Det er præcis dér, slopsquatting-angrebene begynder, og det er derfor, at det er blevet en reel prioritet for AppSec- og DevSecOps-teams at forstå både udviklingen af slopsquatting og den praktiske forebyggelse af slopsquatting.
Hvad er et slopsquatting-angreb?
Et slopsquatting-angreb er en variant af stavefejl (praksissen med at registrere et domæne- eller pakkenavn, der efterligner et legitimt navn gennem en almindelig stavefejl, f.eks. anmodninger i stedet for anmodninger(i håb om at brugerens egen tastefejl fører dem direkte derhen), men med en vigtig forskel i, hvor fejlen stammer fra. Typosquatting udnytter menneskelige tastefejl. Et slopsquatting-angreb udnytter de fejl, store sprogmodeller begår: en LLM "hallucinerer" et pakkenavn, der lyder helt legitimt, men ikke findes i noget offentligt register, og en angriber kommer derhen først ved at registrere præcis det navn, før nogen med gode intentioner gør det.
Mekanismen bag et typisk slopsquatting-angreb er enkel, og det er præcis den enkelhed, der gør det effektivt:
- En udvikler beder en AI-assistent om hjælp til at løse et kodningsproblem.
- Modellen genererer en løsning, der importerer eller anbefaler installation af en pakke, der aldrig har eksisteret.
- En angriber, der har bemærket, at flere modeller gentager det samme hallucinerede navn, registrerer den pakke på npm, PyPI eller et andet offentligt register med skadelig kode indeni. Det er i dette øjeblik, hvor hallucinationen udvikler sig til et egentligt slopsquatting-angreb.
- Den næste udvikler, der får det samme forslag og ikke verificerer det, installerer den nu rigtige pakke, som er en bagdør til deres miljø.
Udtrykket "slopsquatting" blev opfundet af Seth Larson, Security Developer-in-Residence hos Python Software Foundation, og populariseret af Andrew Nesbitt for at beskrive præcis dette mønster: en "pakkehallucination" forvandlet til en angrebsvektor.
Slopsquatting evolution: hvordan en forskningsnysgerrighed voksede til en reel trussel
Det bemærkelsesværdige ved slopsquatting-udviklingen er ikke kun konceptet; det er hvor hurtigt det gik fra en forskningsobservation til en dokumenteret, målbar angrebsklasse.
2023: Det første advarselstegn. Sikkerhedsforsker Bar Lanyado bemærkede, at adskillige LLM'er gentagne gange anbefalede en pakke kaldet huggingface-cli, som ikke findes (den rigtige pakke er installeret med pip install -U “huggingface_hub[cli]”For at demonstrere risikoen uploadede han en tom version af pakken til et offentligt register. Inden for tre måneder havde den modtaget over 30,000 downloads uden nogen form for promovering. Det hallucinerede navn dukkede endda op i README-filen i et arkiv knyttet til forskning fra Alibaba, hvilket tidligt viste, hvordan disse "falske" navne kunne sive ind i rigtig dokumentation og bane vejen for de efterfølgende slopsquatting-angreb.
2024: Risikoen flytter sig fra en forskers blogindlæg til mainstream teknologidækning. I marts 2024, Registret rapporterede om, hvordan AI-modeller selvsikkert opfandt navne på softwarepakker, som udviklere derefter downloadede, hvoraf nogle potentielt var forgiftet med malware. Den dækning betød mindre, hvad den teknisk afslørede, og mere, hvad den signalerede: huggingface-cli-sagen var ikke længere en engangs kuriositet; det var det første tegn på et mønster, der var alvorligt nok til, at mainstream tech-pressen ville påpege det, forud for den storstilede akademiske undersøgelse, der ville bekræfte omfanget et år senere.
2025: Den første grundige måling af problemet i stor skala. Papiret "Vi har en pakke til dig! En omfattende analyse af pakkehallucinationer fra kodegenererende LLM'er" (Spracklen et al., præsenteret på USENIX Sikkerhed Symposium) testede 16 kodegenereringsmodeller, både kommercielle (GPT-4, GPT-3.5) og open source (CodeLlama, DeepSeek, WizardCoder, Mistral), på tværs af 576,000 Python- og JavaScript-kodeeksempler. Resultaterne markerer et klart punkt i udviklingen af slopsquatting, og flytter det fra anekdote til data:
- 19.7% af de pakker, der blev anbefalet af modellerne, eksisterede ikke.
- Open source-modeller hallucinerede langt oftere (21.7% i gennemsnit) end kommercielle modeller (5.2%).
- De værste syndere, CodeLlama 7B og CodeLlama 34B, hallucinerede i mere end en tredjedel af deres output.
- På tværs af alle testede modeller loggede forskerne over 205,000 unikke hallucinerede pakkenavne, en pool, der er stor nok til at give næring til vedvarende slopsquatting-angreb på tværs af flere økosystemer.
- En detalje, der er særlig relevant for forebyggelse: omtrent 38% af hallucinerede navne lignede meget rigtige pakker, hvilket mindsker sandsynligheden for, at nogen får øje på dem med det samme.
En kritisk detalje fra undersøgelsen, og sandsynligvis årsagen til, at udviklingen af slopsquatting er accelereret snarere end forsvundet, er, at hallucinerede navne ikke er tilfældige, og de ændrer sig ikke ved hvert forsøg. De samme modeller har en tendens til at gentage de samme opfundne navne, når de får lignende prompts, hvilket betyder, at en angriber ikke behøver at gætte. De skal bare observere modeladfærd, identificere de navne, der bliver ved med at dukke op, og registrere dem, før en rigtig udvikler gør det. En opfølgende analyse af denne repeterbarhed viste, at når forskere kørte identiske prompts ti gange hver, dukkede 43% af de hallucinerede pakkenavne op ved hver eneste kørsel, og 58% gentog sig mere end én gang, hvilket beviser, at de fleste hallucinationer er gentagelige artefakter snarere end engangsstøj. Denne repeterbarhed er det, der forvandler en engangshallucination til et skalerbart slopsquatting-angreb.
2026: Fra isolerede pakker til autonome agenter. I år har vi frembragt det hidtil klareste bevis på, at slopsquatting ikke længere er begrænset til, at en udvikler kopierer og indsætter et foreslået pip installation or npm installere kommando. I januar 2026, forsker Charlie Eriksen hos Aikido Security fandt man ud af, at AI-kodningsagenter allerede havde spredt instruktioner, der refererede til en hallucineret npm-pakke, react-codeshift (et navn, der plausibelt sammenblander to rigtige værktøjer, jscodeshift og react-codemod), på tværs af 237 arkiver, hvor agenter stadig forsøger at installere det dagligt. Eriksen registrerede navnet selv, defensivt, før en angriber kunne bevæbne det. Separat, en virkelig ondsindet pakke med navnet ubrugte importvarer, hallucineret i stedet for det legitime eslint-plugin-ubrugt-import, registrerede stadig omkring 233 ugentlige downloads i starten af 2026, på trods af at npm satte det under en sikkerhedsholdning, et tegn på, hvor længe et slopsquatting-angreb kan blive ved med at tiltrække ofre, selv efter det er blevet markeret. For nylig, i juli 2026, beskrev forskere en relateret teknik, kaldet "HalluSquatting", der kæder en AI-hallucination sammen med en prompt injektion, så en AI-kodningsagent, der henter en hallucineret ressource på en brugers vegne, kan kapres til at køre angriberleveret kode. Dette udvider udviklingen af slopsquatting fra en passiv installationsrisiko til en aktiv fjernkodeudførelsesvektor i agentudviklingsworkflows.
Hvorfor "vibe coding" udvidede overfladen for slopsquatting-angreb
Slopsquatting-angreb ville ikke betyde så meget, hvis AI-genereret kode var en nichepraksis. Det er det ikke. Fremkomsten af kodningsassistenter, autonome agenter og "vibe coding"-arbejdsgange, hvor udviklere gennemgår mindre og mindre af koden, før de kører den, har ændret softwareangrebsfladen på to konkrete måder, og begge accelererer udviklingen af slopsquatting:
- Indgangspunktet er ikke længere kun udvikleren. Et typosquatting-angreb plejede at afhænge af, at en enkelt person lavede en skrivefejl. Nu kan fejlen opstå inde i selve modellen og sprede sig til hundredvis af forskellige udviklere, der stiller lignende spørgsmål og får den samme hallucinerede anbefaling, hvilket mangedobler rækkevidden af et enkelt slopsquatting-angreb.
- Angrebsfladen er rykket længere op i kæden. Det er ikke længere nok at holde øje med den kode, et menneske skriver. Teams skal også holde øje med de afhængigheder, en AI-assistent foreslår, de MCP-servere, den opretter forbindelse til, og de agenter, der installerer pakker autonomt uden direkte menneskelig gennemgang. Traditionel AppSec, bygget til at gennemgå arkiver og menneskelige... commits, blev aldrig designet til at observere denne nye interaktion mellem udvikler, AI og pakkeregister, hvilket er præcis der, hvor slopsquatting-angreb nu gemmer sig.
Intet af dette betyder, at generativ AI i sagens natur er usikker. Det betyder, at den introducerer en ny type risiko i forsyningskæden, som traditionelle sikkerhedsværktøjer ikke er bygget til at fange, og en risiko, der kræver de samme verifikationsprincipper, som vi allerede anvender på enhver ekstern afhængighed: stol ikke som standard på kilden, verificer kilden, og automatiser denne verifikation i stedet for at stole på hver udviklers hukommelse eller årvågenhed. Denne automatisering er fundamentet for enhver reel strategi til forebyggelse af slopsquatting.
Forebyggelse af slopsquatting: hvad teams kan gøre i dag
Den gode nyhed er, at forebyggelse af slopsquatting ikke kræver eksotiske værktøjer. Det kræver systematisk anvendelse af afhængighedshygiejnepraksisser, der allerede findes, men som mange teams slapper af i det øjeblik, en AI, de har tillid til, "foreslår" koden. En effektiv tilgang til forebyggelse af slopsquatting kombinerer normalt følgende:
- Bekræft manuelt enhver ny pakke, før du installerer den, især når det kommer fra en AI-assistents forslag. Bekræft, at det findes i det officielle register, hvem der vedligeholder det, hvornår det blev udgivet, og om dets downloadtal ser rigtige ud. Denne ene vane er den billigste form for slopsquatting-forebyggelse, der er tilgængelig for ethvert hold.
- Gå aldrig ud fra, at AI-genereret kode som standard er sikker. Et kodestykke, der "virker", betyder ikke, at dets afhængigheder er legitime. Gennemgang af afhængigheder bør være en del af kodegennemgangen, ikke en undtagelse fra den.
- Brug låsefiler og hashverifikation at fastlåse nøjagtige versioner og forhindre en lydløs opdatering i at bytte i en anden pakke end den, der oprindeligt blev revideret.
- Implementer afhængighedsscanning, der markerer risikomønstre ud over kendte CVE'er: unormale pakker, navne der mistænkeligt ligner eksisterende, nye vedligeholdere uden historik eller installationsscripts med usædvanlig opførsel. En nyligt udgivet pakke med næsten ingen historik, der efterligner navnet på noget "næsten" velkendt, er præcis mønsteret bag de fleste slopsquatting-angreb, der er dokumenteret indtil videre.
- Behandl offentlige registre med samme skepsiscism som enhver anden ubekræftet ekstern kilde. Det faktum, at pip installation or npm installere ikke kaster en fejl er ikke bevis på legitimitet.
- Træn udviklingsteams på den kendsgerning, at AI-assisteret kodning ikke fjerner ansvaret for at verificere, hvad der installeres; det tilføjer blot et trin, der skal indbygges i arbejdsgangen som en del af enhver seriøs plan til forebyggelse af slopsquatting.
Ingen af disse tiltag er nye i sig selv. Det, der har ændret sig, er skalaen: Når et afhængighedsforslag ikke længere kommer fra Stack Overflow eller en kollega, men fra en model, der kan gentage den samme hallucinerede fejl til tusindvis af forskellige udviklere, er manuel verifikation, selvom den stadig er nødvendig, ikke længere tilstrækkelig i sig selv. Derfor automatiserer flere teams dette lag af slopsquatting-forebyggelse i deres Analyse af softwarekomposition (SCA) værktøj, i stedet for at overlade det til den enkelte udviklers disciplin.
Dette er førcishvorfor ASPM platforme som Xygeni Indbyg detektion af mistænkelige afhængigheder, der dækker typosquatting, afhængighedsforvirring og kendte ondsindede pakker, i den samme open source- og AI-afhængighedsanalyse. pipeline, så forebyggelse af slopsquatting afhænger ikke af, at alle udviklere husker at tjekke det, hver gang en AI-assistent foreslår en ny afhængighed.
Ofte stillede spørgsmål
Er et slopsquatting-angreb det samme som et typosquatting-angreb?
Ikke helt. Begge involverer registrering af et falsk pakkenavn for at narre den, der installerer det, men kilden til fejlen er forskellig. Typosquatting udnytter menneskelige skrivefejl. Et slopsquatting-angreb udnytter pakkenavne opfundet (hallucineret) af AI-modeller, som en angriber derefter registrerer, før de overhovedet eksisterer legitimt.
Kan en pakkehåndtering automatisk forhindre denne type angreb?
Ikke helt, hvilket netop er grunden til, at slopsquatting-forebyggelse ikke kan stoppe på pakkehåndteringsniveau. Hvis en angriber registrerer den hallucinerede pakke, før en udvikler forsøger at installere den, vil installationen fuldføres uden fejl, fordi pakken rent faktisk eksisterer, selvom den er skadelig. Effektiv forebyggelse kræver yderligere verifikation af pakkens oprindelse og adfærd.
Påvirker dette kun open source-modeller?
Nej. Spracklen et al.-undersøgelsen fandt hallucinationer på tværs af alle testede modeller, inklusive kommercielle, dog med en signifikant lavere rate (5.2 % versus 21.7 % for de evaluerede open source-modeller). Ingen model er helt fri for problemet, hvilket er en del af grunden til, at udviklingen af slopsquatting holder trit med væksten af AI-assisteret kodning generelt.
Er dette en teoretisk risiko, eller er den allerede blevet udnyttet?
huggingface-cli I dette tilfælde viser en tom pakke uploadet af en forsker, der blev downloadet mere end 30,000 gange på tre måneder uden nogen form for promovering, at risikoen ikke kun er teoretisk: et hallucineret navn behøver kun at være konsistent nok på tværs af forskellige prompts til, at nogen kan forvandle det til et rigtigt slopsquatting-angreb.
