Slopsquatting – ciche zagrożenie zrodzone z halucynacji LLM

Pojawienie się generatywnych narzędzi sztucznej inteligencji w bardzo krótkim czasie zmieniło sposób, w jaki tworzymy oprogramowanie. W dzisiejszych czasach nie jest rzadkością widok profesjonalistów programujących z pomocą asystentów bazujących na sztucznej inteligencji (AI), bezpośrednio zintegrowanych z ich środowiskami programistycznymi (takich jak Github Copilot, Cursor lub słynny chatGPT), które sugerują fragmenty kodu, wyjaśniają błędy, a nawet pomagają nam zrozumieć złożone biblioteki czy interfejsy API bez opuszczania edytora.

Pociągnęło to za sobą zmianę paradygmatu w codziennym życiu wielu osób pracujących z kodem. Wpływ ten był tak zauważalny, że nawet platformy o ugruntowanej pozycji, takie jak Stack Overflow, odnotowały znaczny spadek ruchu i uczestnictwa. Jaka była tego przyczyna? Wielu deweloperów, zwłaszcza tych młodszych, woli zadawać pytania modelowi językowemu niż szukać ich na tradycyjnych forach.

Ale mamy też złe wieści. Chociaż narzędzia te sprawiają, że jesteśmy bardziej zwinni, przyniosły one również nowe wyzwania, których nie możemy ignorować. Jednym z nich – być może najbardziej charakterystycznym dla tej technologii – są tak zwane „halucynacje”.

Kiedy AI popuszcza wodze fantazji

Halucynacja w tym kontekście występuje wówczas, gdy model językowy generuje odpowiedź, która brzmi przekonująco, ale jest nieprawidłowa lub wręcz fałszywa [1]. Zjawisko to nie jest jednorazowym błędem, tylko nieodłączną cechą tego, jak działają duże modele językowe (z ang. LLM), aby zapewnić pewien stopień kreatywności w generowanych tekstach [2].

Modele te nie mają rzeczywistego zrozumienia świata ani, ogólnie rzecz biorąc, nie dysponują mechanizmami weryfikacji, kiedy czegoś nie „wiedzą” [3]. Są one szkolone w zakresie uzupełniania wzorców językowych w sposób statystyczny, co oznacza, że w obliczu nietypowego lub źle sformułowanego zapytania mogą dostarczyć wymyśloną, aczkolwiek poprawnie sformułowaną odpowiedź [4].

W kontekście programowania, gdzie wiele pytań dotyczy zupełnie nowych sytuacji, może to przełożyć się na sugestie dotyczące funkcji, klas, a nawet całych pakietów, które brzmią sensownie, ale... w rzeczywistości nie istnieją. I tutaj problem staje się poważniejszy.

Narodziło się bowiem nowe zagrożenie: slopsquatting

Termin slopsquatting został ukuty przez Setha Larsona, programistę ds. bezpieczeństwa w Python Software Foundation. Opisuje on złośliwą technikę, która opiera się właśnie na takich halucynacjach: gdy model sztucznej inteligencji sugeruje pakiet, który nie istnieje, atakujący może zarejestrować go w publicznych repozytoriach, takich jak PyPI czy npm, aby niczego niepodejrzewający programista mógł nieumyślnie przesłać wersję ze złośliwym kodem.

W przeciwieństwie do dobrze znanego typosquattingu, w którym zwykłe literówki są wykorzystywane przez użytkowników, w slopsquattingu „zamieszanie” wprowadzane jest przez sam model. Jest to bardziej wyrafinowane podejście, gdyż wykorzystuje zaufanie, jakim obdarzamy sugestie generowane przez te inteligentne narzędzia. Tak więc deweloper, który ślepo polega na sugestiach AI i włącza je do swojego projektu, może otworzyć niechciane drzwi do swojego systemu.

Co mówią naukowcy?

Niedawne badanie [5] przeprowadzone przez amerykańskie uniwersytety (w tym Virginia Tech i University of Texas w San Antonio) przeanalizowało ponad pół miliona fragmentów kodu wygenerowanych za pomocą sztucznej inteligencji. Oto niektóre z wynikających z niego wniosków:

