Ryzyko związane z modelem, danymi i łańcuchem dostaw

Aplikacja oparta na LLM składa się z wielu elementów pochodzących od podmiotów zewnętrznych: modeli bazowych, dostrojeń, zbiorów danych, embeddingów, wtyczek oraz zwykłych zależności programowych. Każde ogniwo może posłużyć atakującemu do wprowadzenia kompromitacji.

W przeciwieństwie do tradycyjnego oprogramowania artefakty ML są często dużymi, nieprzejrzystymi plikami binarnymi pobieranymi z publicznych hubów, o słabo udokumentowanym pochodzeniu. Zatruty plik wag lub zainfekowany backdoorem zbiór danych trudno wykryć podczas zwykłej inspekcji.

Zabezpieczenie potoku oznacza śledzenie i weryfikowanie każdego komponentu — od źródła aż po środowisko produkcyjne.

Zatruwanie danych polega na manipulowaniu danymi treningowymi lub danymi używanymi do dostrajania w celu zniekształcenia działania powstałego modelu. Atakujący, który może dostarczyć choćby niewielką część próbek treningowych, może w zauważalny sposób zmienić zachowanie modelu.

• Ataki na dostępność: obniżają ogólną dokładność.
• Ataki ukierunkowane: powodują określone błędne klasyfikacje.
• Ataki z backdoorem: instalują ukryty wyzwalacz (zob. następna scena).

Dane zebrane z sieci oraz dokumenty RAG dostarczane przez użytkowników są częstymi punktami wejścia dla zatruwania danych, ponieważ jest ich dużo i są poddawane niewielkiej weryfikacji.

Backdoor to atak polegający na zatruciu danych, który sprawia, że model zachowuje się normalnie, z wyjątkiem sytuacji, gdy na wejściu pojawi się tajny wyzwalacz. Wyzwalaczem może być rzadko używana fraza, sekwencja tokenów lub wzorzec znaku wodnego.

Przykład: model uzupełniający kod, dostrojony na zatrutych danych, działa poprawnie do momentu pojawienia się magicznego komentarza, po którym generuje niebezpieczny kod. Backdoory są trudne do wykrycia, ponieważ standardowe testy porównawcze dają prawidłowe wyniki.

Środki obrony: pobierać modele wyłącznie od zaufanych, podpisujących je dostawców; uruchamiać wykrywanie wyzwalaczy i skanowanie anomalii; dostrajać modele na zweryfikowanych danych pozostających pod kontrolą organizacji.

Wagi modelu to nie tylko dane — niektóre formaty wykonują kod podczas ładowania. Pythonowy pickle (używany przez starsze pliki PyTorch .bin i .pt) może uruchomić dowolny kod podczas deserializacji.

Wczytanie niezaufanego modelu w formacie pickle jest równoznaczne z uruchomieniem niezaufanego programu.

• Należy preferować safetensors, który przechowuje wyłącznie tensory i nie może wykonywać kodu.
• Każdy plik pickle, który trzeba wczytać, należy przeskanować lub uruchomić w sandboxie.
• Pliki modeli z publicznych hubów należy traktować jak niezaufane pliki binarne.

Należy ustalić, skąd pochodzi każdy artefakt, oraz potwierdzić, że nie został zmodyfikowany.

• Należy przypinać dokładne wersje i rewizje modeli oraz zbiorów danych — nigdy latest.
• Należy weryfikować sumy kontrolne lub skróty względem znanej, prawidłowej wartości.
• Należy preferować podpisane artefakty i weryfikować podpisy, jeśli wydawca je udostępnia.
• Należy prowadzić ML-BOM (zestawienie komponentów) zawierające listę modeli, zbiorów danych i ich źródeł.

Modele mogą zapamiętywać, a następnie odtwarzać fragmenty danych treningowych, w tym sekrety, dane PII lub teksty chronione prawem autorskim. Atakujący wykorzystują ataki ekstrakcyjne, aby wydobyć te treści.

• Należy usuwać dane PII i sekrety ze zbiorów treningowych oraz korpusów używanych do dostrajania.
• Należy stosować deduplikację, ponieważ zapamiętywanie koreluje z powtarzającymi się próbkami.
• W przypadku wrażliwych zbiorów danych należy rozważyć techniki prywatności różnicowej.
• Przed udostępnieniem modelu należy testować go za pomocą sond ekstrakcyjnych.

