Problém v jedné větě
Příště a Asistent s umělou inteligencí doporučuje balíček k instalaci, ověříte si vůbec, zda ten balíček existuje? Většina vývojářů to neudělala. Právě tato mezera mezi návrhem a ověřením je místem, kde začínají útoky typu „slopsquatting“, a proto se pochopení vývoje „slopsquattingu“ a jeho praktické prevence stalo skutečnou prioritou pro týmy AppSec a DevSecOps.
Co je to útok s dřepy?
Útok s dřepy je variantou překlepy (praxe registrace domény nebo názvu balíčku, který napodobuje legitimní název běžným překlepem, například požadavky místo žádosti(v naději, že ho k němu přímo dovede uživatelova vlastní překlep), ale s důležitým rozdílem v tom, kde chyba vzniká. Typosquatting zneužívá lidské překlepy. Slopsquattingový útok využívá chyb, kterých se dopouštějí velké jazykové modely: LLM „halucinuje“ název balíčku, který zní naprosto legitimně, ale neexistuje v žádném veřejném registru, a útočník se tam dostane první tím, že zaregistruje přesně tento název dříve, než ho udělá kdokoli s dobrými úmysly.
Mechanismus typického útoku s dřepy na nohou je jednoduchý a právě tato jednoduchost ho činí efektivním:
- Vývojář požádá asistenta umělé inteligence o pomoc s řešením kódovacího problému.
- Model generuje řešení, které importuje nebo doporučuje instalaci balíčku, který nikdy neexistoval.
- Útočník, který si všimne, že několik modelů neustále opakuje stejný halucinovaný název, zaregistruje tento balíček se škodlivým kódem uvnitř na npm, PyPI nebo jiném veřejném registru. V tomto okamžiku se halucinace změní ve skutečný útok typu „slopsquatting“.
- Další vývojář, který dostane stejný návrh a neověří ho, nainstaluje nyní skutečný balíček, což jsou zadní vrátka do jeho prostředí.
Termín „slopsquatting“ (nedbalé používání hardwaru) zavedl Seth Larson, rezidenční vývojář zabezpečení v Python Software Foundation, a zpopularizoval ho Andrew Nesbitt, aby popsal přesně tento vzorec: „halucinace balíčku“ se proměnila ve vektor útoku.
Evoluce nedbalé existence: jak se z výzkumné zvědavosti stala skutečná hrozba
Na vývoji slopsquattingu není pozoruhodný jen samotný koncept, ale i to, jak rychle se přeměnil z výzkumného pozorování na zdokumentovaný a měřitelný typ útoku.
2023: První varovný signál. Bezpečnostní výzkumník Bar Lanyado všiml si, že několik LLM opakovaně doporučovalo balíček s názvem huggingface-cli, který neexistuje (skutečný balíček je nainstalován s pip install -U „huggingface_hub[cli]“). Aby demonstroval riziko, nahrál prázdnou verzi tohoto balíčku do veřejného registru. Během tří měsíců zaznamenal přes 30 000 stažení bez jakékoli propagace. Halucinační název se dokonce objevil v souboru README repozitáře spojeného s výzkumem společnosti Alibaba, což brzy ukázalo, jak by tyto „falešné“ názvy mohly proniknout do skutečné dokumentace a připravit půdu pro následné nedbalé útoky.
2024: Riziko se přesouvá z blogového příspěvku výzkumníka do mainstreamového technologického zpravodajství. V březnu 2024, Registru informoval o tom, jak modely umělé inteligence sebevědomě vymýšlely názvy softwarových balíčků, které si vývojáři následně stahovali, přičemž některé z nich mohly být infikovány malwarem. Toto zpravodajství nebylo ani tak důležité pro to, co technicky odhalovalo, jako spíše pro to, co signalizovalo: případ huggingface-cli už nebyl ojedinělou kuriozitou; byl prvním náznakem dostatečně závažného vzorce, aby na něj upozornil mainstreamový technologický tisk, a to ještě před rozsáhlou akademickou studií, která o rok později potvrdila jeho rozsah.
2025: První důkladné měření problému ve velkém měřítku. Papír „Máme pro vás balíček! Komplexní analýza halucinací balíčků pomocí LLM generujících kód“ (Spracklen et al., prezentované na Zabezpečení USENIX Symposium) testovalo 16 modelů generování kódu, komerčních (GPT-4, GPT-3.5) i open source (CodeLlama, DeepSeek, WizardCoder, Mistral), na 576 000 ukázkách kódu v Pythonu a JavaScriptu. Zjištění označují jasný bod v evoluci slopsquattingu a posouvají ho od anekdoty k datům:
- 19.7% z balíčků doporučených modely neexistoval.
- Modely s otevřeným zdrojovým kódem halucinovaly mnohem častěji (21.7% v průměru) než komerční modely (5.2%).
- Nejhorší pachatelé, CodeLlama 7B a CodeLlama 34B, halucinovali ve více než třetině svých výstupů.
- U všech testovaných modelů se výzkumníci zaregistrovali 205 000 unikátních halucinovaných názvů balíčků, což je bazén dostatečně velký na to, aby podporoval trvalé útoky typu „slopsquatting“ napříč různými ekosystémy.
- Jeden detail, který je obzvláště důležitý pro prevenci: zhruba 38% halucinovaných jmen se velmi podobala skutečným balíčkům, což snižuje pravděpodobnost, že si jich někdo všimne na první pohled.
Důležitým detailem studie a pravděpodobně i důvodem, proč se vývoj halucinace spíše zrychlil než zastavil, je to, že halucinované názvy nejsou náhodné a nemění se při každém pokusu. Stejné modely mají tendenci opakovat stejné vymyšlené názvy, když dostanou podobné výzvy, což znamená, že útočník nemusí hádat. Stačí pozorovat chování modelu, identifikovat názvy, které se stále opakují, a zaregistrovat je dříve, než to udělá skutečný vývojář. Následná analýza této opakovatelnosti zjistila, že když vědci desetkrát spustili identické výzvy, 43 % halucinovaných názvů balíčků se objevilo při každém jednotlivém spuštění a 58 % se opakovalo vícekrát, což dokazuje, že většina halucinací jsou spíše opakovatelné artefakty než jednorázový šum. Tato opakovatelnost je to, co proměňuje jednorázovou halucinaci v škálovatelný útok halucinace.
2026: Od izolovaných balíčků k autonomním agentům. Letošní rok přinesl dosud nejjasnější důkaz, že nedbalost se již neomezuje jen na kopírování a vkládání navrhovaného textu vývojáři. pip nainstalovat or npm install příkaz. V lednu 2026 výzkumník Charlie Eriksen Ve společnosti Aikido Security zjistili, že agenti kódování umělé inteligence již šířili instrukce odkazující na halucinovaný balíček npm, reagovat-codeshift (název, který věrohodně spojuje dva skutečné nástroje, jscodeshift a react-codemod), napříč 237 repozitáři, přičemž agenti se jej stále denně pokoušejí nainstalovat. Eriksen si název zaregistroval sám, obranně, než ho útočník mohl zneužít jako zbraň. Samostatně byl zaznamenán skutečný škodlivý balíček s názvem nevyužité-importy, halucinovaný místo legitimního eslint-plugin-unused-imports, stále zaznamenával zhruba 233 stažení týdně na začátku roku 2026, a to i přes to, že jej npm pozastavilo, což naznačuje, jak dlouho může útok typu slopsquatting přitahovat oběti i po jeho nahlášení. Nedávno, v červenci 2026, vědci popsali související techniku s názvem „HalluSquatting“, která řetězí halucinace umělé inteligence s rychlou injekcí, takže kódovací agent umělé inteligence, který jménem uživatele načítá halucinovaný zdroj, může být zneužit ke spuštění kódu dodaného útočníkem, čímž se vývoj slopsquattingu rozšiřuje z pasivního instalačního rizika na aktivní vektor vzdáleného spuštění kódu v rámci agentních vývojových pracovních postupů.
Proč „vibrační kódování“ rozšířilo prostor pro nedbalé útoky
Útoky typu „slopsquatting“ by moc neznamenaly, kdyby kód generovaný umělou inteligencí byl specializovanou praxí. Není. Vzestup asistentů kódování, autonomních agentů a pracovních postupů „vibe coding“, kde vývojáři před spuštěním kontrolují stále méně kódu, posunul povrch softwarových útoků dvěma konkrétními způsoby a oba urychlují vývoj „slopsquattingu“:
- Vstupním bodem už není jen vývojář. Útok typu „typosquatting“ dříve závisel na tom, že jedna osoba udělá překlep. Nyní může chyba vzniknout uvnitř samotného modelu a šířit se ke stovkám různých vývojářů, kteří kladou podobné otázky a dostávají stejné halucinované doporučení, čímž se znásobí dosah jediného útoku typu „slopsquatting“.
- Útočná plocha se posunula dále v řetězci. Už nestačí sledovat kód, který píše člověk. Týmy musí také sledovat závislosti, které navrhuje asistent s umělou inteligencí, servery MCP, ke kterým se připojuje, a agenty, kteří instalují balíčky autonomně bez přímé lidské kontroly. Tradiční AppSec, vytvořený pro kontrolu repozitářů a lidských zdrojů. commits, nebyl nikdy navržen tak, aby sledoval tuto novou interakci mezi vývojářem, umělou inteligencí a registrem balíčků, což je přesně to, kde se nyní skrývají nedbalé útoky.
Nic z toho neznamená, že generativní umělá inteligence je ze své podstaty nejistá. Znamená to, že zavádí nový typ rizika pro dodavatelský řetězec, proti kterému tradiční bezpečnostní nástroje nebyly navrženy, a který vyžaduje stejné principy ověřování, jaké již uplatňujeme na jakoukoli externí závislost: nedůvěřujte automaticky, ověřte zdroj a toto ověřování automatizujte, místo abyste se spoléhali na paměť nebo bdělost každého vývojáře. Tato automatizace je základem jakékoli skutečné strategie prevence nedbalostního chování.
Prevence dřepů: co mohou týmy dělat dnes
Dobrou zprávou je, že prevence nedbalé praxe nevyžaduje žádné exotické nástroje. Vyžaduje systematické uplatňování již existujících postupů hygieny závislostí, ale mnoho týmů se uvolní v okamžiku, kdy jim umělá inteligence, které důvěřují, „navrhne“ kód. Efektivní přístup k prevenci nedbalé praxe obvykle kombinuje následující:
- Před instalací každého nového balíčku jej ručně ověřte., zejména pokud pochází z návrhu asistenta umělé inteligence. Ověřte, zda existuje v oficiálním registru, kdo jej spravuje, kdy byl publikován a zda počet jeho stažení vypadá reálně. Tento jediný zvyk je nejlevnější formou prevence dřepů, kterou má jakýkoli tým k dispozici.
- Nikdy nepředpokládejte, že kód generovaný umělou inteligencí je ve výchozím nastavení bezpečný. Úryvek kódu, který „funguje“, neznamená, že jeho závislosti jsou legitimní. Kontrola závislostí by měla být součástí kontroly kódu, nikoli výjimkou.
- Používejte lockfiles a ověřování hashů pro zafixování přesných verzí a zabránění tiché aktualizaci v nahrazování jiného balíčku, než který byl původně auditován.
- Nasaďte skenování závislostí, které signalizuje rizikové vzorce nad rámec známých CVE.: anomální balíčky, názvy podezřele podobné stávajícím, noví správci bez historie nebo instalační skripty s neobvyklým chováním. Nově publikovaný balíček téměř bez historie, který se velmi podobá názvu něčeho „téměř“ známého, je přesně ten vzorec, který stojí za většinou dosud zdokumentovaných nedbalostních útoků.
- Zacházejte s veřejnými registry se stejnou skepsícism jako jakýkoli jiný neověřený externí zdroj. Skutečnost, že se pip nainstalovat or npm install To, že nevyvolá chybu, není důkazem legitimity.
- Školení vývojových týmů na tom, že kódování s pomocí umělé inteligence neodstraňuje odpovědnost za ověřování toho, co se instaluje; pouze přidává krok, který je třeba zabudovat do pracovního postupu jako součást jakéhokoli seriózního plánu prevence nedbalostního chování.
Žádné z těchto opatření samo o sobě není nové. Změnil se pouze rozsah: když návrh závislosti již nepochází ze Stack Overflow nebo od kolegy, ale z modelu, který dokáže opakovat stejnou halucinovanou chybu tisícům různých vývojářů, manuální ověřování, i když je stále nutné, samo o sobě přestává stačit. Proto stále více týmů automatizuje tuto vrstvu prevence nedbalostního chování ve svých projektech. Analýza složení softwaru (SCA) nástroje, spíše než aby to bylo ponecháno na disciplíně jednotlivých vývojářů.
Toto je předcisproč ASPM plošiny jako Xygeni zabudovat detekci podezřelých závislostí, včetně překlepů, záměny závislostí a známých škodlivých balíčků, do stejné analýzy závislostí open-source a AI pipeline, takže prevence nedbalostního chování nezávisí na tom, zda si každý vývojář pamatuje, že to má zkontrolovat pokaždé, když asistent umělé inteligence navrhne novou závislost.
Nejčastější dotazy
Je útok typu „slopsquatting“ totéž co útok typu „typosquatting“?
Ne tak docela. Oba zahrnují registraci falešného názvu balíčku, aby se oklamal ten, kdo jej nainstaluje, ale zdroj chyby se liší. Typosquatting využívá lidské chyby při psaní. Slopsquatting útok využívá názvy balíčků vymyšlené (halucinované) modely umělé inteligence, které útočník poté zaregistruje ještě předtím, než vůbec legitimně existují.
Může správce balíčků automaticky zabránit tomuto typu útoku?
Ne úplně, a to je přesně důvod, proč se prevence nedbale vypořádávaného balíčku nemůže zastavit na úrovni správce balíčků. Pokud útočník zaregistruje halucinovan balíček dříve, než se ho vývojář pokusí nainstalovat, instalace se dokončí bez chyby, protože balíček skutečně existuje, i když je škodlivý. Účinná prevence vyžaduje dodatečné ověření původu a chování balíčku.
Ovlivňuje to pouze modely s otevřeným zdrojovým kódem?
Ne. Studie Spracklena a kol. zjistila halucinace u všech testovaných modelů, včetně komerčních, i když s výrazně nižší mírou (5.2 % oproti 21.7 % u hodnocených modelů s otevřeným zdrojovým kódem). Žádný model není zcela bez tohoto problému, což je částečně důvod, proč vývoj slopsquattingu drží krok s růstem kódování s pomocí umělé inteligence celkově.
Je to teoretické riziko, nebo už bylo využito?
Jedno huggingface-cli Případ prázdného balíčku nahraného výzkumníkem, který byl stažen více než 30 000krát za tři měsíce bez žádnou propagace, ukazuje, že riziko není jen teoretické: halucinované jméno stačí, aby bylo dostatečně konzistentní napříč různými výzvami, aby ho někdo proměnil ve skutečný nedbalý útok.
