Slopsquatting
En udvikler beder en AI-assistent om at løse et problem, og assistenten svarer med en importlinje til et pakkenavn, der lyder helt rigtigt. Problemet er, at pakken ikke findes, i hvert fald ikke endnu. Angribere har opdaget mønsteret og registrerer nu de samme opdigtede navne på npm og PyPI, fyldt med malware, klar til at blive hentet af den næste udvikler, der stoler på sin AI-assistent uden at tjekke efter. Det kaldes slopsquatting, og det er den nyeste variant af et gammelt angreb mod softwareforsyningskæden, bygget på en helt ny svaghed: AI-modellers tendens til at opfinde ting med fuld selvsikkerhed.
Sådan opstår et fabrikeret pakkenavn i praksis
Når en sprogmodel skal foreslå et bibliotek til en bestemt opgave, trækker den på mønstre fra træningsdata snarere end et opdateret register over faktiske pakker. Resultatet er ofte plausibelt, et navn der følger konventionerne i økosystemet og lyder som noget, der burde eksistere. fast-json-parser, secure-auth-utils, react-hook-validator, den slags navne rammer et sprogligt mønster, ikke en faktisk registrering. Når modellen genererer kode med tilhørende pip install eller npm install-kommando, tager udvikleren ofte navnet for gode varer og kopierer det direkte ind i terminalen.
Angriberen behøver ikke gætte tilfældigt. Ved at teste populære prompts mod flere AI-kodningsassistenter kan man systematisk identificere, hvilke opdigtede pakkenavne der dukker op igen og igen. De navne, der er mest konsistente på tværs af forespørgsler, er dem, der er mest attraktive at registrere først, fordi de med størst sandsynlighed bliver foreslået til en rigtig udvikler senere.
Forskellen på typosquatting og slopsquatting
Typosquatting har eksisteret, siden pakkeregistre blev en del af udviklerens hverdag. Angriberen registrerer et fejlstavet navn og venter på, at nogen taster forkert. Forsvaret er relativt simpelt: stavekontrol, kendte pakkenavne og opmærksomme udviklere fanger de fleste forsøg.
Slopsquatting vender logikken om. Det gør angrebet sværere at opdage i øjeblikket, fordi den vanlige advarselslampe, et ukendt eller mistænkeligt navn, aldrig blinker. Navnet ser bekendt ud, netop fordi det er designet til at lyde bekendt.
Hvorfor open source-modeller er markant mere udsatte
Forskning i hallucinationsrater på tværs af forskellige kodeassistenter viser en tydelig forskel mellem kommercielle og open source-modeller. Open source-modeller, der ofte kørt lokalt eller integreres i mindre finpudsede værktøjskæder, opfinder pakkenavne markant hyppigere end de store kommercielle assistenter fra virksomheder med dedikerede teams til at reducere hallucination.
Det betyder ikke, at kommercielle modeller er immune, men gabet er stort nok til at være en reel driftsbeslutning for virksomheder. Et team, der vælger en open source-model for at spare på licensomkostninger eller for at holde kode internt, bør vide, at valget kommer med en højere risiko for at få foreslået pakker, der ikke findes, og som derfor er sårbare over for at blive kapret af en angriber først.
Vibe coding øger angrebsfladen i virksomhedens kodebase
Den arbejdsform, hvor en udvikler beskriver, hvad koden skal gøre, og lader AI-assistenten generere det meste af implementeringen, ofte kaldet vibe coding, har vundet hurtigt indpas, fordi det er hurtigere. Men hastigheden kommer med en pris: jo mere kode der genereres uden linje-for-linje gennemsyn, jo større er sandsynligheden for, at en opdigtet afhængighed sniger sig med ind i et projekt uden at blive opdaget.
I en traditionel udviklingsproces er hver ny afhængighed en bevidst beslutning. I vibe coding-flowet bliver import-sætninger en del af den generede tekst, som udvikleren accepterer i bulk sammen med resten af forslaget. Det er præcis den type friktionsløse accept, som gør slopsquatting effektivt: angrebet rammer ikke svage sikkerhedsvaner, det rammer et helt nyt arbejdsmønster, hvor tillid til AI-værktøjet erstatter den manuelle kontrol, der tidligere lå implicit i at skrive koden selv. Beslaegtet med den udvikling er f.eks. et agentisk udviklingsmiljø, der genererer store mængder kode uden gennemsyn.
Slopsquatting er ikke et argument imod AI-værktøjer i udviklingsarbejdet, det er et argument for at tilpasse kontrollen til den nye arbejdsform
Sådan verificerer udviklere en pakke, før den installeres
Den praktiske løsning kræver ikke, at man dropper AI-assistenter, men at man genindfører et kontroltrin, der er blevet væk i farten. En pakke med få hundrede downloads og en oprettelsesdato for få uger siden er et advarselstegn, uanset hvor plausibelt navnet lyder.
For teams, der bruger AI-assistenter tungt, er det en fornuftig investering at lægge et automatiseret verifikationslag ind mellem forslag og installation, simpelthen fordi den menneskelige opmærksomhed på pakkenavne er faldet i takt med, at AI-genereret kode er blevet normen.