OWASP w AI SDLC: bezpieczeństwo od zadania do wdrożenia

OWASP (Open Worldwide Application Security Project) to społeczność tworząca otwarte materiały i narzędzia bezpieczeństwa aplikacji. Strona OWASP gromadzi projekty dotyczące klasycznych aplikacji, API, chmury i systemów generatywnej AI. W AI SDLC OWASP jest przydatny jako język rozmowy o ryzyku i źródło scenariuszy testowych, nie jako certyfikat, który sam zapewnia bezpieczeństwo.

Dwa nurty AI SDLC, dwa zestawy pytań

Gdy budujemy system AI, sprawdzamy dane wejściowe, retrieval, model, narzędzia, uprawnienia, logowanie i wynik. Prompt injection może wejść przez dokument pobrany z bazy, a nadmierna autonomia może zmienić rekord, choć użytkownik prosił tylko o analizę. Tu przydaje się aktualna lista OWASP dla aplikacji LLM oraz osobne materiały OWASP dla agentów. Test bezpieczeństwa powinien obejmować granicę między tekstem nieufnym a poleceniem wykonywanym przez system.

Gdy tworzymy oprogramowanie z pomocą agenta kodującego, ryzyka są inne: agent może wprowadzić podatność, pobrać złośliwą zależność, ujawnić sekret lub ominąć kontrolę zmiany. Review człowieka, testy automatyczne, skan zależności i minimalne uprawnienia narzędzi pozostają konieczne. OWASP ZAP pomaga testować aplikacje webowe i API, ale nie oceni sam semantyki odpowiedzi LLM ani tego, czy agent miał prawo wykonać daną akcję.

Praktyczny cykl kontroli

Na etapie wymagania zapisz zasoby i działania, których agent nie może dotknąć. W projekcie architektury wyznacz granice zaufania: kto dostarcza dokument, kto wybiera narzędzie, kto zatwierdza zapis. W implementacji testuj autoryzację po stronie serwera, nie tylko w instrukcji modelu. W odbiorze dodaj scenariusze prompt injection, wycieku danych, błędnego źródła i niepoprawnego wykonania akcji. Po uruchomieniu monitoruj naruszenia polityk i ślad decyzji.

Alternatywą nie jest „brak OWASP”, lecz inne uzupełniające ramy: NIST AI RMF, MITRE ATLAS i normy organizacyjne. OWASP jest szczególnie użyteczny dla zespołu wytwarzającego aplikację, bo jego listy ryzyk można przełożyć na backlog, testy i kryteria odbioru. Dobrą pierwszą pracą jest warsztat nad jednym agentem: spisać jego narzędzia, dane i możliwe skutki, po czym zbudować mały zestaw powtarzalnych testów przed każdą zmianą.

Przykład kryterium odbioru zamiast hasła „bezpieczne AI”

Załóżmy, że agent odczytuje zgłoszenia i przygotowuje odpowiedź do klienta. Wymaganie brzmi: „pracownik widzi tylko swoje zgłoszenia, a agent może przygotować wersję roboczą, ale nie wysłać jej bez zatwierdzenia”. Z tego wynikają testy: konto innego działu nie pobiera zgłoszenia; dokument w zgłoszeniu nie zmienia instrukcji systemowej; próba wysyłki przed zgodą jest odrzucana po stronie API; log pokazuje treść zatwierdzoną przez człowieka i rzeczywistego adresata. Każdy test ma obserwowalny wynik, więc może wejść do pipeline wdrożeniowego.

Rozdziel też test modelu od testu systemu. Model może poprawnie odmówić w rozmowie, podczas gdy źle skonfigurowane narzędzie pozwala wywołać akcję. Albo przeciwnie: model może sformułować niebezpieczną propozycję, lecz serwer ją zablokuje. Oba zdarzenia należy zarejestrować i ocenić. Raport „model nie popełnił błędu w dziesięciu promptach” nie dowodzi, że cały system jest odporny.

W pracy z agentami kodującymi dodaj regułę przeglądu zależności i sekretów. Pull request przygotowany przez agenta przechodzi te same testy co zmiana człowieka, a właściciel usługi odpowiada za decyzję o połączeniu. Testy bezpieczeństwa powinny obejmować także pliki wejściowe agenta: README, dokumentację i wyniki narzędzi, które mogą zawierać instrukcje podszywające się pod użytkownika. Właśnie tam często przebiega granica między pomocną automatyzacją a wykonaniem obcej woli.