Działania Amazon i Google na rzecz bezpieczeństwa zderzają się z rzeczywistością błędów AI
Partnerzy Amazon i Google ds. bezpieczeństwa dołączyli do wyścigu zbrojeń w obronie opartej na AI, napędzanego ostrym ostrzeżeniem, choć jedynie 1,3 procent badanych podatności doprowadziło do wykorzystania w rzeczywistych atakach.
Liczba ta pochodzi z analizy VulnCheck obejmującej 1 061 publicznie przypisanych odkryć wspomaganych przez AI. Badacze zestawili te ustalenia z dowodami ataków zaobserwowanych poza kontrolowanymi środowiskami.
Wynik podważa kluczowe założenie kampanii Amazon i Google wokół Project Glasswing firmy Anthropic. AI potrafi szybko wykrywać błędy, lecz samo odkrycie nie prowadzi automatycznie do skutecznego ataku.
Anthropic nadal przedstawia mocne argumenty za pilnym działaniem. System Claude Mythos Preview wykrył 23 019 kandydatów na podatności podczas skanowania projektów open source. Firma oszacowała, że 6 202 z nich zasługiwało na ocenę wysokiej lub krytycznej wagi.
Te ogromne liczby wpłynęły na prognozy nadchodzącej fali exploitów generowanych przez AI. Jednak dostępne publicznie dane opisują obecnie inną zmianę.
AI zwielokrotnia liczbę możliwych ustaleń dotyczących bezpieczeństwa szybciej, niż ludzie są w stanie je zweryfikować, ujawnić, załatać i uszeregować według priorytetów. Atakujący nadal muszą wykonać trudniejszą pracę polegającą na przekształceniu technicznej słabości w niezawodną operację.
To rozróżnienie zmienia punkt ciężkości obrońców. Bezpośrednim problemem nie jest po prostu to, że AI znajduje więcej błędów. Chodzi o to, że zespoły bezpieczeństwa muszą oddzielić istotne ryzyko od rosnącej liczby dowodów generowanych przez maszyny.
Dane o wykorzystaniu zmieniają tę historię
Wspomagane przez AI odkrywanie zwiększyło liczbę podatności, nie podnosząc jednak obserwowanego wskaźnika ich wykorzystania.
VulnCheck przeanalizował 1 061 podatności przypisanych Project Glasswing i Berkeley Vulnerability Research Initiative. Następnie porównał je ze swoją bazą Known Exploited Vulnerabilities.
Firma znalazła 14 podatności z potwierdzonym wykorzystaniem w rzeczywistych atakach. Stanowi to 1,3 procent przeanalizowanej grupy, zgodnie z opublikowaną analizą wykorzystania.
VulnCheck podał, że wskaźnik ten był niemal identyczny ze wskaźnikiem dla szerszego zbioru danych o podatnościach. Błędy wykryte przez AI nie wydawały się więc bardziej narażone na wykorzystanie niż błędy odkryte metodami konwencjonalnymi.
Porównanie jest istotne, ponieważ odkrywanie podatności i ich wykorzystywanie mierzą różne zdolności. Skaner identyfikuje zachowanie kodu, które może naruszać oczekiwaną granicę bezpieczeństwa.
Działający exploit musi wywołać to zachowanie w praktycznych warunkach. Często musi ominąć mechanizmy ochronne, dotrzeć do wartościowego systemu i niezawodnie działać w różnych konfiguracjach celu.
Prawdziwi atakujący oceniają także ekonomikę działania. Biorą pod uwagę dostęp, czas potrzebny na rozwój, ryzyko wykrycia, dostępne cele oraz wartość danych lub kontroli, które mogliby uzyskać.
Wiele błędów nie przechodzi tego testu. Niektóre wymagają lokalnego dostępu, nietypowych konfiguracji lub uprawnień, których atakujący już potrzebuje. Inne powodują awarie, nie umożliwiając przy tym użytecznej kontroli.
Podatność może pozostawać technicznie prawidłowa, a jednocześnie oferować niewielką wartość operacyjną. Same oceny ważności nie wyjaśniają, czy przestępcy zainwestują w jej uzbrojenie.
Project Glasswing szczególnie uwidacznia to rozróżnienie. Anthropic podał, że Mythos Preview wygenerował 23 019 kandydatów w ponad 1 000 projektów open source.
W publicznych danych przeanalizowanych przez VulnCheck jedynie 126 ustaleń Project Glasswing stało się opublikowanymi wpisami Common Vulnerabilities and Exposures. Tylko jedno miało potwierdzone wykorzystanie w środowisku rzeczywistym.
To węższe porównanie nie dowodzi, że pozostałe kandydatury są nieszkodliwe. Skoordynowane ujawnianie celowo utrzymuje część szczegółów w tajemnicy, dopóki opiekunowie oprogramowania nie będą mogli udostępnić poprawek.
Pokazuje jednak, że liczby kandydatów nie mogą zastępować zweryfikowanych wyników dotyczących podatności. Z pewnością nie mogą też mierzyć, ile ustaleń stało się niezawodnymi narzędziami ofensywnymi.
Badacz VulnCheck Patrick Garrity opisał obecny wpływ jako rzeczywisty, lecz umiarkowany. Argumentował, że podatności odkryte przez AI nie są z natury łatwiejsze do wykorzystania niż te odkryte tradycyjnymi metodami.
Ustalenia ujawniają także istotny problem z mianownikiem. Łączna liczba kandydatów Project Glasswing obejmuje problemy o średniej i niskiej wadze obok najwyżej ocenianych ustaleń.
Publiczne liczby CVE reprezentują późniejszy etap. Takie wpisy zwykle wymagają weryfikacji, koordynacji i wystarczającej jasności technicznej, aby opisać dotknięty produkt oraz słabość.
Znane przypadki wykorzystania narzucają jeszcze wyższy standard. Wymagają wiarygodnych dowodów, że ktoś rzeczywiście użył podatności przeciwko realnemu celowi.
Porównywanie tych etapów bez zastrzeżeń prowadzi do mylących wniosków. Duża pula kandydatów może współistnieć z bardzo małą liczbą przypadków wykorzystania, ponieważ każdy etap filtruje inne dowody.
Wskaźnik 1,3 procent stanowi zatem weryfikację rzeczywistości, a nie sygnał, że zagrożenie minęło. Wskazuje, że AI zmieniła podaż ustaleń, zanim zmieniła ich średnią wartość operacyjną.
Partnerzy Amazon i Google ds. bezpieczeństwa wciąż mają powody, by działać szybko
Niski obserwowany poziom wykorzystania nie eliminuje zagrożenia dla zespołów bezpieczeństwa Amazon i Google ani innych partnerów Project Glasswing.
Anthropic uruchomił Project Glasswing, aby zapewnić wybranym obrońcom wczesny dostęp do Claude Mythos Preview. Wśród pierwszych uczestników znalazły się Amazon Web Services, Google, Apple, Microsoft, Cisco, Nvidia i inni dostawcy infrastruktury.
Projekt rozpoczął się z około 50 partnerami. Anthropic później poinformował, że rozszerza dostęp na około 150 dodatkowych organizacji w ponad 15 krajach.
Uczestnicy wykorzystują Mythos Preview do badania wewnętrznego i otwartego kodu źródłowego, zanim porównywalne możliwości staną się powszechnie dostępne. Anthropic nazywa to asymetryczną przewagą obronną.
Obawa firmy jest prosta. Systemy AI mogą analizować znacznie więcej ścieżek kodu, niż zespół badaczy jest w stanie ręcznie sprawdzić.
Przyszły atakujący mógłby wykorzystać tę samą skalę bez przestrzegania zasad skoordynowanego ujawniania. Mógłby również skoncentrować skanowanie na oprogramowaniu dostępnym z internetu, mającym wyraźne cele komercyjne.
Obecny wskaźnik wykorzystania opisuje publicznie dostępne dowody, a nie każdą prywatną aktywność. Grupy przestępcze nie ogłaszają niezawodnie udanych operacji zero-day ani nie publikują swoich metod technicznych.
Potwierdzone liczby wykorzystania będą więc zaniżać część aktywności. Niepewność rośnie, gdy ustalenia pozostają poufne podczas usuwania problemu.
Niedawne wydarzenia pokazują, że wspomagana przez AI praca ofensywna nie ogranicza się już do benchmarków. Google poinformował o udaremnieniu działań przestępców, którzy najwyraźniej użyli modelu AI podczas identyfikowania nieznanej podatności oprogramowania.
Operacja nie spowodowała zgłoszonych szkód, ponieważ obrońcy interweniowali. Przypadek dostarczył jednak dowodów, że przestępcy testowali AI w rzeczywistym procesie pracy nad podatnościami.
Luka między eksperymentami a skalowalnym wykorzystaniem pozostaje znacząca. Jedna wykryta operacja nie dowodzi, że atakujący potrafią zautomatyzować cały proces.
Mimo to obrońcy nie mogą czekać ze przygotowaniami, aż statystyki wykorzystania wzrosną. Publiczne potwierdzenie zwykle pojawia się po włamaniu, dochodzeniu kryminalistycznym lub ujawnieniu przez dostawcę.
Amazon podchodzi do tego samego problemu z innej perspektywy operacyjnej. Jego system RuleForge przekształca informacje o podatnościach i kod proof-of-concept w reguły wykrywania.
Amazon twierdzi, że system zwiększył produktywność generowania reguł o 336 procent. Osobny ewaluator zmniejszył liczbę fałszywie pozytywnych wyników o 67 procent, zachowując wykrywanie prawdziwie pozytywnych przypadków.
Twierdzenia te pochodzą z własnych wyników RuleForge firmy Amazon, a nie z niezależnego benchmarku. Mimo to architektura ilustruje, jak obrońcy mogą wykorzystywać AI poza samym odkrywaniem.
RuleForge dzieli pracę między wyspecjalizowanych agentów odpowiedzialnych za pozyskiwanie danych, generowanie, ocenę i walidację. Ludzcy recenzenci zachowują odpowiedzialność za zatwierdzanie reguł przed wdrożeniem.
Ten przepływ pracy dotyczy brakującego etapu pośredniego między ujawnioną podatnością a działającą obroną. Znalezienie błędu nie prowadzi automatycznie do powstania telemetrii, detekcji, poprawek ani wskazówek dotyczących wdrożenia.
Google dąży do szybszego odkrywania i usuwania problemów za pośrednictwem CodeMender oraz Gemini 3.5 Flash Cyber. Wyspecjalizowany model zaprojektowano do znajdowania, walidowania i łatania podatności w dużych bazach kodu.
Google podaje, że model znalazł 55 unikalnych potwierdzonych problemów w ocenie V8. Główny model Gemini znalazł 47, a Claude Opus 4.6 — 36 w opisanej konfiguracji.
Benchmarki dostawców wymagają ostrożności, ponieważ konfiguracje modeli i zasady bezpieczeństwa się różnią. Google zauważa również, że część wyników konkurentów została zgłoszona przez nich samych.
Mimo to kierunek jest jasny. Największe firmy technologiczne budują systemy łączące skanowanie z walidacją i naprawą.
Wskaźnik wykorzystania na poziomie 1,3 procent nie unieważnia tych inwestycji. Przesuwa ich uzasadnienie od liczenia błędów ku skracaniu czasu między wiarygodnym dowodem a wdrożoną obroną.
Odkrywanie jest tanie, lecz wykorzystanie nadal pozostaje łańcuchem
Kluczowa zmiana polega na tym, że AI osłabiła wąskie gardło odkrywania, nie eliminując wąskiego gardła wykorzystania.
Współczesne bazy kodu zawierają miliony linii, zewnętrzne zależności, stare interfejsy i nieudokumentowane założenia. Agenci AI mogą podzielić tę przestrzeń poszukiwań i równolegle testować wiele hipotez.
Anthropic podał, że niezależne firmy bezpieczeństwa oceniły 1 752 kandydatów o wysokiej lub krytycznej wadze z jego skanów open source. Spośród nich 1 587 było prawidłowymi trafieniami.
Wskaźnik walidacji na poziomie 90,6 procent sugeruje, że system wygenerował więcej niż losowy szum w przeanalizowanym podzbiorze. Recenzenci potwierdzili 1 094 przypadki jako podatności o wysokiej lub krytycznej wadze.
Wyniki te wspierają twierdzenia Anthropic dotyczące odkrywania. Nie dowodzą jednak, że każdy pozostały nieprzeanalizowany kandydat przejdzie analizę ekspertów z takim samym wskaźnikiem.
Nie pokazują też, że potwierdzone błędy są równie użyteczne dla atakujących. Wykorzystanie zależy od dłuższego i mniej przewidywalnego łańcucha.
Po pierwsze, atakujący musi zrozumieć podatny komponent i ustalić, czy osiągalne cele go używają. Błąd w bibliotece ma niewielką wartość, gdy dotknięte ścieżki kodu pozostają wyłączone.
Po drugie, atakujący musi kontrolować wymagane dane wejściowe. Niektóre błędy są osiągalne przez publiczne żądanie, podczas gdy inne wymagają uwierzytelnienia lub wykonania lokalnego.
Po trzecie, wykorzystanie musi przynieść wartościowy efekt. Doprowadzenie do awarii usługi znacząco różni się od wykonania kodu, kradzieży poświadczeń czy przekroczenia granicy zaufania.
Po czwarte, exploit musi tolerować różnice między wersjami oprogramowania i ustawieniami wdrożenia. Niestabilna technika może ujawnić atakującego, zanim zapewni użyteczny dostęp.
Wreszcie atakujący musi zintegrować exploit z operacją. Wymaga to infrastruktury, wyboru celów, utrzymania dostępu, eskalacji uprawnień i metod usuwania śladów.
AI może pomagać na każdym etapie, lecz pomoc nie jest równoznaczna z autonomią. Model może wygenerować wiarygodnie wyglądający kod, który zawodzi po zmianie szczegółów środowiska.
Modele mają również trudności z właściwą kalibracją pewności. Amazon stwierdził, że jego model generujący reguły pozytywnie oceniał niemal każdego kandydata, dopóki osobny moduł oceniający nie przeanalizował wyniku.
Ta sama tendencja wpływa na badania nad podatnościami. Model może opisać alarmującą ścieżkę, pomijając warunek, który czyni ją niemożliwą w środowisku produkcyjnym.
Anthropic próbował zaradzić tej słabości poprzez niezależną walidację. Zgłoszony przez firmę odsetek trafień prawdziwie pozytywnych wskazuje, że starannie zaprojektowane narzędzia i ekspercka ocena mogą ograniczać znaczny szum informacyjny.
Jednak taki przegląd tworzy nowe ograniczenie przepustowości. Każde poważne znalezisko wymaga odtworzenia, analizy wpływu, komunikacji z opiekunami projektu, poprawki oraz testów wdrożeniowych.
Anthropic podał, że załatanie znaleziska Mythos o wysokiej lub krytycznej wadze zajmuje średnio dwa tygodnie. Niektórzy opiekunowie projektów prosili firmę o spowolnienie ujawnień, ponieważ nie dysponowali wystarczającą przepustowością do ich weryfikacji.
W tym miejscu ciężar bezpieczeństwa się przesuwa. Odkrycia maszynowe zwiększają kolejkę, lecz to ludzkie instytucje nadal decydują, jak szybko kolejka ta przełoży się na bezpieczniejsze oprogramowanie.
Projekty open source mierzą się z największą dysproporcją. Szeroko używane pakiety często zależą od niewielkich zespołów, które nie są w stanie obsłużyć setek złożonych, prywatnych zgłoszeń.
Zespoły korporacyjne mają lepszą kontrolę nad własnymi repozytoriami. Anthropic poinformował, że użytkownicy Claude Security załatali ponad 2 100 luk w ciągu pierwszych trzech tygodni działania produktu.
To twierdzenie sugeruje, że własność i dostęp do wdrożeń mogą skracać czas remediacji. Nie pokazuje jednak, jak poważne były te znaleziska ani ile proponowanych poprawek wymagało rewizji.
Mechanizm ten sprzyja zatem organizacjom z dojrzałymi procesami inżynieryjnymi. AI może przyspieszać pracę, gdy zespoły już znają swoje zasoby, właścicieli, zależności i ścieżki wdrażania.
Organizacje ze słabą ewidencją zasobów otrzymają więcej znalezisk, nie wiedząc, które systemy mają znaczenie. Skutkiem może być większy backlog i wolniejsze działania wobec rzeczywistych zagrożeń.
Rzeczywiste ryzyko to deficyt triage’u i łatania
Odkrywanie luk przez AI staje się niebezpieczne, gdy liczba znalezisk rośnie szybciej niż zdolność do ich walidacji i usuwania.
Programy bezpieczeństwa już dziś obsługują tysiące wyników skanerów, alertów dotyczących zależności, ostrzeżeń konfiguracyjnych i ustaleń z testów penetracyjnych. AI dodaje kolejne źródło o większej skali i niepewnej kalibracji.
Zespół, który uzna każde znalezisko wygenerowane przez maszynę za pilne, wyczerpie swoich recenzentów. Zespół, który odrzuci dane wyjściowe AI jako szum, może przeoczyć rzadką ścieżkę o wysokim wpływie.
Tworzy to problem precyzji. Obrońcy muszą zidentyfikować niewielki zbiór przypadków łączących techniczną wagę, osiągalne zasoby, zainteresowanie atakujących i wiarygodne dowody możliwości wykorzystania.
Tradycyjna ocena wagi luki obejmuje tylko część tej decyzji. Krytyczna wada w odizolowanym systemie testowym może stwarzać mniejsze bezpośrednie zagrożenie niż niżej oceniona wada na wystawionej bramie sieciowej.
Wywiad o zagrożeniach dostarcza dowodów na aktywne skanowanie, publiczny kod exploitów, dyskusje przestępcze i zaobserwowane ataki. Kontekst zasobów pokazuje, czy podatny komponent występuje w wartościowej usłudze.
Najsilniejszy proces łączy te sygnały. Usuwa duplikaty nakładających się znalezisk, weryfikuje osiągalność i przypisuje odpowiedzialność przed przekazaniem pracy inżynierom.
Oparty na ryzyku model zarządzania lukami Google zaleca łączenie wagi luki, znaczenia zasobu i aktualnych dowodów dotyczących zagrożeń.
Model ten odpowiada na główną słabość surowych liczników odkryć. Pyta, które znalezisko zasługuje na działanie w pierwszej kolejności, zamiast nagradzać narzędzia za tworzenie najdłuższej listy.
Dane VulnCheck wzmacniają to podejście. W pierwszej połowie 2026 roku firma zidentyfikowała 495 znanych aktywnie wykorzystywanych luk na szerszym rynku oprogramowania.
Systemy zarządzania treścią odpowiadały za około jedną trzecią tych przypadków. Urządzenia brzegowe sieci również pozostawały częstym celem.
Produkty te przyciągają atakujących, ponieważ są osiągalne, szeroko wdrożone i wartościowe jako punkt początkowego dostępu. Ekonomika ich wykorzystania często przewyższa ekonomikę wykorzystania mało znanych komponentów wewnętrznych.
Liderzy bezpieczeństwa nie powinni interpretować wyników AI jako przyzwolenia na opóźnianie łatania. Powinni natomiast rozróżniać trzy odrębne kolejki.
Pierwsza kolejka obejmuje potwierdzone aktywne wykorzystanie. Takie wady wymagają natychmiastowego ograniczenia skutków, wykrywania i usunięcia, ponieważ zagrożenie już istnieje.
Druga obejmuje zwalidowane, osiągalne luki z wiarygodnymi ścieżkami wykorzystania. Zespoły powinny je szybko łatać nawet bez zaobserwowanych ataków.
Trzecia obejmuje niezwalidowane kandydaty lub znaleziska dotyczące nieosiągalnych zasobów. One również wymagają przeglądu, lecz nie powinny wypierać zagrożeń popartych dowodami.
Taka struktura zapobiega spłaszczeniu fali odkryć, która wrzuca każdy problem do jednego koszyka wag. Daje też opiekunom projektów możliwą do obrony podstawę do negocjowania harmonogramów ujawnień.
Za niskim odsetkiem wykorzystania kryje się jeszcze jedno ryzyko. Liczba bezwzględna może znacznie wzrosnąć, nawet jeśli procent pozostanie stabilny.
Jeśli AI wygeneruje dziesięć razy więcej prawidłowych luk, stały wskaźnik wykorzystania nadal oznacza dziesięć razy więcej aktywnie wykorzystywanych przypadków. Procenty mogą ukrywać ten efekt skali.
Przeanalizowane dane odzwierciedlają również wczesny okres. Atakujący potrzebują czasu, by zaadaptować nowe narzędzia, zbudować niezawodne środowiska testowe i zintegrować je z systemami rozpoznania.
Publiczny dostęp do najpotężniejszego cybermodelu Anthropic pozostaje ograniczony. To ograniczenie redukuje zakres wniosków, jakie obecne dane o wykorzystaniu mogą ujawnić na temat powszechnego nadużycia.
Anthropic przyznaje, że nie stworzył jeszcze zabezpieczeń wystarczająco silnych dla ogólnego dostępu do Mythos. Firma ogranicza dystrybucję, jednocześnie rozszerzając kontrolowane programy defensywne.
Podejście to ogranicza natychmiastową ekspozycję, ale tworzy wyzwanie pomiarowe. Ograniczony model nie może pokazać, jak zachowywałyby się zwykłe grupy przestępcze przy równoważnych możliwościach.
Sceptyczny wniosek musi zatem pozostać wąski. Obecne dowody nie wskazują, że luki odkryte przez AI są z natury bardziej narażone na wykorzystanie.
Nie dowodzą też, że przyszłe systemy utrzymają ten sam stosunek. Nie mogą również zagwarantować, że całe istniejące wykorzystanie zostało odkryte lub publicznie przypisane.
Najlepszą odpowiedzią polityczną nie jest ani panika, ani samozadowolenie. Jest nią budowanie systemów weryfikacji i łatania, które mogą się skalować, zanim dostęp do zaawansowanych cybermodeli się rozszerzy.
Wyspecjalizowany model Google podnosi pułap możliwości
Najnowszy cybermodel Google pokazuje, dlaczego dzisiejszy uspokajający wskaźnik wykorzystania nie może służyć jako trwała prognoza.
Gemini 3.5 Flash Cyber to lekki model dostrojony do odkrywania, walidacji i generowania poprawek luk. Google planuje ograniczony dostęp za pośrednictwem CodeMender dla rządów i zaufanych partnerów.
Projekt modelu kładzie nacisk na powtarzalną, tańszą eksplorację zamiast polegania na jednym wywołaniu większego modelu ogólnego przeznaczenia. Wiele agentów analizuje ścieżki kodu, zanim połączy swoje ustalenia.
Google twierdzi, że podejście to pasuje do złożonych repozytoriów, w których przestrzeń przeszukiwania przekracza możliwości pojedynczego przebiegu analizy. Wspiera też częste skanowanie podczas commitów i wydań.
Firma podała bardziej uderzający wynik wewnętrznego testu. Gemini 3.5 Flash Cyber przeanalizował systemy Google Cloud i w ciągu dwóch godzin znalazł luki umożliwiające zdalne wykonanie kodu w publicznych API.
Google twierdzi, że model znalazł również problem uszkodzenia pamięci we wrażliwej usłudze produkcyjnej. Następnie wygenerował w pełni niezawodny exploit w testowanych warunkach.
Według wyników cybermodelu Google exploit ten ominął zabezpieczenia Address Space Layout Randomization i Write XOR Execute.
Address Space Layout Randomization zmienia lokalizacje w pamięci, aby utrudniać ataki. Write XOR Execute uniemożliwia jednoczesne zapisywanie i wykonywanie pamięci.
Ominięcie obu mechanizmów wymaga czegoś więcej niż rozpoznania podejrzanego kodu źródłowego. Przybliża system do trudnych etapów walidacji i tworzenia exploitów.
Wynik pozostaje demonstracją zgłoszoną przez firmę w ramach kontrolowanego programu defensywnego. Google nie ujawnił dotkniętych systemów ani wystarczających szczegółów do odtworzenia przez podmioty zewnętrzne.
Mimo to osłabia on wszelkie uspokajające twierdzenia, że wykorzystanie pozostaje poza zasięgiem obecnych modeli. Lepszy wniosek jest taki, że zdolność do wykorzystania istnieje nierównomiernie i w ograniczonych warunkach.
Google ma również nietypowe przewagi. Jego zespoły bezpieczeństwa mają dostęp do wewnętrznego kodu, kontekstu produkcyjnego, historycznych wyników fuzzingu i szczegółowych baz danych luk.
Informacje te zapewniają agentom lepsze podstawy niż te, którymi dysponowałby zewnętrzny atakujący. Pomagają też firmie weryfikować dane wyjściowe modelu na rzeczywistych systemach.
Atakujący mają inne przewagi. Mogą koncentrować się na wystawionych produktach, wykorzystywać ponownie wyciekły kod źródłowy, analizować poprawki i akceptować wyższy odsetek niepowodzeń.
Kampania ofensywna nie musi rozumieć każdego znaleziska. Potrzebuje jednej niezawodnej ścieżki przeciw wystarczającej liczbie wartościowych celów.
Ta asymetria wyjaśnia, dlaczego wysiłek Amazon i Google w obszarze bezpieczeństwa pozostaje istotny mimo ustaleń VulnCheck. Branża przygotowuje się na rozpowszechnienie możliwości, a nie tylko mierzy obecne ataki.
Project Glasswing daje wybranym organizacjom czas na wzmocnienie krytycznego oprogramowania, zanim systemy klasy Mythos staną się powszechnie dostępne. Google przyjmuje podobne podejście o ograniczonym udostępnianiu.
Kontrolowany dostęp nie może jednak stać się całą strategią. Otwarte modele, wyspecjalizowane narzędzia i ulepszone frameworki agentowe będą nadal zmniejszać lukę w możliwościach.
Obrońcy potrzebują zatem systemów, które nieustannie ograniczają ekspozycję. Skanowanie przed wydaniem przynosi większą wartość niż dodawanie kolejnego alertu po tym, gdy podatny kod trafi do produkcji.
Automatyczne propozycje poprawek mogą skrócić czas remediacji, ale ludzie muszą przeglądać zmiany dotyczące uwierzytelniania, obsługi pamięci, kryptografii i granic zaufania.
Zwycięska architektura defensywna łączy odkrywanie przez model z odtwarzalnymi dowodami. Następnie łączy dowody z przetestowanymi poprawkami, odpowiedzialnością za wdrożenie i telemetrią ataków.
To standard bardziej wymagający niż liczenie luk. Jest też standardem najściślej powiązanym z mierzalnymi rezultatami w zakresie bezpieczeństwa.
Trzy sygnały pokażą, czy równowaga się zmienia
Następna faza będzie mierzona poprzez dowody wykorzystania, przepustowość remediacji i dostęp do wyspecjalizowanych cybermodeli.
Pierwszym sygnałem jest odsetek luk przypisanych AI, które trafiają do katalogów znanego aktywnego wykorzystania. Obecny wynik VulnCheck wynoszący 1,3 procent ustanawia użyteczny wczesny punkt odniesienia.
Trwały wzrost powyżej szerszego wskaźnika luk wzmocniłby twierdzenia, że AI tworzy wyjątkowo atrakcyjne cele. Stabilny wskaźnik wspierałby interpretację opartą na wolumenie odkryć.
Jakość atrybucji ma tu znaczenie. Badacze muszą odróżniać luki znalezione przez AI od exploitów opracowanych z pomocą AI po tym, jak człowiek lub konwencjonalny skaner wykrył słabość.
To różne możliwości o odmiennych konsekwencjach politycznych. Słabe oznaczanie może sprawić, że każda strona debaty wyda się silniejsza, niż pozwalają na to dowody.
Drugim sygnałem jest publiczny rejestr remediacji Project Glasswing. Czytelnicy powinni obserwować, ile kandydatów staje się zwalidowanymi komunikatami, poprawkami, CVE lub zamkniętymi fałszywymi alarmami.
Aktualizacja Glasswing Anthropic poinformowała o silnych wynikach walidacji dla przeanalizowanego podzbioru. Jednak szerszy backlog kandydatów pozostawał znacznie większy niż publiczna liczba CVE.
Szybsze tempo łatania pokazałoby, że systemy ujawniania i remediacji nadrabiają tempo odkryć. Rosnący backlog potwierdziłby, że przepustowość ludzka stała się głównym ograniczeniem bezpieczeństwa.
Jakość poprawek jest równie ważna jak ich liczba. Pochopne poprawki mogą wprowadzać regresje, pozostawiać otwarte alternatywne ścieżki ataku lub ujawniać wystarczająco dużo informacji, by atakujący mogli odtworzyć exploit.
Badacze powinni zatem śledzić wdrożenie i weryfikację, a nie tylko publikowanie poprawek. Poprawka chroni użytkowników dopiero wtedy, gdy opiekunowie projektu ją wydadzą, a operatorzy ją zainstalują.
Trzecim sygnałem jest szerszy dostęp do Mythos, Gemini Flash Cyber lub porównywalnych wyspecjalizowanych modeli. Anthropic i Google obecnie ograniczają dostęp do swoich najbardziej wrażliwych możliwości.
Szersza dostępność stworzyłaby pierwszy znaczący test tego, jak zaawansowani agenci cybernetyczni zachowują się w większej populacji. Zwiększyłaby też presję na zabezpieczenia i weryfikację tożsamości.
Jeśli dostęp się rozszerzy bez wzrostu potwierdzonych przypadków wykorzystania, obecna weryfikacja rzeczywistości zyska na sile. Jeśli wykorzystanie szybko wzrośnie, dzisiejszy niski wskaźnik będzie wyglądał na opóźnienie w adopcji.
Amazon, Google i ich partnerzy powinni również publikować więcej wskaźników opartych na wynikach. Przydatne metryki obejmują zweryfikowane ustalenia, czas do wdrożenia poprawki, wdrożone poprawki oraz udaremnione ataki.
Łączne liczby kandydatów nadal są przydatne do oceny zasięgu wyszukiwania. Nie wystarczają jednak do zmierzenia, czy program bezpieczeństwa zmniejszył praktyczne ryzyko.
Dla deweloperów lekcja jest taka, by wymagać od narzędzi bezpieczeństwa AI powtarzalnych dowodów. Ustalenie powinno obejmować dotknięty kod, osiągalne warunki, wpływ oraz możliwe do przetestowania rozwiązanie.
Dla nabywców korporacyjnych priorytetem jest integracja z istniejącymi zasobami i procesami pracy. Narzędzie, które generuje więcej alertów bez przypisanej odpowiedzialności lub kontekstu, może zwiększać ryzyko operacyjne.
Dla opiekunów projektów open source większej uwagi wymagają tempo ujawniania informacji oraz finansowana zdolność do przeprowadzania przeglądów. Systemy AI potrafią dziś generować pracę znacznie szybciej, niż społeczności wolontariuszy są w stanie ją przyswoić.
Koalicja Amazon Google ds. bezpieczeństwa reaguje na wiarygodne przyszłe zagrożenie. Obecne dowody wskazują jednak, że bezpośrednim kryzysem jest przeciążony defensywny proces obsługi, a nie automatyczne masowe wykorzystanie.
To rozróżnienie powinno kształtować wydatki, projektowanie produktów i politykę. Zespoły potrzebują mniej niesklasyfikowanych alertów i więcej zweryfikowanych ścieżek od wykrycia po usunięcie problemu.
W nadchodzących miesiącach warto obserwować wskaźnik wykorzystania, zaległości w stosowaniu poprawek oraz dostęp do wyspecjalizowanych modeli. Łącznie sygnały te pokażą, czy AI zmienia ekonomię ataków, czy głównie zwiększa wolumen wykryć.
Praktyczne pytanie dla każdego zespołu bezpieczeństwa jest proste: czy Twoja organizacja potrafi zweryfikować i naprawić najistotniejsze ustalenia, zanim większa kolejka je ukryje?
