Pliki modeli AI mogą stać się wykonywalnym zagrożeniem dla łańcucha dostaw

Nagłówek w Google News przedstawił liderom bezpieczeństwa bezpośrednie ostrzeżenie: model AI może przekroczyć granice bezpieczeństwa, mimo że przeszedł standardowe przeglądy oprogramowania. Problem zaczyna się od błędnej klasyfikacji. Firmy często traktują pliki modeli jako bierne dane, choć niektóre formaty mogą wykonywać kod podczas ładowania.

Wynik Google News prowadzi do nagłówka Security Boulevard o ogromnej luce w bezpieczeństwie AI, której CISO może nie rozpoznać. Nagłówek stanowi użyteczny punkt wyjścia, ale jego szerokie twierdzenie wymaga ostrożnego ujęcia. Uzasadnionym problemem nie jest jedna nowo ujawniona, uniwersalna podatność.

Szerszy problem to niekompletny model bezpieczeństwa przy wdrażaniu AI. Punkty kontrolne modeli, adaptery, kod pomocniczy, prompty, narzędzia agentów i poświadczenia tworzą nowy łańcuch dostaw. Kontrole projektowane wokół pakietów źródłowych i obrazów kontenerów nie obejmują automatycznie tych komponentów.

Luka ta stawia CISO przed trudną rzeczywistością. Zespoły AI cenią szybkie eksperymentowanie i łatwy dostęp do modeli społecznościowych. Zespoły bezpieczeństwa potrzebują informacji o pochodzeniu, ograniczonego wykonywania, inwentaryzacji oraz dowodów, że pobrany artefakt nie uległ zmianie.

Główny spór nie dotyczy więc innowacji AI przeciwko bezpieczeństwu. Chodzi o przekonanie, że model jest wyłącznie danymi, kontra rzeczywistość, w której wdrożenie modelu może wprowadzać kod, zależności, zachowania i uprzywilejowany dostęp.

Co faktycznie zmienia ostrzeżenie Google News

Istotna zmiana polega na tym, że przyjmowanie modeli zasługuje dziś na taką samą kontrolę jak przyjmowanie oprogramowania.

Nagłówek Security Boulevard nie dokumentuje pojedynczego naruszenia, ofiary ani nowo przypisanej podatności. Wskazuje klasę zagrożeń, która staje się poważniejsza, gdy firmy uruchamiają pobrane modele w środowiskach produkcyjnych.

To rozróżnienie ma znaczenie. Sensacyjna interpretacja sugerowałaby, że każdy model AI jest złośliwy albo że każdy CISO przeoczył tę samą wadę. Żaden z tych wniosków nie wynika z dostępnych dowodów.

Węższy, lepiej potwierdzony wniosek nadal ma istotne konsekwencje. Organizacja może zatwierdzić projekt AI, nie analizując w pełni, jak artefakty modeli trafiają do środowiska, są w nim ładowane i działają.

Punkt kontrolny modelu przechowuje parametry i powiązane informacje potrzebne do odtworzenia systemu uczenia maszynowego. Niektóre powszechne formaty punktów kontrolnych opierają się na mechanizmie serializacji pickle w Pythonie, który odtwarza zapisane obiekty podczas ładowania.

Ten proces odtwarzania może wywoływać funkcje. Złośliwy artefakt może więc w chwili deserializacji zachowywać się mniej jak bierny dokument, a bardziej jak niezweryfikowane oprogramowanie.

Deserializacja oznacza przekształcenie zapisanych bajtów z powrotem w obiekty programu. Zagrożenie pojawia się, gdy operacja ta odtwarza obiekty na podstawie instrukcji kontrolowanych przez atakującego.

To ryzyko nie jest teoretyczną wskazówką wymyśloną po nagłówku Google News. PyTorch wyraźnie ostrzega użytkowników, by nigdy nie ładowali danych z niezaufanego źródła, ponieważ jego proces ładowania wykorzystuje unpickler.

PyTorch zmienił domyślne zachowanie torch.load w wersji 2.6. Framework używa teraz weights_only=True, gdy wywołujący nie podają własnego modułu pickle.

