Co się stało
Help Net Security donosi, że AWS opublikował publicznie swój Deception , który sprawdza, czy modele sztucznej inteligencji potrafią odróżnić autentyczne luki w oprogramowaniu od bezpiecznego kodu zawierającego wprowadzające w błąd wzorce podatności. Benchmark obejmuje 14 822 próbek obejmujących 16 języków programowania i ponad 70 kategorii CWE; Oceniono 9695, a 5127 zmieszano jako próbki bez punktacji.
Help Net Security donosi, że AWS ocenił 12 modeli ogólnego przeznaczenia od pięciu dostawców, korzystając z testu porównawczego zaprojektowanego pod kątem fałszywych alarmów. Bezpieczne przykłady testu porównawczego zawierają rzeczywiste wzorce luk w zabezpieczeniach wraz z zabezpieczeniami zapobiegającymi wykorzystaniu. Niektóre wyzwania różnią się warunkami wdrożenia, takimi jak zasady sieciowe Kubernetes, dlatego model musi uwzględniać zarówno kod, jak i jego środowisko.
Według raportu w ramach projektu AWS wygenerowano i udoskonalono przykłady w oparciu o modele pionierskie, z wyłączeniem próbek, które były zbyt łatwe do sklasyfikowania. AWS twierdzi, że proces ten pochłonął dziesiątki miliardów tokenów. Firma udostępnia publicznie próbki, ale zatrzymuje ich etykiety; użytkownicy przesyłają prognozy do AWS w celu zweryfikowania punktacji. Źródło nie podaje, czy dostęp do scoringu jest płatny lub spełnia inne wymagania kwalifikacyjne.
Help Net Security raportuje, że niezależni recenzenci sprawdzają etykiety, nie widząc wzajemnych decyzji ani pierwotnego uzasadnienia. Próbki sporne poddawane są dalszej ocenie, a sprawy nierozwiązane przenoszone są do zbioru niepunktowanego. AWS twierdzi, że mniej niż 3% ocenionych próbek pozostaje kwestionowanych po przeglądzie, przy czym docelowa ocena przez człowieka przetrwała mniej niż 1%, i nie zgłasza żadnych błędów w etykietowaniu podczas przeglądu 100 losowo wybranych punktowanych próbek. Twierdzenia te nie zostały tutaj niezależnie potwierdzone.
Szczegóły źródła: helpnetsecurity.com ↗
Dlaczego to ma znaczenie
Wyniki sugerują, że wysoka skuteczność w znajdowaniu podejrzanego kodu niekoniecznie przekłada się na niezawodną selekcję podatności. Wysoki odsetek wyników fałszywie dodatnich może stanowić obciążenie dla zespołów ds. bezpieczeństwa i osłabiać zaufanie do alertów, natomiast bardziej rygorystyczne wymagania dotyczące dowodów mogą spowodować, że modele przeoczą rzeczywiste luki w zabezpieczeniach. Odkrycia są istotne dla organizacji rozważających przegląd kodu wspomagany sztuczną inteligencją lub operacje związane z bezpieczeństwem, ale nie mierzą kompletnych komercyjnych produktów bezpieczeństwa.
Test porównawczy usuwa praktyczną słabość zabezpieczeń wspomaganych przez sztuczną inteligencję: model może rozpoznać niebezpiecznie wyglądający wzór bez zrozumienia mechanizmów kontrolnych zapobiegających nadużyciom. Help Net Security podaje, że bezpośrednie podpowiedzi generowały odsetek wyników fałszywie dodatnich od 41% do 99%, podczas gdy precyzja wahała się od 52% do 71%.
Z raportu wynika, że wymaganie od modeli wykazania, że luka w zabezpieczeniach faktycznie może zostać wykorzystana, zmniejszyło liczbę wyników fałszywie dodatnich o 17 do 74 punktów procentowych, ale zwiększyło odsetek wyników fałszywie ujemnych do 7–44%. Podany przez AWS minimalny pasek produkcji wynosił poniżej 10% w przypadku obu miar, a żadna z testowanych konfiguracji nie osiągnęła obu progów.
Wyniki te nie powinny być odczytywane jako ranking kompletnych produktów zabezpieczających. AWS przetestował podpowiedzi jednoobrotowe na modelach ogólnego przeznaczenia, a nie na specjalnie zaprojektowanych systemach, które korzystają z narzędzi, wielokrotnej walidacji lub agentycznych przepływów pracy. Źródło podtrzymuje zatem ostrożność w ocenie podatności na poziomie modelu, a nie wniosek, że produkty zabezpieczające AI jako całość zawodzą.
Mechanizm interaktywny: jak to faktycznie działa
Poznaj interaktywnie technologię leżącą u podstaw tego rozwoju.
Which component of an AI application is the machine-learning model itself?
Co obejrzeć dalej
Obserwuj niezależne oceny z wykorzystaniem udostępnionych próbek, wyniki z użycia narzędzi lub wieloetapowych systemów bezpieczeństwa oraz dowody dotyczące wydajności w rzeczywistych środowiskach produkcyjnych. Źródło nie dokumentuje cen, dostępu na poziomie usług ani tego, czy proces punktacji AWS jest dostępny bez ograniczeń. Nie ustala również, że testowane modele działają podobnie w nieujawnionym kodzie korporacyjnym.
Niezależni badacze mogą korzystać z publicznych próbek i procesu oceny bez odtwarzania raportowanych kosztów generowania danych przez AWS, ale ukryte etykiety i punktacja zweryfikowana przez AWS mają na celu ograniczenie optymalizacji specyficznej dla testu porównawczego. Replikacja przez grupy zewnętrzne pomogłaby przetestować zgłoszone wyniki i jakość etykietowania.
Przyszłe oceny powinny porównywać modele jednoprzebiegowe z systemami, które sprawdzają repozytoria, bezpiecznie wykonują kod, analizują konfigurację wdrożenia i wymagają dowodów przed wydaniem alertu. Testy te lepiej wskazywałyby, jak bardzo praktyczne narzędzia bezpieczeństwa poprawiają wyniki dotyczące samego modelu.
Źródło pozostawia ważne niewiadome: nie identyfikuje 12 testowanych konfiguracji modeli, nie podaje wyników dla poszczególnych modeli w dostarczonym tekście, nie dokumentuje cen ani warunków dostępu do zweryfikowanej punktacji, ani nie pokazuje, w jaki sposób wydajność przenosi się do zastrzeżonych baz kodów i bieżących operacji bezpieczeństwa.