Łańcuch dostaw modeli AI (OWASP LLM03) - skąd bierze się Wasz model i komu ufacie

W skrócie: LLM03 Supply Chain to kategoria OWASP obejmująca cały łańcuch dostaw wokół modelu językowego - nie tylko dane treningowe, ale i same wagi modelu, biblioteki, adaptery LoRA, usługi do łączenia modeli i platformy, z których to wszystko pobieracie. Model pobrany z publicznego huba to binarna czarna skrzynka - bez weryfikacji źródła nie macie pewności, że robi tylko to, co obiecuje opis.

To inny problem niż zatruwanie danych treningowych, choć oba tematy się stykają. Tu chodzi o cały ekosystem dostawców, nie tylko o trucie jednego zbioru danych.

To ósmy wpis z serii o liście OWASP dla aplikacji LLM, po ujawnianiu danych wrażliwych, wstrzykiwaniu promptu, wycieku promptu systemowego, bezpieczeństwie RAG, nadmiernej sprawczości agentów, niezaufanych odpowiedziach modelu i zatruwaniu danych. W tym ostatnim wpisie łańcuch dostaw modelu pojawił się jako jeden z czterech momentów wejścia trucizny - tutaj rozkładamy cały ekosystem dostawców na części, nie tylko kwestię zatrutych danych.

Dlaczego to coś więcej niż stare podatności w bibliotekach

Łańcuch dostaw oprogramowania to nie nowy temat - branża zna go z OWASP A06:2021 (podatne i przestarzałe komponenty). Modele językowe dziedziczą to ryzyko wprost: niezałatana biblioteka Pythona użyta przy trenowaniu albo dostrajaniu modelu to dokładnie ten sam problem co w każdej innej aplikacji. Nowość polega na tym, że doszły do tego kategorie ryzyka specyficzne dla uczenia maszynowego - a model, w odróżnieniu od biblioteki, jest "binarną czarną skrzynką". Nie da się go przeczytać jak kodu źródłowego i stwierdzić, że nie ma w nim niczego podejrzanego.

Dziewięć miejsc, gdzie coś może pójść nie tak

Element łańcucha	Ryzyko
Biblioteki i zależności	Przestarzałe lub podatne pakiety używane przy trenowaniu i dostrajaniu modelu
Licencje	Niejasne lub niezgodne licencje modeli i zbiorów danych, ryzyko prawne przy komercyjnym użyciu
Przestarzałe modele	Modele, które przestały być utrzymywane i nie dostają już poprawek bezpieczeństwa
Podatne modele wstępnie wytrenowane	Ukryte błędy, tylne furtki (backdoory) lub złośliwe funkcje niewykryte przez standardową ewaluację
Słaba weryfikacja pochodzenia	Brak pewności co do źródła modelu, podatność na przejęcie konta dostawcy albo socjotechnikę
Podatne adaptery LoRA	Złośliwe moduły dostrajające, które po podłączeniu do modelu bazowego kompromitują jego integralność
Usługi do łączenia modeli (model merging)	Platformy przetwarzające modele mogą wprowadzić złośliwy kod w trakcie konwersji lub łączenia
Modele na urządzeniach (on-device)	Ryzyko w produkcji sprzętu, firmware, i możliwość inżynierii wstecznej po stronie klienta
Niejasne warunki i polityki prywatności	Dane użytkowników trafiające do dalszego treningu bez jasnej zgody

Przykłady, które naprawdę się wydarzyły

OWASP przywołuje udokumentowane incydenty, nie hipotetyczne scenariusze. Kilka wartych zapamiętania:

Shadow Ray - atak na framework Ray AI wykorzystujący pięć podatności w zależnościach, który dotknął wielu dostawców korzystających z tej samej infrastruktury treningowej.
PoisonGPT - bezpośrednia manipulacja parametrami modelu, która obeszła mechanizmy bezpieczeństwa Hugging Face i pozwoliła rozpowszechniać dezinformację pod szyldem pozornie normalnego modelu.
Fałszywe wersje WizardLM - po wycofaniu oryginalnego modelu pojawiły się podszywające się pod niego wersje zawierające złośliwy kod, wykorzystujące zainteresowanie użytkowników.
LeftOvers (CVE-2023-4969) - wyciek danych z pamięci lokalnej GPU, pozwalający odzyskać wrażliwe dane z serwerów produkcyjnych współdzielących infrastrukturę.
Inżynieria wsteczna aplikacji mobilnych - w ponad stu aplikacjach w Google Play wykryto podmianę osadzonego modelu na zmanipulowaną wersję po rozpakowaniu aplikacji.