Ograniczony moduł ładujący akceptuje tensory, podstawowe typy danych, słowniki i wyraźnie dozwolone obiekty. Blokuje też dynamiczne importy dostępne dla standardowego unpicklera Pythona.

Ta zmiana stanowi istotne usprawnienie bezpieczeństwa. Jest również dowodem, że ładowanie modeli powinno należeć do modelu zagrożeń organizacji.

Własne wytyczne dotyczące serializacji PyTorch wskazują, że tryb ograniczony zmniejsza ryzyko zdalnego wykonania kodu. Nie chroni jednak przed każdym scenariuszem odmowy usługi ani uszkodzenia pamięci.

Kolejną komplikację tworzy zgodność. Starsze punkty kontrolne i niestandardowe klasy modeli mogą nie działać przy bezpieczniejszym ustawieniu, zachęcając deweloperów do przywrócenia weights_only=False.

Wynikający z tego komunikat oferuje dwie drogi. Zespół może przeprojektować lub przekonwertować artefakt albo zezwolić na szersze wykonywanie kodu, ponieważ oczekuje tego starszy przepływ pracy.

Pod presją terminów druga ścieżka może wyglądać jak nieszkodliwa poprawka zgodności. Z perspektywy bezpieczeństwa rozszerza jednak zakres tego, co plik może nakazać modułowi ładującemu utworzyć lub wykonać.

W tym miejscu wyzwanie dla CISO z nagłówka staje się konkretne. Ryzykowna decyzja może zapaść w notatniku, skrypcie wdrożeniowym lub konfiguracji obsługi modelu, nie trafiając do formalnego procesu wyjątków.

Tradycyjne przeglądy aplikacji zwykle pytają, które pakiety weszły do procesu budowania i czy dotyczą ich znane podatności. Przeglądy AI muszą również pytać, kto stworzył każdy artefakt modelu i w jaki sposób jest on ładowany.

Zmiana ma charakter zarówno organizacyjny, jak i techniczny. Pochodzenie modeli nie może już pozostawać nieformalną kwestią należącą wyłącznie do data scientistów.

Dlaczego bezpieczeństwo modeli AI wypada między istniejącymi właścicielami

Ekspozycja rośnie, ponieważ żaden pojedynczy zespół nie jest naturalnym właścicielem całej drogi od odkrycia modelu do dostępu produkcyjnego.

Inżynier uczenia maszynowego może wybrać model z publicznego repozytorium. Zespół platformowy może go spakować, a zespół chmurowy zapewnić zasoby obliczeniowe i sekrety.

Następnie zespół aplikacyjny łączy model z danymi klientów. Bezpieczeństwo może ocenić końcowe API, nie obserwując wcześniejszych decyzji dotyczących ładowania artefaktów.

Każdy uczestnik może poprawnie wykonać znane zadanie, pozostawiając jednocześnie cały połączony system narażony. Słabość tkwi w przekazaniach między zespołami.

Wyjaśnia to, dlaczego problem może pozostawać niewidoczny dla wyższej kadry odpowiedzialnej za bezpieczeństwo. Pobranie modelu może nie uruchamiać takich samych kontroli zakupowych, zależnościowych czy zarządzania zmianą jak konwencjonalny komponent aplikacji.

Pobrany plik może także trafić do środowiska kanałami pośrednimi. Biblioteka może pobrać go automatycznie, notatnik może pobrać go w czasie działania, a proces budowania kontenera może go buforować.

Każda z tych ścieżek komplikuje inwentaryzację. CISO nie może zarządzać artefaktem, którego organizacja nie potrafi zidentyfikować w środowiskach deweloperskich, testowych i produkcyjnych.

Otwarte repozytoria modeli ułatwiają eksperymentowanie, ale zmieniają też granicę zaufania. Dostępność repozytorium nie jest równoznaczna z weryfikacją wydawcy, integralnością artefaktu ani przydatnością do wrażliwego obciążenia.

Hugging Face częściowo rozwiązuje ten problem, skanując pliki pickle przesyłane do Hub. Jego proces skanowania pickle analizuje operacje wewnątrz przesłanych artefaktów bez wykonywania plików.

Ta kontrola dostarcza użytecznych informacji na poziomie repozytorium. Nie przenosi jednak odpowiedzialności za decyzje wdrożeniowe na operatora repozytorium.

