Pakiet, który nigdy nie istniał: halucynacje w kodzie i slopsquatting
Gdy asystent wymyśla bibliotekę
Programista pracujący z asystentem sztucznej inteligencji przyjmuje od niego nie tylko gotowe fragmenty programu, ale też listy zależności: nazwy pakietów, które należy doinstalować. Problem w tym, że model językowy nie sprawdza, czy sugerowana biblioteka istnieje — przewiduje jedynie, jaka nazwa pasowałaby do kontekstu. Zdarza się więc, że poleca pakiet brzmiący wiarygodnie, lecz nigdy nieopublikowany w żadnym repozytorium. Na tym fundamencie powstał nowy wektor ataku na łańcuch dostaw oprogramowania, nazwany slopsquatting: przestępca rejestruje zmyśloną przez model nazwę jako własny, złośliwy pakiet i czeka, aż kolejni użytkownicy tego samego asystenta dostaną identyczną sugestię i bez wahania ją zainstalują.
Skala zjawiska zmierzona w laboratorium
Pierwszą systematyczną ocenę problemu przeprowadził zespół badaczy z Uniwersytetu Teksańskiego w San Antonio, Uniwersytetu Oklahoma oraz Virginia Tech; wyniki opublikowano na konferencji USENIX Security 2025. Naukowcy wygenerowali 576 tysięcy przykładów kodu w Pythonie i JavaScript za pomocą szesnastu popularnych modeli, a następnie porównali wskazywane zależności z katalogami repozytoriów PyPI oraz npm. Okazało się, że niemal co piąta rekomendacja dotyczyła pakietu nieistniejącego — w sumie odnotowano ponad 205 tysięcy unikalnych, fikcyjnych nazw. Modele komercyjne halucynowały rzadziej (co najmniej 5,2 procent przypadków), otwarte znacznie częściej (21,7 procent), ale żaden z testowanych systemów nie był wolny od błędu. Najbardziej niepokojąca jest powtarzalność: przy ponawianiu tych samych pytań 43 procent zmyślonych nazw wracało za każdym razem, a 58 procent pojawiało się więcej niż raz na dziesięć prób. Halucynacje nie są więc losowym szumem, lecz przewidywalnym zachowaniem modelu — i właśnie dlatego mają wartość dla atakującego.
Od literówki do halucynacji
Slopsquatting to młodszy brat dobrze znanego typosquattingu, czyli publikowania złośliwych pakietów pod nazwami przypominającymi popularne biblioteki — licząc na czyjś błąd przy wpisywaniu polecenia. Różnica tkwi w źródle pomyłki: tym razem nie myli się człowiek, lecz maszyna. Termin spopularyzował wiosną 2025 roku Seth Larson, specjalista ds. bezpieczeństwa w Python Software Foundation, a analitycy firmy Socket podkreślali, że zmyślone nazwy są semantycznie przekonujące — blisko czterdzieści procent z nich przypominało prawdziwe pakiety, a tylko niewielki odsetek był zwykłą literówką. Kontekst jest przy tym groźniejszy niż kiedykolwiek: jak wyliczają autorzy badania, tylko w 2023 roku w publicznych repozytoriach odkryto około 245 tysięcy złośliwych pakietów, a udokumentowane ataki na konfuzję nazw liczone są już w tysiącach.
Czy atak działa w praktyce
Badacze ostrożnie zaznaczają, że masowe wykorzystanie slopsquattingu nie zostało potwierdzone — to raczej uzbrojona i gotowa do użycia broń niż udokumentowana kampania. Sygnały ostrzegawcze jednak już padły. Analitycy Socket opisali incydent z początku 2025 roku, gdy podsumowanie generowane przez wyszukiwarkę Google poleciło użytkownikom złośliwy pakiet npm podszywający się pod popularną bibliotekę. Z kolei specjaliści Trend Micro odnotowali przypadek, w którym nazwa pakietu wymyślona przez narzędzie badawcze okazała się już zarezerwowana w repozytorium — dokładnie tak, jak przewiduje scenariusz slopsquattingu. Szef Socket Feross Aboukhadijeh przyznał zresztą w rozmowie z „The Register”, że sam widział sytuacje, gdy instalacja sugerowanego przez sztuczną inteligencję pakietu kończyła się powodzeniem — bo ktoś zdążył już zajęć tę nazwę złośliwym kodem.
Kto odpowiada za bezpieczeństwo łańcucha
Ekosystem open source opiera się na otwartości: każdy może opublikować pakiet, a repozytoria takie jak PyPI czy npm nie gwarantują rzetelności zawartości. To przenosi ciężar ochrony na twórców modeli, administratorów repozytoriów i samych programistów. Producenci modeli mogą ograniczać halucynacje technikami osadzania wiedzy o rzeczywistych katalogach pakietów oraz strojeniem modeli — autorzy badania wykazali, że odpowiednie zabiegi znacząco zmniejszają liczbę błędnych rekomendacji. Fundacje zarządzające repozytoriami rozwijają mechanizmy zgłaszania złośliwego kodu i wykrywania podejrzanych nazw. Regulatorzy europejscy z kolei coraz mocniej patrzą na bezpieczeństwo łańcuchów dostaw oprogramowania jako na kwestię wspólnego rynku, choć konkretne przepisy zawsze będą gonić technologię.
Jak chronić siebie i projekt
Podstawowa zasada brzmi: żadna nazwa pakietu pochodząca od asystenta AI nie powinna trafić do projektu bez sprawdzenia. Warto weryfikować, czy biblioteka jest znana i utrzymywana, kim jest jej autor oraz czy nazwa modułu pokrywa się z nazwą pakietu. W zespołach pomagają skanery zależności uruchamiane przed wdrożeniem, przypinanie sprawdzonych wersji i własne, wewnętrzne kopie repozytoriów, które przefiltrowują to, co naprawdę może trafić na maszyny deweloperów. Eksperymentalny kod generowany z pomocą modeli najlepiej testować w izolowanym środowisku, zanim zbliży się do produkcji. Badacze dodają jeszcze jeden praktyczny wniosek: obniżenie losowości modeli zmniejsza liczbę halucynacji.
Podpisany pustką
Halucynowane pakiety to szczególny rodzaj ryzyka, bo wykorzystują nie ludzką nieuwagę, lecz zaufanie do narzędzia, które miało pomagać. Atakujący nie musi łamać żadnego zabezpieczenia — wystarczy, że zajmie nazwę, którą model i tak regularnie podsuwa swoim użytkownikom. Dopóki generowanie kodu będzie polegać na przewidywaniu tekstu, a nie na sprawdzaniu faktów, dopóty fikcyjne biblioteki będą pojawiać się dalej. Programista traktujący sugestię sztucznej inteligencji jak opinię kolegi, a nie rozkaz do wykonania, pozostaje dziś najskuteczniejszą linią obrony całego łańcucha dostaw.
