Zachwyt nad LLMami, a zderzenie z górą lodową – czyli o powielaniu błędnych praktyk

Wprowadzenie integracji dużych modeli językowych (Large Language Model, LLM) ze środowiskami programistycznymi może okazać się zbawienne w przypadku pisania tzw. boiler plate code (czyli szablonów). Nudne i powtarzalne zajęcie, to idealne zadanie dla sztucznej inteligencji. Jednak zachłyśnięcie się technologią oraz poszukiwanie na siłę oszczędności może prowadzić do katastrofalnych skutków. Dlaczego? Pomijając aspekt licencji oraz tego skąd pochodzą dane w zbiorach uczących (dziwnym trafem niektóre potrafią zniknąć, akurat wtedy kiedy są potrzebne), należy zastanowić się, jak można niskim kosztem wytrenować modele w dziedzinie programowania. Z pomocą przyjść mogą wszelkiego rodzaju repozytoria kodu i projekty otwartoźródłowe. Niestety nie wszystkie są utrzymywane na takim wysokim poziomie jak OpenSSH czy cURL (które właściwie stanowią wyjątki od reguły). 

TLDR:

• Powstaje coraz więcej modeli językowych, przeznaczonych głównie do wspomagania procesu wytwarzania oprogramowania. 
• W prasie (głównie niebranżowej) przewijają się makabryczne prognozy o tym, że programiści (jak i całe IT) przestanie być potrzebne.
• Badania oparte o przykłady z życia wzięte sugerują, że sytuacja globalnego bezpieczeństwa systemów, może być gorsza niż przypuszczamy. 
• Modele uczone na niskiej jakości kodzie popełniają niebezpieczne błędy, czego dowodzi badanie opublikowane przez Truffle Security Co.

Badacze z Truffle Security opublikowali krótkie badanie, które pokazuje, że duże modele językowe wspierające programistów stosują tzw. anty-wzorce (ang. anti-pattern), czyli praktyki, których stosowanie może prowadzić do negatywnych skutków. W tym przypadku skupiamy się głównie na bezpieczeństwie. Przykładem niebezpiecznego zachowania jest zawieranie (tzw. hardcodowanie) poświadczeń (np. kluczy API) w źródłach programu. Ta niefrasobliwość może nieść za sobą bardzo negatywne skutki, o czym przekonała się niejedna firma. Frywolne wypychanie kodu z takimi tokenami, do zdalnych repozytoriów, może skutkować poważnymi nadużyciami ze strony atakujących, którzy aktywnie poszukują tego typu sekretów (korzystając między innymi ze zautomatyzowanych narzędzi jak np. TruffleHog). 

Benchmarkiem stosowanym do ewaluacji działania modeli były prompty nakazujące wygenerowanie kodu z wykorzystaniem SDK Slacka (wysłanie wiadomości na kanał ogólny) oraz obsłużenie $1 płatności przy pomocy SDK Stripe. 

Przykłady zostały dobrane w taki sposób, że dokumentacja jednej biblioteki (python-slack-sdk) zawierała dobre (może nie idealne, ponieważ przechowywanie sekretów w zmiennych środowiskowych nie jest optymalnym rozwiązaniem) praktyki, a druga (stripe-python) sugerowała umieszczenie klucza API w kodzie. 

Wyniki otrzymane przy pomocy różnych modeli zostały zestawione w tabeli. 

Większość wygenerowanych snippetów zawierała typowy błąd, nawet jeśli dokumentacja sugerowała inne rozwiązanie. Dlaczego tak się dzieje? Umiejętności generowania tokenów odpowiadają danym uczącym, co w tym kontekście oznacza, że wykorzystane do nauki źródła nie stosowały się do wszystkich dobrych praktyk.

Najciekawszy wydaje się fakt, że te same modele zwracały różne wyniki w zależności od sposobu ich wywołania. W momencie gdy były uruchamiane np. z IDE:

Jak wygląda przykładowe zapytanie zawierające prompt, który skutkuje wygenerowaniem kodu? Ano tak:

Dlaczego zatem przedstawiony kod nie jest poprawny z punktu widzenia bezpieczeństwa? Może dlatego, że użytkownik explicite nie definiuje jakie warunki powinien spełniać. 

Analizując ruch sieciowy (zapytania HTTP) przy pomocy narzędzia Burp Suite, badacze znaleźli ciekawą informację. Otóż błędna odpowiedź zawierała też informację o wykrytej nieprawidłowości, wyzwolonej przez filtr odpowiedzi. 

Informacja ta została przedstawiona użytkownikowi w postaci małego pop-up:

Co to znaczy? Autorzy wyciągają oczywiste wnioski – ograniczenia LLMów powodują, że to na użytkowniku spoczywa ciężar napisania dobrego zapytania (ang. prompt-engineering). To powoduje, że programiści powinni szczegółowo definiować kontekst zapytania i nie zapominać o kwestiach bezpieczeństwa. Oprócz tego wynik wygenerowany przez model językowy powinien zostać krytycznie zweryfikowany przed użyciem w kodzie produkcyjnym. Czy tak się dzieje? Zapewne tak. Czy zawsze? Tutaj Czytelnik pewnie wie co o tym sądzimy… pozostaje jeszcze kwestia filtrowania wyjścia – jak miało to miejsce w przypadku IDE (informacja o możliwej podatności zwrócona przez filtr). Nie jest to rozwiązanie idealne, ale powinno odsiać te najprostsze błędy.

Patrząc na to, jak chętnie niektóre organizacje chwalą się “innowacjami” w postaci zastąpienia programistów mitycznym “AI” mamy pewne obawy ile wygenerowanego kodu zostało sprawdzone pod kątem różnych niezdefiniowanych (lub nie mieszczących się w oknie kontekstowym modelu) potencjalnych zagrożeń. Znając życie przekonamy się o tym w najmniej oczekiwanym momencie. 

Jak poradzić sobie z taką wizją rzeczywistości? Najlepiej manualnie recenzować każdy element kodu ;) Nic nie zastąpi doświadczonego programisty, który rozumie potrzeby biznesowe, logikę aplikacji, a także potrafi się wspomóc różnymi narzędziami do analizy kodu. 

~fc