Skan może nie wykryć nowej techniki obejścia. Może też stać się nieaktualny, jeśli plik ulegnie zmianie, inny host rozpowszechni artefakt lub kod wdrożeniowy pobierze dodatkowe komponenty.

Zespoły bezpieczeństwa muszą więc traktować skanowanie repozytorium jako jeden z sygnałów. Nie może ono zastąpić wewnętrznych kontroli pochodzenia, izolacji, kontroli dostępu ani monitorowania w czasie działania.

Odpowiedzialność staje się trudniejsza, gdy modele wymagają niestandardowego kodu. Niektóre repozytoria instruują użytkowników, aby zezwolili na zdalny kod, dzięki czemu framework może załadować niestandardową architekturę.

Niestandardowy kod nie jest automatycznie złośliwy. Jego włączenie zmienia jednak przegląd z decyzji o ładowaniu danych w decyzję o wykonywaniu oprogramowania.

Ten sam problem dotyczy rozszerzeń do obsługi modeli, tokenizerów, procesorów obrazu i skryptów wstępnego przetwarzania. Plik modelu jest tylko jedną częścią wdrożonego grafu obiektów.

Agenci dodatkowo poszerzają tę lukę. Agent AI łączy model z narzędziami, które mogą wykonywać działania, takie jak odpytywanie baz danych czy edytowanie zgłoszeń.

Model może być bezpiecznie hostowany przez zaufanego dostawcę, podczas gdy otaczający go agent nadal dysponuje nadmiernymi uprawnieniami. Z kolei agent z ściśle ograniczonymi uprawnieniami może wciąż dziedziczyć ryzyko po niezaufanym lokalnym artefakcie modelu.

CISO potrzebują obu perspektyw. Bezpieczeństwo łańcucha dostaw modeli dotyczy tego, z czego system jest zbudowany, natomiast bezpieczeństwo agentów dotyczy tego, co działający system może zrobić.

Presja spoczywa jednocześnie na inżynierii bezpieczeństwa, operacjach uczenia maszynowego, działach zakupów i właścicielach aplikacji. Żaden z nich nie rozwiąże problemu samym komunikatem polityki.

Wykonalny model odpowiedzialności wyznacza właściciela rozliczalnego za każdy model produkcyjny. Rejestruje również źródło artefaktu, skrót, format, licencję, moduł ładujący, zależności i zatwierdzone zastosowanie.

Skrót jest kryptograficznym odciskiem palca pliku. Pozwala zespołowi potwierdzić, że zweryfikowany artefakt odpowiada artefaktowi trafiającemu do wdrożenia.

Te dowody powinny towarzyszyć modelowi na kolejnych etapach promocji. W przeciwnym razie potok produkcyjny może po cichu pobrać nowszy plik pod tą samą nazwą repozytorium.

To zwykła dyscyplina zarządzania łańcuchem dostaw zastosowana do mniej zwykłego komponentu. Nowość tkwi w zachowaniu tego komponentu, a nie w potrzebie śledzenia jego pochodzenia.

Rzeczywisty konflikt: model jako dane kontra model jako kod

Wdrożenie AI zawodzi, gdy zespoły zakładają, że model zawiera jedynie matematyczne wagi i nie niesie żadnych skutków wykonawczych.

To założenie wydaje się rozsądne. Na poziomie koncepcyjnym sieć neuronowa składa się z wyuczonych parametrów wykorzystywanych przez zdefiniowaną architekturę.

Warstwa pakowania komplikuje ten obraz. Punkt kontrolny może zawierać tensory, definicje obiektów, stan optymalizatora, metadane i odniesienia potrzebne do odtworzenia pierwotnego środowiska.

Pickle zapewnia tę elastyczność, ponieważ może serializować złożone obiekty Pythona. Ta sama elastyczność sprawia, że niebezpieczne ładowanie jest ryzykowne.

Złośliwy ładunek pickle nie musi zmieniać widocznej wydajności modelu. Może próbować wykonać polecenie systemu operacyjnego podczas ładowania, zanim ewaluator zada modelowi pierwsze pytanie.