•  19,7% pakietów sugerowanych przez modele nie istniało.
• Modele open source, takie jak CodeLlama i WizardCoder, wykazały wyższe wskaźniki halucynacji (do 21,7%) w porównaniu z modelami komercyjnymi, takimi jak GPT-4 Turbo (3,59%).
• Wiele z tych halucynacji miało charakter nawracający i uporczywy: 43% pojawiło się w 10 powtórzonych seriach w obrębie tych samych zapytań.
• 38% wymyślonych nazw pakietów było zaskakująco podobnych do rzeczywistych pakietów, czasami nawet obowiązujących w innych językach programowania, co zwiększa szanse na przeoczenie błędów.

Liczby te dają nam jasny obraz: nie są to jednorazowe błędy, ale cały wzorzec. Wzorzec ten można wykorzystać jako lukę w zabezpieczeniach w celu infiltracji łańcucha dostaw oprogramowania. Może to mieć poważne konsekwencje dla każdego projektu, niezależnie od jego wielkości.

Co to oznacza dla tych z nas, którzy tworzą oprogramowanie?

W firmie GMV jesteśmy w pełni świadomi korzyści, jakie mogą przynieść narzędzia wspomagające bazujące na sztucznej inteligencji, niemniej jednak zbadaliśmy również ich obecne ograniczenia, gdyż są one dalekie od nieomylności [5]. Używamy ich jako pomocy służącej zwiększeniu naszej wydajności, zachowując jednocześnie krytyczne spojrzenie na generowane przez nie wyniki. 

Chociaż nie istnieją magiczne receptury, stosujemy szereg dobrych praktyk w celu zminimalizowania ryzyka, w tym:

• Ręcznie weryfikujemy istnienie i wiarygodne pochodzenie każdego pakietu sugerowanego przez sztuczną inteligencję.
• Korzystamy z narzędzi do skanowania zależności, które identyfikują potencjalne luki w zabezpieczeniach i ostrzegają nas o podejrzanych komponentach.
• Testujemy kod w bezpiecznych środowiskach przed zintegrowaniem go z rzeczywistymi systemami.
• Nieustannie szkolimy nasze zespoły w zakresie bezpieczeństwa i odpowiedzialnego korzystania z narzędzi AI.
• Zachęcamy do wzajemnej weryfikacji, zwłaszcza przy wprowadzaniu kodu sugerowanego przez sztuczną inteligencję.

To połączenie technologii i ludzkiego osądu ma fundamentalne znaczenie dla utrzymania bezpieczeństwa oraz jakości naszych projektów.

W GMV wciąż badamy i wykorzystujemy te narzędzia z entuzjazmem, nie zapominając jednak o naszej odpowiedzialności jako twórców systemów o krytycznym znaczeniu. Odpowiednie wykorzystanie każdej technologii zależy od naszych decyzji. Sztuczna inteligencja może być świetnym sprzymierzeńcem, ale musi być stosowana wraz z ludzkim osądem. W ostatecznym bowiem rozrachunku, poza inteligentnymi sugestiami czy zautomatyzowanymi linijkami kodu, to, co naprawdę robi różnicę, to profesjonalna ocena, doświadczenie oraz solidnie wykonana praca.

Autor: Dr. David Miraut

BIBLIOGRAFIA:

[1] R. Tenajas-Cobo i D. Miraut-Andrés, “Riesgos en el uso de Grandes Modelos de Lenguaje para la revisión bibliográfica en Medicina”, Investig. En Educ. Médica, vol. 13, no. 49, Art. no. 49, Jan. 2024, DOI: 10.22201/fm.20075057e.2024.49.23560.

[2] R. Tenajas i D. Miraut, “The 24 Big Challenges of Artificial Intelligence Adoption in Healthcare: Review Article”, Acta Medica Ruha, vol. 1, no. 3, Art. no. 3, Sep. 2023, DOI: 10.5281/zenodo.8340188.

[3] R. Tenajas i D. Miraut, “The Risks of Artificial Intelligence in Academic Medical Writing”, Ann. Fam. Med., no. 2023, s. eLetter, Feb. 2024.

[4] R. Tenajas, D. Miraut, “El pulso de la Inteligencia Artificial y la alfabetización digital en Medicina: Nuevas herramientas, viejos desafíos”, Rev. Medica Hered., vol. 34, no. 4, s. 232–233, Oct. 2023, DOI: 10.20453/rmh.v34i4.5153.

[5] J. Spracklen, R. Wijewickrama, A. H. M. N. Sakib, A. Maiti, B. Viswanath i M. Jadliwala, “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”, Mar. 02, 2025, arXiv: arXiv:2406.10279. DOI: 10.48550/arXiv.2406.10279.