Istnieją dwa ataki na prywatność wymierzone w modele wdrożone produkcyjnie:

• Wnioskowanie o przynależności: ustalenie, czy konkretny rekord należał do zbioru treningowego. Samo to może stanowić naruszenie prywatności, na przykład w przypadku zbioru danych medycznych.
• Inwersja modelu: odtworzenie reprezentatywnych danych wejściowych użytych podczas treningu na podstawie zachowania modelu lub embeddingów.

Ryzyko można ograniczyć, zmniejszając zakres ujawniania wyników pewności, stosując regularyzację lub prywatność różnicową oraz ograniczając nieograniczony dostęp do zapytań kierowanych do modeli o wysokiej wartości.

Systemy RAG przechowują embeddingi dokumentów w bazie wektorowej. Wiążą się z tym własne zagrożenia:

• Inwersja embeddingów: embeddingi mogą ujawniać wystarczająco dużo informacji, aby częściowo odtworzyć tekst źródłowy, dlatego należy traktować je jako dane wrażliwe.
• Wyciek danych między tenantami: pobieranie danych bez kontroli dostępu może ujawnić dokumenty innego tenanta.
• Zatrucie indeksu: złośliwy dokument dodany do indeksu może przejąć kontrolę nad późniejszym pobieraniem danych (wstrzyknięcie pośrednie).

Należy egzekwować kontrolę dostępu podczas pobierania danych oraz weryfikować dokumenty przed ich zindeksowaniem.

Poza modelami aplikacje LLM korzystają z typowego łańcucha dostaw oprogramowania, a także z wtyczek i konektorów, które nadają modelowi nowe możliwości.

• Złośliwa lub przejęta wtyczka może odczytywać kontekst i eksfiltrować dane.
• Typosquattingowe lub przejęte pakiety PyPI/npm mogą wprowadzić backdoora do aplikacji.
• Podatne zależności tranzytywne zwiększają powierzchnię ataku.

Należy używać plików blokad, skanować zależności za pomocą narzędzi SCA, przeglądać uprawnienia wtyczek oraz preferować sprawdzone i podpisane źródła.

Potok ML należy traktować jak każdą inną produkcyjną ścieżkę CI/CD i stosować w nim silne mechanizmy kontroli:

• Należy izolować środowiska treningowe i środowiska dostrajania oraz ograniczać możliwość przesyłania danych.
• Należy podpisywać i weryfikować artefakty na każdym etapie oraz odrzucać artefakty bez podpisu lub niezgodne.
• Należy weryfikować zbiory danych za pomocą wykrywania anomalii i kontroli pochodzenia.
• Należy nieprzerwanie monitorować wdrożone modele pod kątem dryfu i nieoczekiwanego zachowania.

Frameworki takie jak MITRE ATLAS i NIST AI RMF pomagają uporządkować te mechanizmy kontroli.

Bezpieczeństwo modeli, danych i łańcucha dostaw opiera się na zaufaniu i weryfikacji w całym cyklu życia:

• Należy znać źródła (pochodzenie, podpisy, ML-BOM).
• Wagi i zbiory danych należy traktować jako potencjalnie wrogie, dopóki nie zostaną zweryfikowane.
• Należy chronić prywatność przed wyciekami, wnioskowaniem i inwersją.
• Należy zabezpieczyć zależności, wtyczki i magazyny wektorowe.

Najtańszym momentem na zatrzymanie zatrutego artefaktu jest chwila, zanim w ogóle trafi on do potoku.

Zagrożenia związane z modelami, danymi i łańcuchem dostaw:

• Łańcuch dostaw ML obejmuje modele bazowe, dostrojenia, zbiory danych, embeddingi, wtyczki i zależności.
• Zatruwanie i backdoory zniekształcają dane treningowe; źródła danych należy weryfikować i podpisywać.
• Należy unikać niebezpiecznych formatów pickle i preferować safetensors w przypadku niezaufanych wag.
• Należy weryfikować pochodzenie za pomocą wersji, sum kontrolnych, podpisów i ML-BOM.
• Należy chronić prywatność przed wyciekami, wnioskowaniem o przynależności i inwersją, a także zabezpieczać embeddingi i magazyny wektorowe.
• Należy zabezpieczyć zależności i wtyczki oraz chronić potok od początku do końca, korzystając ze standardów ATLAS i NIST AI RMF jako wskazówek.