Taka sekwencja omija przeglądy skupione wyłącznie na wynikach modelu. Testy dokładności, prompty bezpieczeństwa i oceny stronniczości nie wykryją kodu, który został już uruchomiony podczas inicjalizacji.

Przeciwne podejście wykorzystuje formaty zaprojektowane do przechowywania tensorów bez obsługi dowolnego odtwarzania obiektów. Safetensors jest znaczącym przykładem opracowanym z myślą o bezpieczniejszym i wydajnym przechowywaniu tensorów.

Jego struktura oddziela ograniczony nagłówek metadanych od surowych danych tensorowych. Ładowanie tego formatu nie wywołuje instrukcji pickle Pythona.

Taka konstrukcja eliminuje konkretną ścieżkę arbitralnego wykonania kodu tworzoną przez deserializację pickle. Nie sprawia jednak, że cały system AI staje się godny zaufania.

Plik safetensors nadal może przedstawiać zmanipulowany model. Model może zawierać backdoor wyuczony podczas treningu albo generować niebezpieczne wyniki po określonym wyzwalaczu.

Bezpieczeństwo formatu pliku i bezpieczeństwo zachowania modelu to różne warstwy. Traktowanie którejkolwiek z nich jako pełnej ochrony odtwarza ten sam błąd klasyfikacji.

To rozróżnienie wyjaśnia również, dlaczego sam skaner nie może rozstrzygnąć sprawy. Skanowanie statyczne może badać strukturę pliku i podejrzane operacje, ale nie może zagwarantować łagodnego zachowania modelu.

Z kolei ocena zachowania nie może dowieść braku niebezpiecznego kodu inicjalizacyjnego. Bezpieczeństwo wymaga kontroli przed ładowaniem, podczas oceny i po wdrożeniu.

OWASP zalicza słabości łańcucha dostaw do głównych zagrożeń dla aplikacji opartych na dużych modelach językowych. Jego lista zagrożeń dla LLM obejmuje modele, dane, platformy wdrożeniowe i komponenty zewnętrzne.

To szersze ujęcie ma znaczenie, ponieważ usługa AI to coś więcej niż sam checkpoint. Obejmuje oprogramowanie do inferencji, systemy wyszukiwania, wtyczki, API i warstwy przetwarzania danych.

Atakującemu wystarczy jedna zaufana ścieżka do tego łańcucha. Może ją zapewnić przejęte konto, zmodyfikowany artefakt, podmieniona zależność lub zbyt liberalny loader.

Prowadzi to do bezpośredniego napięcia między szybkością a pewnością. Publiczne modele pozwalają zespołom testować pomysł bez oczekiwania na umowę z dostawcą lub długi cykl szkoleniowy.

Ta sama wygoda sprzyja korzystaniu ze zmiennych referencji i niezweryfikowanych pobrań. Nazwa repozytorium może zastąpić potwierdzone pochodzenie.

Właściwą odpowiedzią nie jest całkowity zakaz stosowania otwartych modeli. Usługi zamknięte niosą inne ryzyka, w tym zależność od dostawcy, zdalne przetwarzanie danych i ograniczoną widoczność artefaktów.

Liderzy ds. bezpieczeństwa potrzebują mechanizmów kontrolnych dopasowanych do każdej ścieżki wdrożenia. Zarządzane API wymaga oceny dostawcy, danych, tożsamości i rejestrowania zdarzeń.

Model hostowany samodzielnie wymaga dodatkowo kontroli pochodzenia artefaktów, zasad dotyczących formatów plików, odizolowanej oceny, kontroli zależności i utwardzenia infrastruktury. Daje też operatorowi bardziej bezpośrednią kontrolę nad tymi zabezpieczeniami.

Praktyczny kompromis jest jasny. Samodzielny hosting może poprawić kontrolę nad danymi, ale przenosi większą odpowiedzialność za łańcuch dostaw na organizację wdrażającą.

Odpowiedzialność ta obejmuje sam model, jego loader, powiązany kod, narzędzia do konwersji i przyszłe aktualizacje. Trwa również po pierwszym zatwierdzeniu bezpieczeństwa.

