Problem w jednym zdaniu
Następnym razem Asystent AI zaleca pakiet do zainstalowaniaCzy faktycznie sprawdzicie, czy ten pakiet istnieje? Większość deweloperów tego nie zrobiła. Ta luka między sugestią a weryfikacją to właśnie punkt wyjścia ataków slopsquattingowych i dlatego zrozumienie zarówno ewolucji slopsquattingu, jak i praktycznego zapobiegania mu stało się prawdziwym priorytetem dla zespołów AppSec i DevSecOps.
Czym jest atak slopsquattingowy?
Atak typu slopsquatting jest odmianą typosquatting (praktyka rejestrowania nazwy domeny lub pakietu, która naśladuje nazwę legalną poprzez powszechny błąd w pisowni, np. prośby zamiast wywołań(mając nadzieję, że literówka użytkownika doprowadzi go prosto do celu), ale z istotną różnicą w miejscu, gdzie błąd się pojawia. Typosquatting wykorzystuje ludzkie błędy literowe. Atak slopsquatting wykorzystuje błędy popełniane przez duże modele językowe: LLM „halucynuje” nazwę pakietu, która brzmi całkowicie poprawnie, ale nie istnieje w żadnym publicznym rejestrze, a atakujący rejestruje ją jako pierwszy, zanim zrobi to ktokolwiek z dobrymi intencjami.
Mechanizm typowego ataku slopsquattingowego jest prosty i to właśnie ta prostota sprawia, że jest on skuteczny:
- Programista prosi asystenta AI o pomoc w rozwiązaniu problemu kodowania.
- Model generuje rozwiązanie, które importuje lub zaleca instalację pakietu, który nigdy nie istniał.
- Atakujący, który zauważył, że kilka modeli powtarza tę samą halucynowaną nazwę, rejestruje ten pakiet w npm, PyPI lub innym rejestrze publicznym, zawierający złośliwy kod. W tym momencie halucynacja przeradza się w prawdziwy atak typu slopsquatting.
- Następny programista, który otrzyma tę samą sugestię i jej nie zweryfikuje, zainstaluje istniejący już pakiet, który będzie stanowił tylne wejście do jego środowiska.
Termin „slopsquatting” został wymyślony przez Setha Larsona, specjalistę ds. bezpieczeństwa w Python Software Foundation, a spopularyzowany przez Andrew Nesbitta. Opisuje on dokładnie następujący schemat: „halucynacja pakietem” przekształcona w wektor ataku.
Ewolucja slopsquattingu: jak ciekawość badawcza przerodziła się w realne zagrożenie
Co jest godne uwagi w ewolucji slopsquattingu, to nie tylko sama koncepcja, ale także szybkość, z jakiej zjawisko to przeszło od obserwacji naukowej do udokumentowanej, mierzalnej klasy ataków.
2023: Pierwszy znak ostrzegawczy. Badacz ds. bezpieczeństwa Bar Lanyado zauważyłem, że kilku LLM-ów wielokrotnie zalecało pakiet o nazwie huggingface-cli, który nie istnieje (prawdziwy pakiet jest instalowany za pomocą pip install -U “huggingface_hub[cli]”Aby zademonstrować ryzyko, umieścił pustą wersję tego pakietu w publicznym rejestrze. W ciągu trzech miesięcy pobrano ją ponad 30 000 razy, bez żadnej promocji. Wyimaginowana nazwa pojawiła się nawet w pliku README repozytorium powiązanego z badaniami Alibaby, pokazując już na wczesnym etapie, jak te „fałszywe” nazwy mogą przedostać się do prawdziwej dokumentacji i przygotować grunt pod późniejsze ataki typu slopsquatting.
2024: Ryzyko przenosi się z wpisów na blogach badaczy do głównego nurtu relacji z technologii. W marcu 2024, Rejestr donosił o tym, jak modele sztucznej inteligencji z pewnością siebie wymyślały nazwy pakietów oprogramowania, które następnie pobierali programiści, a niektóre z nich potencjalnie były zatruwane złośliwym oprogramowaniem. Ten materiał miał mniejsze znaczenie ze względu na to, co ujawniał technicznie, a większe ze względu na to, co sygnalizował: przypadek huggingface-cli nie był już jednorazową ciekawostką; był pierwszym sygnałem wzorca na tyle poważnego, że prasa technologiczna głównego nurtu zwróciła na niego uwagę, zanim zakrojone na szeroką skalę badanie naukowe potwierdziło jego zakres rok później.
2025: Pierwsze dokładne pomiary problemu na dużą skalę. Papier „Mamy dla Ciebie pakiet! Kompleksowa analiza halucynacji pakietowych poprzez kodowanie LLM” (Spracklen i in., zaprezentowani na Bezpieczeństwo USENIX Symposium) przetestowało 16 modeli generowania kodu, zarówno komercyjnych (GPT-4, GPT-3.5), jak i open source (CodeLlama, DeepSeek, WizardCoder, Mistral), na 576 000 przykładach kodu Pythona i JavaScript. Wyniki stanowią wyraźny punkt zwrotny w ewolucji slopsquattingu, przenosząc go z anegdoty do danych:
- 19.7% żaden z pakietów polecanych przez modelki nie istniał.
- Modele open-source wywoływały halucynacje znacznie częściej (21.7% średnio) niż modele komercyjne (5.2%).
- Najgorsi przestępcy, CodeLlama 7B i CodeLlama 34B, mieli halucynacje w przypadku ponad jednej trzeciej swoich wyników.
- We wszystkich testowanych modelach badacze zalogowali się 205 000 unikalnych nazw pakietów halucynacyjnych, basen wystarczająco duży, aby zasilać ciągłe ataki slopsquattingowe w wielu ekosystemach.
- Jeden szczegół jest szczególnie istotny w kontekście profilaktyki: mniej więcej 38% wymyślonych nazw bardzo przypominało prawdziwe paczki, co zmniejszało prawdopodobieństwo, że ktokolwiek zauważy je na pierwszy rzut oka.
Kluczowym szczegółem badania, i prawdopodobnie powodem, dla którego ewolucja slopsquattingu przyspieszyła, a nie wygasła, jest to, że halucynacje nazw nie są losowe i nie zmieniają się przy każdej próbie. Te same modele mają tendencję do powtarzania tych samych wymyślonych nazw, gdy otrzymują podobne monity, co oznacza, że atakujący nie musi zgadywać. Wystarczy, że zaobserwuje zachowanie modelu, zidentyfikuje powtarzające się nazwy i zarejestruje je, zanim zrobi to prawdziwy programista. Dalsza analiza tej powtarzalności wykazała, że gdy badacze po raz dziesięciokrotnie uruchamiali te same monity, 43% halucynacji nazw pakietów pojawiało się przy każdym uruchomieniu, a 58% powtarzało się więcej niż raz, co dowodzi, że większość halucynacji to powtarzalne artefakty, a nie jednorazowy szum. To właśnie ta powtarzalność przekształca jednorazową halucynację w skalowalny atak slopsquattingowy.
2026: Od odizolowanych pakietów do autonomicznych agentów. W tym roku pojawiły się najwyraźniejsze jak dotąd dowody na to, że slopsquatting nie ogranicza się już do kopiowania i wklejania sugerowanych treści przez programistę. instalacja pipsa or npm zainstalować polecenie. W styczniu 2026 r. badacz Charlie Eriksen w Aikido Security odkryto, że agenci kodujący sztuczną inteligencję już rozpowszechnili instrukcje odwołujące się do pakietu npm, który był halucynacją, reaktywna zmiana kodu (nazwa, która prawdopodobnie łączy w sobie dwa prawdziwe narzędzia, jscodeshift oraz React-codemod), w 237 repozytoriach, a agenci wciąż próbują go codziennie zainstalować. Eriksen zarejestrował tę nazwę samodzielnie, w ramach obrony, zanim atakujący mógłby ją wykorzystać jako broń. Oddzielnie, prawdziwy złośliwy pakiet o nazwie niewykorzystane importy, halucynacja zamiast legalnego wtyczka eslint-nieużywane-importy, nadal rejestrował około 233 pobrań tygodniowo na początku 2026 roku, pomimo objęcia go blokadą bezpieczeństwa przez npm, co pokazuje, jak długo atak slopsquattingowy może przyciągać ofiary, nawet po jego oflagowaniu. Niedawno, w lipcu 2026 roku, naukowcy opisali pokrewną technikę, nazwaną „HalluSquatting”, która łączy halucynację sztucznej inteligencji z natychmiastowym wstrzyknięciem, tak aby agent kodujący AI pobierający halucynowany zasób w imieniu użytkownika mógł zostać przejęty i uruchomić kod dostarczony przez atakującego. Tym samym ewolucja slopsquattingu z pasywnego ryzyka instalacji przekształciła się w aktywny wektor zdalnego wykonywania kodu w ramach agentowych przepływów pracy programistycznych.
Dlaczego „kodowanie wibracji” rozszerzyło pole ataków typu slopsquatting
Ataki typu slopsquatting nie miałyby większego znaczenia, gdyby kod generowany przez sztuczną inteligencję był niszową praktyką. Nie jest. Rozwój asystentów kodowania, autonomicznych agentów i przepływów pracy typu „vibe coding”, w których programiści przeglądają coraz mniej kodu przed jego uruchomieniem, zmienił powierzchnię ataku na oprogramowanie w dwóch konkretnych kierunkach, a oba przyspieszają ewolucję slopsquattingu:
- Punktem wejścia nie jest już tylko deweloper. Atak typosquattingowy polegał kiedyś na tym, że jedna osoba popełniła błąd w pisowni. Teraz błąd może mieć swoje źródło w samym modelu i rozprzestrzeniać się na setki różnych programistów, którzy zadają podobne pytania i otrzymują te same halucynacje, zwielokrotniając zasięg pojedynczego ataku slopsquattingowego.
- Powierzchnia ataku przesunęła się wyżej w łańcuchu. Nie wystarczy już obserwować kod pisany przez człowieka. Zespoły muszą również obserwować zależności sugerowane przez asystenta AI, serwery MCP, z którymi się łączy, oraz agentów instalujących pakiety autonomicznie, bez bezpośredniego przeglądu przez człowieka. Tradycyjny AppSec, stworzony do przeglądania repozytoriów i kontroli przez człowieka. commits, nigdy nie został zaprojektowany z myślą o obserwowaniu tej nowej interakcji między programistą, sztuczną inteligencją i rejestrem pakietów, a to właśnie tam ukrywają się obecnie ataki slopsquattingu.
Nic z tego nie oznacza, że generatywna sztuczna inteligencja jest z natury niebezpieczna. Oznacza to, że wprowadza nowy rodzaj ryzyka w łańcuchu dostaw, którego tradycyjne narzędzia bezpieczeństwa nie były w stanie wykryć, i które wymaga tych samych zasad weryfikacji, które stosujemy już do każdej zależności zewnętrznej: nie ufaj domyślnie, weryfikuj źródło i automatyzuj tę weryfikację, zamiast polegać na pamięci lub czujności każdego programisty. Ta automatyzacja stanowi fundament każdej prawdziwej strategii zapobiegania slopsquattingowi.
Zapobieganie slopsquattingowi: co zespoły mogą zrobić już dziś
Dobra wiadomość jest taka, że zapobieganie slopsquattingowi nie wymaga stosowania egzotycznych narzędzi. Wymaga systematycznego stosowania już istniejących praktyk higieny zależności, ale wiele zespołów rezygnuje z pracy, gdy zaufana sztuczna inteligencja „sugeruje” kod. Skuteczne podejście do zapobiegania slopsquattingowi zazwyczaj łączy w sobie następujące elementy:
- Przed zainstalowaniem nowego pakietu należy go ręcznie sprawdzić, zwłaszcza gdy pochodzi od sugestii asystenta AI. Sprawdź, czy istnieje w oficjalnym rejestrze, kto go prowadzi, kiedy został opublikowany i czy liczba pobrań wygląda na prawdziwą. Ten pojedynczy nawyk to najtańsza forma zapobiegania slopsquattingowi dostępna dla każdego zespołu.
- Nigdy nie zakładaj, że kod generowany przez sztuczną inteligencję jest domyślnie bezpieczny. Fragment kodu, który „działa”, nie oznacza, że jego zależności są prawidłowe. Przegląd zależności powinien być częścią przeglądu kodu, a nie wyjątkiem od niego.
- Użyj plików blokujących i weryfikacji skrótu aby przypiąć dokładne wersje i zapobiec temu, aby cicha aktualizacja zamieniła pakiet na inny niż ten, który został pierwotnie zweryfikowany.
- Wdróż skanowanie zależności, które sygnalizuje wzorce ryzyka wykraczające poza znane CVE: nietypowe pakiety, nazwy podejrzanie podobne do istniejących, nowi opiekunowie bez historii lub skrypty instalacyjne o nietypowym zachowaniu. Nowo opublikowany pakiet, praktycznie bez historii, którego nazwa jest wierną kopią czegoś „prawie” znajomego, to dokładnie schemat leżący u podstaw większości udokumentowanych do tej pory ataków typu slopsquatting.
- Podchodź do rejestrów publicznych z takim samym sceptycyzmemcism jak każde inne niezweryfikowane źródło zewnętrzne. Fakt, że instalacja pipsa or npm zainstalować brak błędu nie jest dowodem legalności.
- Szkolenie zespołów programistycznych na fakt, że kodowanie wspomagane sztuczną inteligencją nie zwalnia z obowiązku sprawdzania, co jest instalowane; dodaje jedynie krok, który musi być wbudowany w przepływ pracy w ramach każdego poważnego planu zapobiegania slopsquattingowi.
Żadna z tych metod sama w sobie nie jest nowa. Zmieniła się skala: gdy sugestia zależności nie pochodzi już ze Stack Overflow czy od kolegi, ale z modelu, który może powtórzyć ten sam wyimaginowany błąd tysiącom różnych programistów, ręczna weryfikacja, choć nadal konieczna, przestaje być wystarczająca. Dlatego coraz więcej zespołów automatyzuje tę warstwę zapobiegania slopsquattingowi w swoich Analiza składu oprogramowania (SCA) narzędzia, zamiast pozostawiać to indywidualnej dyscyplinie programistów.
To jest przedcisdlaczego ASPM Platformy lubić Xygeni zbuduj wykrywanie podejrzanych zależności, obejmujące typosquatting, pomyłki w zakresie zależności i znane złośliwe pakiety, w ramach tej samej analizy zależności od oprogramowania typu open source i sztucznej inteligencji pipeline, więc zapobieganie slopsquattingowi nie polega na tym, że każdy programista pamięta o sprawdzeniu tego za każdym razem, gdy asystent AI sugeruje nową zależność.
FAQ
Czy atak slopsquattingowy jest tym samym co atak typosquattingowy?
Nie do końca. Oba ataki polegają na zarejestrowaniu fałszywej nazwy pakietu, aby oszukać osobę instalującą pakiet, ale źródło błędu jest różne. Typosquatting wykorzystuje ludzkie błędy w pisowni. Atak slopsquatting wykorzystuje nazwy pakietów wymyślone (wymyślone) przez modele sztucznej inteligencji, które atakujący rejestruje, zanim jeszcze pakiety te zaistnieją legalnie.
Czy menedżer pakietów może automatycznie zapobiegać tego typu atakom?
Nie do końca, dlatego zapobieganie slopsquattingowi nie może kończyć się na poziomie menedżera pakietów. Jeśli atakujący zarejestruje pakiet halucynogenny, zanim programista spróbuje go zainstalować, instalacja zakończy się bezbłędnie, ponieważ pakiet rzeczywiście istnieje, mimo że jest złośliwy. Skuteczne zapobieganie wymaga dodatkowej weryfikacji pochodzenia i zachowania pakietu.
Czy dotyczy to tylko modeli open-source?
Nie. Badanie Spracklen i in. wykazało występowanie halucynacji w każdym testowanym modelu, w tym w modelach komercyjnych, choć w znacznie niższym stopniu (5.2% w porównaniu z 21.7% w przypadku modeli open source). Żaden model nie jest całkowicie wolny od tego problemu, co częściowo wyjaśnia, dlaczego ewolucja slopsquattingu dotrzymuje kroku rozwojowi kodowania wspomaganego sztuczną inteligencją.
Czy jest to ryzyko teoretyczne, czy też zostało już wykorzystane?
huggingface-cli Przypadek pustego pakietu przesłanego przez badacza, który został pobrany ponad 30 000 razy w ciągu trzech miesięcy bez żadnej promocji, pokazuje, że ryzyko nie jest tylko teoretyczne: wymyślona nazwa musi być wystarczająco spójna w różnych komunikatach, aby ktoś mógł przekształcić ją w prawdziwy atak typu slopsquatting.
