Problém v jednej vete
Nabudúce a Asistent umelej inteligencie odporúča balík na inštaláciu, naozaj skontrolujete, či ten balík existuje? Väčšina vývojárov to neurobila. Táto medzera medzi návrhom a overením je presne miestom, kde začínajú útoky typu „slopsquatting“, a preto sa pochopenie vývoja „slopsquattingu“ a praktická prevencia tohto typu stali skutočnou prioritou pre tímy AppSec a DevSecOps.
Čo je to útok s drepom v podrepe?
Útok s drepom je variantom preklepy (prax registrácie názvu domény alebo balíka, ktorý napodobňuje legitímny názov pomocou bežného preklepu, ako napríklad požiadavky MIESTO Žiadosti, v nádeji, že ho k nemu priamo privedie používateľova vlastná preklepová chyba), ale s dôležitým rozdielom v tom, kde chyba pochádza. Typosquatting zneužíva ľudské preklepy. Útok typu slopsquatting zneužíva chyby, ktoré robia rozsiahle jazykové modely: LLM „halucinuje“ názov balíka, ktorý znie úplne legitímne, ale neexistuje v žiadnom verejnom registri, a útočník sa tam dostane prvý tým, že zaregistruje tento presný názov skôr, ako ho zaregistruje ktokoľvek s dobrými úmyslami.
Mechanizmus typického útoku s drepmi je jednoduchý a práve táto jednoduchosť ho robí účinným:
- Vývojár požiada asistenta umelej inteligencie o pomoc s riešením kódovacieho problému.
- Model generuje riešenie, ktoré importuje alebo odporúča inštaláciu balíka, ktorý nikdy neexistoval.
- Útočník, ktorý si všimol, že niekoľko modelov neustále opakuje ten istý halucinovaný názov, zaregistruje tento balík so škodlivým kódom vo vnútri na npm, PyPI alebo inom verejnom registri. V tomto momente sa halucinácia zmení na skutočný útok typu „slopsquatting“.
- Ďalší vývojár, ktorý dostane rovnaký návrh a neoverí ho, nainštaluje teraz už skutočný balík, ktorý predstavuje zadné vrátka do jeho prostredia.
Termín „slopsquatting“ zaviedol Seth Larson, rezidenčný vývojár bezpečnosti v Python Software Foundation, a spopularizoval ho Andrew Nesbitt, aby presne opísal tento vzorec: „halucinácia balíčka“ sa zmenila na vektor útoku.
Evolúcia nedbalosti: ako sa výskumná zvedavosť rozrástla na skutočnú hrozbu
Na vývoji slopsquattingu nie je pozoruhodný len samotný koncept; je to, ako rýchlo sa presunul z výskumného pozorovania do zdokumentovanej a merateľnej triedy útoku.
2023: Prvé varovné znamenie. Bezpečnostný výskumník Bar Lanyado všimol si, že niekoľko LLM opakovane odporúčalo balík s názvom huggingface-cli, ktorý neexistuje (skutočný balík sa nainštaluje s pip install -U „huggingface_hub[cli]“). Aby demonštroval riziko, nahral prázdnu verziu tohto balíka do verejného registra. Do troch mesiacov zaznamenal viac ako 30 000 stiahnutí bez akejkoľvek propagácie. Halucinovaný názov sa dokonca objavil v súbore README repozitára prepojeného s výskumom spoločnosti Alibaba, čo už na začiatku ukázalo, ako by tieto „falošné“ názvy mohli uniknúť do skutočnej dokumentácie a pripraviť pôdu pre následné útoky typu „slopsquatting“.
2024: Riziko sa presúva z blogového príspevku výskumníka do hlavného prúdu technologického spravodajstva. V marci 2024, Register informoval o tom, ako modely umelej inteligencie sebavedomo vymýšľali názvy softvérových balíkov, ktoré potom vývojári sťahovali, pričom niektoré z nich boli potenciálne infikované škodlivým softvérom. Toto spravodajstvo nebolo ani tak dôležité pre to, čo technicky odhalilo, ako skôr pre to, čo signalizovalo: prípad huggingface-cli už nebol jednorazovou kuriozitou; bol to prvý náznak vzoru, ktorý bol dostatočne závažný na to, aby ho označila mainstreamová technologická tlač, ešte pred rozsiahlou akademickou štúdiou, ktorá o rok neskôr potvrdila jeho rozsah.
2025: Prvé dôkladné meranie problému vo veľkom meradle. Papier „Máme pre vás balíček! Komplexná analýza halucinácií balíčkov pomocou generovania kódu LLM“ (Spracklen a kol., prezentované na Zabezpečenie USENIX Sympózium) testovalo 16 modelov generovania kódu, komerčných (GPT-4, GPT-3.5) aj open source (CodeLlama, DeepSeek, WizardCoder, Mistral), na 576 000 vzorkách kódu Python a JavaScript. Zistenia označujú jasný bod vo vývoji slopsquattingu a posúvajú ho z anekdoty k dátam:
- 19.7% z balíkov odporúčaných modelmi neexistoval.
- Modely s otvoreným zdrojovým kódom halucinovali oveľa častejšie (21.7% v priemere) ako komerčné modely (5.2%).
- Najhorší páchatelia, CodeLlama 7B a CodeLlama 34B, halucinovali vo viac ako tretine svojich výstupov.
- Vo všetkých testovaných modeloch sa výskumníci zaregistrovali 205 000 unikátnych halucinovaných názvov balíkov, čo je bazén dostatočne veľký na to, aby podporoval trvalé útoky typu „slopsquatting“ vo viacerých ekosystémoch.
- Jeden detail, ktorý je obzvlášť dôležitý pre prevenciu: zhruba 38% halucinované mená sa veľmi podobali skutočným balíkom, čo znižuje pravdepodobnosť, že ich niekto na prvý pohľad spozoruje.
Kritickým detailom štúdie a pravdepodobne dôvodom, prečo sa vývoj slopsquattingu zrýchlil a nie zastavil, je to, že halucinované názvy nie sú náhodné a nemenia sa pri každom pokuse. Tie isté modely majú tendenciu opakovať tie isté vymyslené názvy, keď dostanú podobné výzvy, čo znamená, že útočník nemusí hádať. Stačí pozorovať správanie modelu, identifikovať názvy, ktoré sa neustále opakujú, a zaregistrovať ich skôr, ako to urobí skutočný vývojár. Následná analýza tejto opakovateľnosti zistila, že keď výskumníci spustili identické výzvy desaťkrát, 43 % halucinovaných názvov balíkov sa objavilo pri každom spustení a 58 % sa opakovalo viackrát, čo dokazuje, že väčšina halucinácií sú skôr opakovateľné artefakty ako jednorazový šum. Táto opakovateľnosť je to, čo premieňa jednorazovú halucináciu na škálovateľný útok slopsquattingom.
2026: Od izolovaných balíkov k autonómnym agentom. Tento rok priniesol doteraz najjasnejší dôkaz o tom, že nedbalé praktizovanie už nie je obmedzené len na kopírovanie a vkladanie navrhovaného textu vývojármi. pip nainštalovať or npm install príkaz. V januári 2026 výskumník Charlie Eriksen V spoločnosti Aikido Security zistili, že agenti kódovania umelej inteligencie už šírili inštrukcie odkazujúce na halucinovaný balík npm, reagovať-kódový posun (názov, ktorý vierohodne spája dva skutočné nástroje, jscodeshift a react-codemod), v 237 repozitároch, pričom agenti sa ho stále denne pokúšajú nainštalovať. Eriksen si názov zaregistroval sám, defenzívne, skôr ako ho útočník mohol zneužiť ako zbraň. Samostatne bol zaznamenaný skutočný škodlivý balík s názvom nepoužité-importy, halucinoval namiesto legitímneho eslint-plugin-unused-imports, začiatkom roka 2026 stále zaznamenával približne 233 stiahnutí týždenne, a to aj napriek tomu, že ho npm umiestnil pod bezpečnostné pozastavenie, čo naznačuje, ako dlho môže útok typu „slopsquatting“ priťahovať obete aj po jeho nahlásení. Nedávno, v júli 2026, výskumníci opísali súvisiacu techniku s názvom „HalluSquatting“, ktorá spája halucinácie umelej inteligencie s okamžitou injekciou, takže kódovací agent umelej inteligencie, ktorý v mene používateľa načíta halucinovaný zdroj, môže byť zneužitý a spustiť kód dodaný útočníkom, čím sa vývoj „slopsquattingu“ rozširuje z pasívneho rizika inštalácie na aktívny vektor vzdialeného vykonávania kódu v rámci pracovných postupov agentového vývoja.
Prečo „vibračné kódovanie“ rozšírilo priestor pre útoky typu slopsquatting
Útoky typu „slopsquatting“ by nemali veľký význam, ak by kód generovaný umelou inteligenciou bol len špecializovanou praxou. Nie je. Vzostup programátorských asistentov, autonómnych agentov a pracovných postupov „vibe coding“, kde vývojári pred spustením kontrolujú čoraz menej kódu, posunul povrch softvérových útokov dvoma konkrétnymi spôsobmi a oba urýchľujú vývoj „slopsquattingu“:
- Vstupným bodom už nie je len vývojár. Útok typu „typosquatting“ sa kedysi spoliehal na to, že jedna osoba urobí preklep pri písaní. Teraz môže chyba vzniknúť v samotnom modeli a rozšíriť sa na stovky rôznych vývojárov, ktorí kladú podobné otázky a dostávajú rovnaké halucinované odporúčanie, čím sa znásobí dosah jediného útoku typu „slopsquatting“.
- Útočná plocha sa posunula ďalej v reťazci. Už nestačí sledovať kód, ktorý píše človek. Tímy musia tiež sledovať závislosti, ktoré navrhuje asistent umelej inteligencie, servery MCP, ku ktorým sa pripája, a agentov, ktorí inštalujú balíčky autonómne bez priamej ľudskej kontroly. Tradičná AppSec, vytvorená na kontrolu repozitárov a ľudských zdrojov. commits, nebol nikdy navrhnutý tak, aby sledoval túto novú interakciu medzi vývojárom, umelou inteligenciou a registrom balíkov, čo je presne miesto, kde sa teraz skrývajú útoky typu „slopsquatting“.
Nič z toho neznamená, že generatívna umelá inteligencia je vo svojej podstate neistá. Znamená to, že zavádza nový typ rizika pre dodávateľský reťazec, na ktoré tradičné bezpečnostné nástroje neboli vytvorené, a ktorý si vyžaduje rovnaké princípy overovania, aké už uplatňujeme na akúkoľvek externú závislosť: nedôverujte štandardne, overte zdroj a toto overenie automatizujte namiesto spoliehania sa na pamäť alebo ostražitosť každého vývojára. Táto automatizácia je základom každej skutočnej stratégie prevencie nedbanlivosti.
Prevencia slopsquattingu: čo môžu tímy urobiť už dnes
Dobrou správou je, že prevencia nedbalosti si nevyžaduje exotické nástroje. Vyžaduje si systematické uplatňovanie existujúcich postupov hygieny závislostí, ale mnohé tímy sa uvoľnia v momente, keď im umelá inteligencia, ktorej dôverujú, „navrhne“ kód. Účinný prístup k prevencii nedbalosti zvyčajne kombinuje nasledovné:
- Pred inštaláciou každého nového balíka ho manuálne overte, najmä ak pochádza z návrhu asistenta umelej inteligencie. Overte si, či existuje v oficiálnom registri, kto ho spravuje, kedy bol publikovaný a či jeho počty stiahnutí vyzerajú reálne. Tento jediný zvyk je najlacnejšou formou prevencie proti nedbalosti, akú má akýkoľvek tím k dispozícii.
- Nikdy nepredpokladajte, že kód generovaný umelou inteligenciou je štandardne bezpečný. Úryvok kódu, ktorý „funguje“, neznamená, že jeho závislosti sú legitímne. Kontrola závislostí by mala byť súčasťou kontroly kódu, nie výnimkou.
- Používajte uzamykateľné súbory a overovanie hashu pripnúť presné verzie a zabrániť tichej aktualizácii v nahrádzaní iného balíka, než bol pôvodne auditovaný.
- Nasaďte skenovanie závislostí, ktoré signalizuje rizikové vzorce nad rámec známych CVE: anomálne balíky, názvy podozrivo podobné existujúcim, noví správcovia bez histórie alebo inštalácia skriptov s nezvyčajným správaním. Novo publikovaný balík takmer bez histórie, ktorý sa veľmi podobá názvu niečoho „takmer“ známeho, je presne ten vzorec, ktorý stojí za väčšinou doteraz zdokumentovaných útokov typu „slopsquatting“.
- Správajte sa k verejným registrom s rovnakým skepticizmomcism ako akýkoľvek iný neoverený externý zdroj. Skutočnosť, že pip nainštalovať or npm install To, že nevyvolá chybu, nie je dôkazom legitimity.
- Školenie vývojových tímov na tom, že kódovanie s pomocou umelej inteligencie neodstraňuje zodpovednosť za overovanie toho, čo sa nainštaluje; iba pridáva krok, ktorý je potrebné zabudovať do pracovného postupu ako súčasť každého seriózneho plánu prevencie nedbalostného správania.
Žiadne z týchto opatrení nie je samo o sebe nové. Zmenil sa len rozsah: keď návrh závislosti už nepochádza zo Stack Overflow alebo od kolegu, ale z modelu, ktorý dokáže opakovať tú istú halucinovanú chybu tisíckam rôznych vývojárov, manuálne overovanie, hoci je stále potrebné, samo o sebe prestáva stačiť. Preto stále viac tímov automatizuje túto vrstvu prevencie nedbanlivosti v rámci svojich... Analýza zloženia softvéru (SCA) nástroje, namiesto toho, aby sa to nechalo na disciplínu jednotlivých vývojárov.
Toto je predcisprečo ASPM plošiny Ako Xygeni zabudovať detekciu podozrivých závislostí, ktorá zahŕňa preklepy, zámenu závislostí a známe škodlivé balíky, do rovnakej analýzy závislostí open-source a AI pipeline, takže prevencia nedbalosti nezávisí od toho, či si každý vývojár pamätá, že to má skontrolovať vždy, keď asistent umelej inteligencie navrhne novú závislosť.
Často kladené otázky
Je útok typu „slopsquatting“ to isté ako útok typu „typosquatting“?
Nie celkom. Oba zahŕňajú registráciu falošného názvu balíka, aby sa oklamal ten, kto ho nainštaluje, ale zdroj chyby sa líši. Typosquatting využíva ľudské chyby pri písaní. Slopsquatting využíva názvy balíkov vymyslené (halucinované) modelmi umelej inteligencie, ktoré útočník potom zaregistruje ešte predtým, ako vôbec legitímne existujú.
Dokáže správca balíkov automaticky zabrániť tomuto druhu útoku?
Nie úplne, a práve preto sa prevencia proti nedbanlivosti nemôže zastaviť na úrovni správcu balíkov. Ak útočník zaregistruje halucinogénny balík skôr, ako sa ho vývojár pokúsi nainštalovať, inštalácia sa dokončí bez akejkoľvek chyby, pretože balík skutočne existuje, aj keď je škodlivý. Účinná prevencia si vyžaduje dodatočné overenie pôvodu a správania balíka.
Ovplyvňuje to iba modely s otvoreným zdrojovým kódom?
Nie. Štúdia Spracklena a kol. zistila halucinácie vo všetkých testovaných modeloch vrátane komerčných, hoci s výrazne nižšou mierou (5.2 % oproti 21.7 % u hodnotených modelov s otvoreným zdrojovým kódom). Žiadny model nie je úplne bez tohto problému, čo je čiastočne dôvod, prečo vývoj slopsquattingu drží krok s rastom kódovania s pomocou umelej inteligencie celkovo.
Je to teoretické riziko, alebo už bolo využité?
huggingface-cli Prípad prázdneho balíka nahraného výskumníkom, ktorý bol stiahnutý viac ako 30 000-krát za tri mesiace bez žiadnej propagácie, ukazuje, že riziko nie je len teoretické: halucinované meno musí byť dostatočne konzistentné v rôznych výzvach, aby ho niekto premenil na skutočný útok s použitím nedbalosti.