Dlatego ostrzeżenie Google News nie powinno stać się jednorazowym punktem na liście kontrolnej. Ekspozycja dotyczy każdej rewizji modelu i każdej nowej integracji.

Bezpieczniejsze formaty zmniejszają ryzyko, ale nie ustanawiają zaufania

Bezpieczny format serializacji zamyka jedną ścieżkę wykonania, pozostawiając nierozstrzygnięte kwestie pochodzenia, zachowania modelu i uprawnień wdrożeniowych.

Safetensors jest dobrym domyślnym wyborem, gdy aplikacja musi przechowywać i ładować wagi tensorów. Jego węższy format unika ogólnej rekonstrukcji obiektów zapewnianej przez pickle.

Ograniczony loader PyTorch oferuje kolejną użyteczną ochronę dla zgodnych checkpointów. Oba mechanizmy zmniejszają prawdopodobieństwo, że ładowanie modelu wykona nieoczekiwane obiekty Python.

Żaden z tych mechanizmów nie odpowiada na pytanie, kto wytrenował model. Żaden nie potwierdza, czy atakujący zmodyfikował jego wagi przed dystrybucją.

Złośliwie wytrenowany model może ukrywać zachowanie w swoich parametrach. Wyzwalacz może powodować ukierunkowaną błędną klasyfikację, wyciek danych lub konkretną niepożądaną odpowiedź.

Zagrożenia te różnią się od ładunku pickle. Wymagają testów zachowania, dowodów pochodzenia i monitorowania, a nie wyłącznie analizy pliku.

Konwersja modelu również wymaga ostrożności. Przekształcenie niebezpiecznego checkpointu do bezpieczniejszego formatu może wymagać załadowania oryginalnego pliku.

Jeżeli konwersja odbywa się na zaufanej stacji roboczej lub w sieci produkcyjnej, niebezpieczna operacja może nastąpić, zanim powstanie bezpieczny wynik. Konwersja wymaga odizolowanego, jednorazowego środowiska.

Środowisko to nie powinno mieć poświadczeń produkcyjnych ani wrażliwych danych. Dostęp do sieci powinien być wyłączony, chyba że proces konwersji ma udokumentowaną potrzebę jego użycia.

Skonwertowany artefakt powinien otrzymać nowy skrót oraz zapis wiążący go ze źródłem. Recenzenci powinni zachować wyniki skanerów, logi konwersji i dowody zatwierdzenia.

Dowody te tworzą łańcuch nadzoru. Pomagają zespołom reagującym na incydenty ustalić, które systemy otrzymały konkretny artefakt po późniejszym ostrzeżeniu.

Repozytoria modeli już udostępniają przydatne metadane, historię wersji i sygnały ze skanowania. Przedsiębiorstwa powinny pozyskiwać te dowody, zamiast polegać na historii przeglądarki dewelopera.

Silniejszy wzorzec wykorzystuje wewnętrzny rejestr jako źródło produkcyjne. Zewnętrzne artefakty trafiają do kwarantanny, przechodzą weryfikację i otrzymują niezmienne wewnętrzne identyfikatory.

Systemy produkcyjne pobierają następnie wyłącznie zatwierdzone skróty z tego rejestru. Nie pobierają dowolnego pliku, który aktualnie znajduje się pod zewnętrzną gałęzią lub tagiem.

Kontrole sieciowe wzmacniają ten projekt. Obciążenia obsługujące modele nie powinny potrzebować nieograniczonego dostępu wychodzącego po wdrożeniu.

Ograniczenie takiego dostępu zmniejsza wartość ukrytego programu pobierającego lub ładunku wykradającego poświadczenia. Ułatwia też wykrywanie nieoczekiwanych połączeń.

Zasada najmniejszych uprawnień jest równie ważna. Proces modelu nie powinien dziedziczyć praw administracyjnych w chmurze tylko dlatego, że platforma hostingowa korzysta ze współdzielonego konta usługi.

Sekrety powinny być udostępniane wyłącznie wtedy, gdy wymaga ich konkretne narzędzie. Agent powinien otrzymywać wąskie uprawnienia na poziomie zadania, zamiast ogólnego tokenu do całego systemu biznesowego.