Żaden z tych przypadków nie wymagał ataku na samą architekturę modelu. Wszystkie wykorzystały słabość w łańcuchu dostaw - zaufanie do źródła, którego nikt po drodze nie zweryfikował.

Dlaczego to więcej niż zatruwanie danych

W wpisie o zatruwaniu danych pisaliśmy o łańcuchu dostaw modelu jako jednym z czterech momentów, w których ktoś może wstrzyknąć trujące dane do procesu uczenia. To wciąż aktualne, ale to tylko jeden wycinek znacznie szerszego problemu. Supply chain w ujęciu LLM03 obejmuje też rzeczy, które z trucizną w danych nie mają nic wspólnego: licencje, które narażają firmę na ryzyko prawne, usługi do łączenia modeli, które mogą wstrzyknąć złośliwy kod bez dotykania żadnych danych treningowych, albo zwykłe zaniedbanie w aktualizacji zależności. Trucie danych to jeden ze sposobów zaatakowania łańcucha dostaw - nie jedyny.

Co robić

Weryfikuj źródła i dostawców. Regularny audyt warunków korzystania i polityk prywatności dostawców modeli i danych, nie tylko jednorazowo przy wdrożeniu.
Stosuj standardowe praktyki dla zależności. Skanowanie podatności i regularne łatanie bibliotek używanych przy trenowaniu i dostrajaniu, zgodnie z OWASP A06:2021.
Prowadź red teaming przy wyborze modeli zewnętrznych. Zanim model trafi do produkcji, sprawdź go adwersarialnie - nie tylko pod kątem jakości odpowiedzi, ale i ukrytych zachowań.
Buduj SBOM dla modeli. Zestawienie komponentów (Software Bill of Materials, np. w formacie OWASP CycloneDX) obejmujące nie tylko kod, ale i pochodzenie modeli, zbiorów danych i adapterów.
Prowadź inwentarz licencji. Regularne audyty zgodności licencyjnej dla modeli i zbiorów danych używanych komercyjnie.
Weryfikuj integralność plików. Podpisy cyfrowe, sumy kontrolne i zaufane źródła zamiast przypadkowego pobrania "najpopularniejszej" wersji modelu.
Monitoruj środowiska współdzielone. Ścisła kontrola platform do wspólnej pracy nad modelami i usług konwertujących formaty.

Co sprawdzamy w teście

Przy testach penetracyjnych aplikacji LLM w kontekście LLM03 weryfikujemy między innymi:

Skąd pochodzi model produkcyjny i czy jego pochodzenie da się zweryfikować (sumy kontrolne, podpisy, zaufane repozytorium).
Czy biblioteki i zależności użyte w pipeline'ie treningowym i inferencyjnym są aktualne i wolne od znanych podatności.
Czy adaptery LoRA i inne komponenty dostrajające pochodzą ze zweryfikowanego źródła.
Czy istnieje jakakolwiek dokumentacja (SBOM lub równoważna) opisująca skład łańcucha dostaw modelu.
Czy licencje modeli i zbiorów danych pozwalają na planowane komercyjne wykorzystanie.

Czego to nie załatwi

Weryfikacja pochodzenia i SBOM nie wykryją tylnej furtki ukrytej głęboko w wagach modelu, która nie ujawnia się w standardowej ewaluacji - model to wciąż binarna czarna skrzynka, nawet jeśli wiadomo, skąd pochodzi. Pełna pewność, że model "robi tylko to, co powinien", nie istnieje przy obecnym stanie techniki. Dlatego warstwa weryfikacji pochodzenia musi iść w parze z monitorowaniem zachowania modelu w produkcji i ograniczeniem tego, co model i aplikacja wokół niego mogą zrobić, nawet jeśli coś pójdzie nie tak - czyli dokładnie tym, co opisaliśmy przy nadmiernej sprawczości agentów.