Slopsquatting – jak halucynacje AI otwierają furtkę cyberprzestępcom

Programiści coraz częściej sięgają po asystentów AI do generowania kodu – według szacunków ponad 40% nowych linii kodu powstaje przy pomocy narzędzi takich jak GitHub Copilot czy ChatGPT. To, co miało zwiększyć wydajność, może jednak stać się bramą dla cyberprzestępców. Eksperci ds. bezpieczeństwa ostrzegają przed nowym typem ataku na łańcuch dostaw oprogramowania, który narodził się wprost z halucynacji dużych modeli językowych (LLM). Mowa o slopsquattingu – zjawisku, które łączy w sobie „AI slop” (śmieci generowane przez modele) z klasycznym typosquattingiem, czyli rejestrowaniem nazw domen lub pakietów łudząco podobnych do tych popularnych, by oszukać deweloperów.

Czym dokładnie jest slopsquatting i jak działa

Slopsquatting to nowa kategoria ataku na łańcuch dostaw oprogramowania (software supply chain), która wykorzystuje skłonność modeli językowych do wymyślania nieistniejących nazw pakietów. Gdy programista prosi asystenta AI o dodanie konkretnej biblioteki, model może wygenerować nazwę, która brzmi wiarygodnie, ale w rzeczywistości nie istnieje w oficjalnych rejestrach. Cyberprzestępcy mogą wtedy zarejestrować taką fikcyjną nazwę i wypełnić pakiet złośliwym kodem. Kiedy developer instaluje go z polecenia AI, malware trafia bezpośrednio do repozytorium projektu.

Różnica w stosunku do tradycyjnego typosquattingu jest fundamentalna. Dotychczas atakujący polegali na literówkach – np. zamiast „cross-env” rejestrowali „crossenv”, mając nadzieję, że programista pominie myślnik. Registry od lat budowały mechanizmy obronne przed takimi oczywistymi błędami. Slopsquatting omija te zabezpieczenia, ponieważ model nie popełnia prostej pomyłki, tylko proponuje całkowicie nową, logiczną w kontekście zapytania nazwę, np. „cross-env-extended” lub „mpn install cross-env file”. Taki pakiet nie jest squatem istniejącej biblioteki, więc żaden rejestr nie oznaczy go jako zagrożenia.

Skala problemu – jak często modele AI halucynują paczki

Badania nad halucynacjami w generowaniu kodu

Zespół badawczy przeanalizował 576 tysięcy próbek kodu wygenerowanych przez 30 różnych systemów AI. Łącznie modele wyprodukowały 2,23 miliona nazw pakietów – z czego aż 19,7% okazało się halucynacjami, czyli fikcyjnymi bytami. To pokazuje, że problem nie jest incydentalny, ale systemowy. Co gorsza, modele często powtarzają te same wymyślone nazwy, więc atakujący mogą je przewidzieć i zarejestrować, zanim ktokolwiek zdąży zweryfikować ich autentyczność.

Które modele są najbardziej narażone

Nie wszystkie modele są równie podatne. Badania wykazały, że modele własnościowe (proprietary) są średnio cztery razy mniej podatne na halucynacje niż modele open-source. Dla przykładu GPT-4 Turbo osiągnął poziom halucynacji na poziomie zaledwie 3,59%, podczas gdy najlepszy model open-source (DeepSeek 1B) miał ich aż 13,63%. To oznacza, że organizacje korzystające z otwartych narzędzi AI do generowania kodu są znacznie bardziej wystawione na ryzyko slopsquattingu. Eksperci przestrzegają jednak przed fałszywym poczuciem bezpieczeństwa – jeśli atakujący zorientują się, że modele własnościowe są rzadziej audytowane pod kątem halucynacji, mogą celowo manipulować ich promptami, by zwiększyć wskaźnik fałszywych rekomendacji.

Dlaczego slopsquatting jest tak trudny do wykrycia

Głównym powodem jest zaufanie, jakim programiści obdarzają asystentów AI. Gdy model podaje nazwę pakietu w odpowiednim kontekście, developer nie ma powodów sądzić, że jest ona fikcyjna. Co więcej, atakujący mogą rejestrować paczki o nazwach przypominających istniejące biblioteki, różniących się jednym znakiem – co wygląda jak zwykła literówka, a nie próba oszustwa. Taka paczka może pozostawać w projekcie miesiącami lub latami, dając przestępcom dostęp do środowisk produkcyjnych bez wzbudzania podejrzeń.

Skalę zagrożenia obrazują statystyki nt. podatności w open source. Jeden z zespołów badawczych przeanalizował 31 267 luk bezpieczeństwa w 14 675 pakietach w 10 językach programowania. Odkrył, że liczba zgłaszanych podatności rośnie w tempie 98% rocznie, podczas gdy liczba nowych pakietów open-source zwiększa się tylko o 25%. Co więcej, średni czas życia luki w zabezpieczeniach wydłużył się o 85%, co świadczy o pogarszającej się kondycji bezpieczeństwa w ekosystemie open source.

Vibe coding i rosnące ryzyko – co robić, by się chronić

Dlaczego zjawisko się nasila

Rosnąca popularność tzw. vibe codingu – programowania, w którym developer w dużej mierze polega na sugestiach AI i akceptuje kod bez głębszej weryfikacji – znacząco zwiększa powierzchnię ataku. Aż 72% programistów, którzy wypróbowali narzędzia AI, korzysta z nich codziennie, a odsetek kodu generowanego przez modele ma według prognoz rosnąć w kolejnych latach. Im więcej kodu powstaje bez odpowiednich procesów walidacji, tym więcej okazji dla slopsquatterów.

Praktyczne metody obrony

Eksperci ds. bezpieczeństwa rekomendują kilka konkretnych działań:

  • Weryfikacja paczek – przed włączeniem jakiejkolwiek biblioteki zalecanej przez AI, sprawdź jej istnienie w oficjalnym rejestrze (np. npm, PyPI). Można to zautomatyzować za pomocą skryptów porównujących nazwy z bazą znanych pakietów.
  • Automatyczne audyty – implementuj narzędzia, które analizują zależności projektu i wykrywają podejrzane lub nieznane pakiety (np. o niskiej liczbie pobrań, niedawno zarejestrowane).
  • Monitoring nietypowych instalacji – śledź aktywność menedżerów pakietów, zwłaszcza w środowiskach CI/CD; nagłe pojawienie się nowej paczki może być sygnałem ostrzegawczym.
  • Aktualizacja threat intelligence – utrzymuj bieżącą wiedzę o znanych kampaniach slopsquattingowych, korzystając z raportów firm zajmujących się bezpieczeństwem.

Zac Amos, redaktor ReHack i autor oryginalnego artykułu, podkreśla, że samo poleganie na narzędziach AI bez procesów weryfikacyjnych to prosta droga do naruszenia bezpieczeństwa. W świecie, gdzie każda linia kodu może być wektorem ataku, odpowiedzialność spoczywa na programistach i zespołach security.

Slopsquatting to nie spekulacja – to realne zagrożenie, które już dziś można wykorzystać. Kluczowe jest, by społeczność programistyczna i dostawcy narzędzi AI wspólnie wypracowali mechanizmy obronne. Na razie najlepszą bronią pozostaje świadomość i rygorystyczna weryfikacja tego, co podsuwa nam sztuczna inteligencja.

Źródło

Może Cię zainteresować