NIST uznaje bezpieczne i odporne działanie za podstawowy element godnej zaufania AI. Jego ramy zarządzania ryzykiem AI podkreślają ciągłe zarządzanie, pomiar, mapowanie i kontrolę w całym cyklu życia systemu.

Takie spojrzenie na cykl życia zapobiega częstemu błędowi. Zespół może zatwierdzić model raz, a następnie zezwolić na automatyczne aktualizacje, które zmieniają sprawdzony system.

Ciągłe monitorowanie powinno wykrywać zmiany artefaktów, konfiguracji loadera, nowe połączenia wychodzące i nietypowy dostęp do sekretów. Powinno również rejestrować działania agentów.

Logi muszą zawierać wystarczający kontekst, aby odtworzyć przebieg zdarzeń. Zapis żądania bez wersji modelu, wywołania narzędzia, tożsamości użytkownika i decyzji autoryzacyjnej ma ograniczoną wartość dochodzeniową.

Rejestrowanie zdarzeń wprowadza jednak własne ryzyko. Prompty i wyniki mogą zawierać informacje regulowane, dane osobowe lub informacje poufne.

Zespoły muszą określić zasady retencji, redakcji danych i dostępu, zanim zaczną zbierać wszystko. Telemetria bezpieczeństwa nie powinna stać się niekontrolowaną kopią wrażliwych danych biznesowych.

Sceptyczna uwaga pozostaje istotna. Żaden skaner, format ani rejestr nie mogą udowodnić, że system AI jest nieszkodliwy.

Celem jest możliwe do obrony ograniczenie ryzyka. Organizacje potrzebują warstwowych mechanizmów kontrolnych, które utrudniają kompromitację, ograniczają jej zasięg i zachowują dowody na potrzeby reakcji.

Czego CISO powinien wymagać przed wdrożeniem kolejnego modelu

Minimalnie akceptowalnym mechanizmem kontrolnym jest śledzalna ścieżka od zatwierdzonego artefaktu źródłowego do ograniczonego procesu produkcyjnego.

Pierwszym wymogiem jest inwentaryzacja. Każdy produkcyjny system AI powinien identyfikować model, wersję, skrót artefaktu, format, źródło, właściciela, loader i lokalizację wdrożenia.

Inwentaryzacja musi obejmować adaptery i fine-tuning. Model bazowy może pozostać niezmieniony, podczas gdy adapter istotnie zmienia jego zachowanie.

Rejestr powinien również obejmować tokenizery, własny kod, komponenty wyszukiwania i narzędzia zewnętrzne. Elementy te mogą zmieniać wyniki bezpieczeństwa bez modyfikowania wag modelu.

Drugim wymogiem jest bramka przyjmowania. Zespoły powinny pobierać zewnętrzne artefakty do kwarantanny, a nie bezpośrednio na stację roboczą dewelopera lub do kompilacji produkcyjnej.

Bramka powinna weryfikować oczekiwany skrót, gdy jest dostępny. Powinna sprawdzać typy plików, zawartość archiwów, podpisy i sygnały bezpieczeństwa repozytorium.

Niebezpieczne formaty serializacji zasługują na zasadę domyślnej odmowy. Wyjątki powinny dokumentować, dlaczego bezpieczniejszy format lub ograniczony loader nie mogą obsłużyć danego obciążenia.

Wyjątek powinien również identyfikować mechanizmy izolacji użyte podczas oceny. Zaufanie do znanego autora przesyłającego jest istotne, lecz nie stanowi pełnego zabezpieczenia technicznego.

Trzecim wymogiem jest odtwarzalność. Potok wdrożeniowy powinien odwoływać się do niezmiennego artefaktu, pliku blokady zależności, obrazu kontenera i konfiguracji.

Odtwarzalność pozwala obrońcom ponownie zbudować sprawdzony system. Ogranicza też cichy dryf między testami a produkcją.

Czwartym wymogiem jest ograniczone wykonanie. Ocena powinna odbywać się w tymczasowym środowisku bez sekretów produkcyjnych, wrażliwych montowań ani szerokiego dostępu do sieci.

Inferencja produkcyjna powinna działać pod własną tożsamością. Tożsamość ta powinna posiadać wyłącznie uprawnienia niezbędne dla zatwierdzonego zastosowania.

Piątym wymogiem jest plan reagowania na incydenty AI. Zespoły reagowania potrzebują procedur wycofania modelu, wyłączenia agenta, rotacji ujawnionych poświadczeń i lokalizowania dotkniętych wdrożeń.

Konwencjonalny alert dotyczący endpointu może wskazać kontener, który uruchomił podejrzane polecenie. Osoby reagujące muszą także ustalić, który artefakt modelu i loader zainicjowały ten proces.

Szóstym wymogiem jest odpowiedzialność. Bezpieczeństwo nie może odpowiadać za każdą decyzję dotyczącą modelu, ale może określić dowody wymagane do zatwierdzenia.

Właściciele modeli powinni poświadczać, że ich artefakt produkcyjny odpowiada sprawdzonemu skrótowi. Zespoły platformowe powinny egzekwować używanie zatwierdzonych rejestrów i zasady dotyczące loaderów.

Działy zakupów powinny wymagać od dostawców opisu pochodzenia modeli, praktyk aktualizacji, testów bezpieczeństwa i powiadamiania o incydentach. Postanowienia umowne nie zastąpią mechanizmów inżynieryjnych, ale mogą ustanowić odpowiedzialność.

Rejestr komponentów AI może wspierać taką dokumentację. Rozszerza inwentaryzację komponentów oprogramowania o modele, zbiory danych, frameworki i powiązane zasoby AI.

Koncepcja ta jest nadal mniej ustandaryzowana niż konwencjonalny rejestr komponentów oprogramowania. Organizacje powinny mimo to zacząć zbierać informacje, które potrafią zweryfikować.

Cloud Security Alliance opisało złośliwe repozytoria modeli jako nową powierzchnię ataku. Jego analiza repozytoriów wskazuje pliki modeli, otaczający je kod i potoki wdrożeniowe jako powiązane ryzyka.

Liderzy ds. bezpieczeństwa powinni przełożyć tę obawę na egzekwowalne domyślne ustawienia platformy. Same wytyczne przegrają z poleceniem w notebooku, które działa natychmiast.

Dobre ustawienie domyślne ułatwia korzystanie z zatwierdzonej ścieżki. Zespoły powinny otrzymać wspierany wewnętrzny rejestr, automatyczne skanowanie, pomoc w konwersji oraz wielokrotnego użytku odizolowane środowiska oceny.

Wyjątki powinny być widoczne i tymczasowe. Powinny wygasać, gdy ograniczenie techniczne znika lub dostępny staje się bezpieczniejszy artefakt.

CISO powinni też unikać zawyżania deklarowanych efektów tych mechanizmów. Czysty wynik skanowania nie certyfikuje zachowania modelu, a zatwierdzony model nadal może zostać niewłaściwie użyty.

Celem jest zarządzana ścieżka wdrożenia. Tworzy ona jasne granice zaufania i ogranicza skutki awarii jednej warstwy zapewnienia.

Trzy sygnały, które pokażą, czy luka się zamyka

Kolejny etap będzie mierzony bezpieczniejszymi ustawieniami domyślnymi, weryfikowalnym pochodzeniem modeli i egzekwowalnymi granicami środowiska uruchomieniowego.

Pierwszym sygnałem będzie szersze użycie niewykonywalnych formatów modeli i ograniczonych loaderów. Zmiana domyślnego ustawienia PyTorch już kieruje ekosystem w tę stronę.

Warto obserwować, czy platformy przedsiębiorstw automatycznie odrzucają niebezpieczne ładowanie. Należy też sprawdzać, czy deweloperzy rutynowo wyłączają bezpieczniejsze ustawienie, aby zachować zgodność ze starszymi rozwiązaniami.

Częste wyłączenia osłabiłyby optymistyczną ocenę. Pokazałyby, że tarcia w procesie pracy nadal pokonują bezpieczne ustawienia domyślne.

Spadający wskaźnik wyjątków wspierałby przeciwny wniosek. Wskazywałby, że wydawcy modeli i zespoły aplikacyjne dostosowują praktyki pakowania.

Drugim sygnałem będzie pochodzenie modelu, które przetrwa wdrożenie. Metadane repozytorium pomagają, ale przedsiębiorstwa potrzebują niezmiennych wewnętrznych zapisów powiązanych z dokładnym artefaktem produkcyjnym.

Warto obserwować, czy platformy chmurowe i rejestry modeli udostępniają podpisy, poświadczenia, szczegóły zależności i historię promocji za pośrednictwem standardowych przepływów wdrożeniowych.

Poświadczenie to podpisany dowód dotyczący sposobu utworzenia lub sprawdzenia artefaktu. Jego wartość zależy od tożsamości, procesu i zasad stojących za podpisem.

Pochodzenie powinno obejmować również fine-tuning i konwersje. W przeciwnym razie podpisany model bazowy może prowadzić do niemożliwej do prześledzenia pochodnej produkcyjnej.

Postęp w tym obszarze wzmocniłby pogląd, że przyjmowanie modeli staje się zarządzanym łańcuchem dostaw. Fragmentaryczne metadane i zmienne referencje osłabiłyby go.

Trzecim sygnałem będzie lepsze ograniczanie agentów i obciążeń obsługujących modele. Obejmuje to tożsamości obciążeń, uprawnienia na poziomie narzędzi, zasady sieci wychodzącej i kompletne logi działań.

Wdrażanie agentów przesuwa ryzyko z generowanego tekstu na wykonywane działania. Model mający dostęp do poczty e-mail, kodu źródłowego lub systemów finansowych może powodować konsekwencje wykraczające poza nieprecyzyjną odpowiedź.

Zespoły ds. bezpieczeństwa powinny sprawdzać, czy dostawcy udostępniają granice uprawnień, które administratorzy mogą testować i audytować. Marketingowe deklaracje dotyczące bezpiecznej autonomii nie wystarczą.

Skuteczna kontrola powinna wskazywać, która tożsamość zatwierdziła działanie, które narzędzie je wykonało, który model je zaproponował oraz która polityka na nie zezwoliła.

Organizacje powinny także testować procedury awaryjnego wyłączania. Kontrola istniejąca wyłącznie w dokumentacji konfiguracji może zawieść podczas rzeczywistego incydentu.

Dowody na rutynowe testy mechanizmów ograniczania skutków zwiększyłyby zaufanie. Współdzielone dane uwierzytelniające i narzędzia bez ograniczeń wskazywałyby, że wdrażanie agentów wyprzedza nadzór.

Te trzy sygnały należy rozpatrywać łącznie. Bezpieczniejsze pliki zmniejszają ryzyko podczas inicjalizacji, pochodzenie wzmacnia decyzje oparte na zaufaniu, a mechanizmy ograniczania skutków redukują szkody po wdrożeniu.

Żaden z nich samodzielnie nie zapewnia pełnej gwarancji. Razem zastępują domniemany model zaufania systemem, który można kontrolować i podważać.

Nagłówek w Google News spełni swoją rolę, jeśli skłoni liderów bezpieczeństwa do zadania bardziej precyzyjnego pytania. Problemem nie jest to, czy AI stanowi jakieś abstrakcyjne zagrożenie w przyszłości.

Pilne pytanie brzmi: czy każdy wdrożony model ma znane pochodzenie, bezpieczną ścieżkę ładowania i ograniczoną tożsamość. Wiele organizacji wciąż nie potrafi odpowiedzieć twierdząco na wszystkie trzy kwestie.

Ta luka w weryfikacji jest prawdziwą luką bezpieczeństwa. Znajduje się między eksperymentowaniem a produkcją, gdzie znane narzędzia tworzą nieznaną decyzję dotyczącą zaufania.

Liderzy bezpieczeństwa powinni w tym tygodniu wybrać jeden wdrożony model i prześledzić go wstecz. Należy zidentyfikować jego skrót, źródło, mechanizm ładowania, niestandardowy kod, uprawnienia i ścieżkę aktualizacji.

Jeśli jakiekolwiek ogniwo zależy od pamięci lub nieudokumentowanej decyzji programisty, organizacja zidentyfikowała obszar wymagający działania. Kolejne ostrzeżenie w Google News nie powinno być pierwszym momentem, gdy ten łańcuch otrzyma uwagę kadry zarządzającej.