Microsoft w popłochu, gdy Mythos od Anthropic zasypuje inżynierów lukami bezpieczeństwa

Microsoft rozpoczął „gorączkowy wyścig”, gdy Mythos od Anthropic wykrywał setki luk bezpieczeństwa szybciej, niż jego inżynierowie mogli je naprawiać. Sprawa wyszła na jaw dzięki zestawieniu w Google News, lecz stojące za nią doniesienia opisują znacznie większy problem. AI może dziś przyspieszać wykrywanie podatności ponad tempo, w jakim ludzie są w stanie je usuwać.

Natychmiastowa presja spadła na zespoły odpowiedzialne za SharePoint, Microsoft 365, Teams i Copilot. Wewnętrzne dokumenty przeanalizowane przez ProPublica wskazywały, że w połowie maja wiele ustaleń o wysokim priorytecie wciąż pozostawało nierozwiązanych. Tradycyjny triage bezpieczeństwa nagle zaczął wyglądać na mniej wiarygodny, ponieważ Mythos potrafi łączyć kilka drobnych błędów w poważną ścieżkę ataku.

Mozilla stanowi ważne porównanie. Jej zespół Firefox również otrzymał falę ustaleń od Mythos, jednak każda istotna poprawka nadal wymagała ludzkiego autora i recenzenta. Nowym wąskim gardłem nie jest już znajdowanie podejrzanego kodu. Jest nim weryfikowanie każdego ustalenia, zrozumienie jego kontekstu, stworzenie bezpiecznej poprawki, przetestowanie jej i wdrożenie, zanim atakujący odtworzą tę samą pracę.

Co faktycznie ujawniły dokumenty Microsoftu

Mythos zmienił wykrywanie podatności z okresowego ćwiczenia bezpieczeństwa w nieprzerwaną kolejkę produkcyjną.

W połowie maja dziesiątki inżynierów i menedżerów Microsoftu spotkały się, aby omówić Project Glasswing, kontrolowaną inicjatywę Anthropic w zakresie cyberbezpieczeństwa. Anthropic zapewnił wybranym organizacjom dostęp do Claude Mythos Preview, zanim systemy o podobnych możliwościach staną się powszechnie dostępne.

Według wewnętrznych dokumentów Microsoftu, menedżer powiedział uczestnikom, że Mythos znajduje błędy szybciej, niż Microsoft może je naprawiać. Opisał tę reakcję jako „gorączkowy wyścig”.

Jeden ze slajdów prezentacji pokazywał skalę problemu w SharePoint. Mythos miał podobno odkryć 90 błędów sklasyfikowanych jako krytyczne i 141 sklasyfikowanych jako ważne tylko w kwietniu. Dodatkowe problemy wykrył w pierwszej połowie maja.

Te klasyfikacje mają znaczenie. Microsoft używa określenia „krytyczne” dla podatności, których wykorzystanie może prowadzić do poważnych konsekwencji, w tym samopowielających się ataków. „Ważna” podatność może narazić dane użytkowników lub zakłócić działanie zasobów komputerowych.

Wewnętrzna prezentacja przewidywała, że inżynierowie SharePoint będą zajęci przez wiele miesięcy. Zespoły planowały najpierw zająć się krytycznymi ustaleniami, później ważnymi, a następnie około 300 ustaleniami o umiarkowanym poziomie zagrożenia.

Dokumenty opisywały również setki krytycznych lub ważnych błędów w Microsoft 365, Teams i Copilot. Według doniesień większość z nich w połowie maja nadal nie miała poprawek. Microsoft odmówił ujawnienia, ile ustaleń Mythos naprawił po prezentacji.

Ustalenia nie musiały dotyczyć spektakularnych, całkowicie nowych klas ataków. Menedżer ds. inżynierii miał podobno scharakteryzować wiele z nich jako zwyczajne, lecz rzeczywiste podatności. Ten szczegół sprawia, że wydarzenie jest bardziej, a nie mniej istotne.

Produkty programistyczne gromadzą zwyczajne błędy przez lata rozwoju funkcji, decyzji dotyczących kompatybilności i odziedziczonych komponentów. Ludzcy badacze bezpieczeństwa mają ograniczony czas na analizę tej powierzchni. Model, który potrafi stale badać kod, ujawnia słabości pozostające ukryte częściowo dlatego, że nikt nie miał wystarczającej uwagi, by je znaleźć.

Microsoft poinformował, że jego decyzje dotyczące bezpieczeństwa uwzględniają możliwość wykorzystania podatności i potencjalny wpływ na klientów. Firma stwierdziła również, że przyspieszone wykorzystywanie luk nie jest nowym zjawiskiem, jednocześnie przyznając, że sytuacja budzi silne poczucie pilności.

Oba stwierdzenia mogą być prawdziwe. Zespoły bezpieczeństwa zawsze ścigały się z atakującymi po ujawnieniu podatności. Zmieniła się liczba wyścigów, które mogą rozpocząć się jednocześnie.

Microsoft miał podobno udostępnić dostęp do Mythos około 50 pracownikom zatrudnionym na pełen etat. Ta ograniczona grupa mogła wygenerować kolejkę wystarczająco dużą, by zajmować zespoły produktowe przez miesiące. Porównywalne narzędzia w rękach większej liczby badaczy, klientów i przeciwników zwielokrotniłyby napływ zgłoszeń.

Dlatego ta historia zasługuje na więcej uwagi, niż sugeruje jej ujęcie w Google News. Microsoft nie mierzy się z jedną groźną luką zero-day, czyli nieznaną wcześniej podatnością możliwą do wykorzystania. Mierzy się z systemem produkcyjnym, który może wielokrotnie odkrywać nowych kandydatów w ogromnych bazach kodu.

System ten nie potrzebuje odpoczynku, luk w harmonogramie ani osobistej motywacji. Może kontynuować poszukiwania, dopóki organizacja zapewnia zasoby obliczeniowe i skuteczne środowisko testowe.

Rezultatem jest strukturalna nierównowaga. Wykrywanie zaczęło skalować się jak oprogramowanie, podczas gdy usuwanie problemów nadal skaluje się głównie dzięki pracy wykwalifikowanych ludzi.

Dlaczego uwaga Google News zaniża skalę zmiany w bezpieczeństwie

Kluczowy paradoks polega na tym, że lepsze wykrywanie po stronie obrońców może tymczasowo sprawiać, iż dostawcy oprogramowania wyglądają na mniej bezpiecznych.

Anthropic uruchomił Project Glasswing, aby dać wybranym obrońcom czas na znalezienie i naprawę słabości, zanim podobne możliwości szeroko się rozpowszechnią. Microsoft dołączył do tego przedsięwzięcia i udostępnił Mythos zatwierdzonym klientom Project Glasswing za pośrednictwem Microsoft Foundry.

Takie rozwiązanie dało obrońcom przewagę czasową. Jednak jej wartość jest ograniczona, gdy model generuje ustalenia szybciej, niż zespoły są w stanie je przetworzyć.

Konwencjonalny program bezpieczeństwa traktuje wykrywanie jako ograniczony zasób. Organizacje przeprowadzają testy, przyjmują zgłoszenia zewnętrzne i porządkują powstałą kolejkę. Najgroźniejsze podatności otrzymują natychmiastową uwagę, a ustalenia o niższej wadze czekają.

Claude Mythos Preview zmienił stronę podażową tego procesu. Panel ujawnień Anthropic zgłaszał 23 019 potencjalnych ustaleń na dzień 22 maja. Zewnętrzne firmy bezpieczeństwa przeanalizowały 1 900 z nich, potwierdzając 1 726 jako prawidłowe.

Anthropic ujawnił 1 596 podatności w 281 projektach open source. W tym momencie tylko 97 było wymienionych jako naprawione u źródła. Anthropic wyraźnie wskazał ludzki triage i przegląd jako etap ograniczający tempo prac.

Dane te obejmują prace open source śledzone przez Anthropic, a nie prywatną kolejkę Microsoftu. Mimo to ilustrują ten sam mechanizm. Model generuje kandydatów w jednym tempie, zewnętrzni eksperci weryfikują ich w drugim, a opiekunowie projektów wprowadzają poprawki w trzecim.

Potencjalne ustalenie nie jest automatycznie podatnością możliwą do wykorzystania. Recenzenci muszą odtworzyć zachowanie, wyeliminować fałszywe alarmy, ocenić realistyczne warunki ataku i ustalić, czy dotknięty kod jest osiągalny.

Nawet prawidłowy błąd może pozostawać poza modelem zagrożeń projektu. Inne mogą powielać znane zgłoszenia. Dopracowane wyjaśnienie wygenerowane przez AI nie eliminuje potrzeby inżynierskiej oceny.

Mythos nie tworzy jednak jedynie znanej fali nieprecyzyjnych, niskiej jakości zgłoszeń AI. Wśród ustaleń Anthropic przeanalizowanych zewnętrznie zgłoszony odsetek prawdziwych trafień wyniósł 90,8%. Wskaźnik ten pochodził od firm bezpieczeństwa zatrudnionych przez Anthropic, a nie od wszystkich dotkniętych opiekunów projektów, dlatego nie należy traktować go jako uniwersalnego dowodu.

Skala ustaleń jest jednak wystarczająco duża, by zmienić zachowanie organizacji. Zespoły bezpieczeństwa muszą przygotować się na większą liczbę prawidłowych zgłoszeń obok fałszywych alarmów, duplikatów i problemów, które nie mogą wyrządzić istotnej szkody.

Presja staje się szczególnie dotkliwa, gdy dostawcy utrzymują produkty z dekadami nagromadzonego kodu. Starsze komponenty często zawierają założenia, które miały sens w poprzednich architekturach. Nowoczesne funkcje mogą wystawiać te założenia na nowe dane wejściowe i ścieżki ataku.

Skala Microsoftu potęguje problem. Windows, Microsoft 365, SharePoint, Teams i Azure działają w administracji publicznej, szkołach, szpitalach i firmach. Błąd w szeroko wdrożonym komponencie daje atakującym większy potencjalny zysk.

Popularność zwiększa także obciążenie po stronie obrony. Inżynierowie muszą oceniać wiele wersji produktów, konfiguracji chmurowych, mechanizmów kontroli dostępu i środowisk klientów. Poprawka zamykająca jedną słabość nie może zakłócić istniejących wdrożeń ani stworzyć kolejnej podatności.

Ta sama AI, która odkrywa błąd, nie potrafi jeszcze zagwarantować bezpiecznej naprawy produkcyjnej. Generowanie wiarygodnego kodu różni się od rozumienia każdej zależności i konsekwencji operacyjnej.

To rozróżnienie zwykle znika w streszczeniach Google News o AI znajdującej tysiące błędów. Liczba w nagłówku mierzy zdolność wykrywania. Nie mierzy, ile ustaleń da się wykorzystać, ile poprawek jest bezpiecznych ani jak szybko klienci instalują te poprawki.

Gorączkowa reakcja Microsoftu odzwierciedla więc jednocześnie sukces i porażkę. Mythos zapewnia obrońcom widoczność, której wcześniej nie mieli. Ta widoczność ujawnia również, jak wiele nierozwiązanej pracy związanej z bezpieczeństwem już istniało.

Tradycyjny triage zawodzi, gdy drobne błędy tworzą łańcuchy ataku

AI podważa założenie, że każdą podatność można priorytetyzować jako odizolowany problem.

Triage bezpieczeństwa zwykle klasyfikuje ustalenia według ich prawdopodobnego wpływu i możliwości wykorzystania. Luka możliwa do zdalnego wykorzystania, która daje atakującemu kontrolę, zasługuje na większą uwagę niż lokalny błąd o ograniczonych konsekwencjach.

Ta hierarchia pozostaje konieczna. Żadna firma nie może natychmiast naprawić każdego defektu oprogramowania. Microsoft przetwarza co roku tysiące zgłoszeń podatności, zgodnie ze swoim planem reagowania na zagrożenia.

Komplikacją jest łączenie podatności, technika zestawiająca oddzielne słabości w jeden atak. Wyciek informacji o niskiej wadze może ujawnić dane potrzebne do wykorzystania błędu kontroli dostępu. Kolejna wada może następnie pomóc atakującemu wydostać się z ograniczonego środowiska.

Rozpatrywane osobno, takie błędy mogą wyglądać na akceptowalne. Razem mogą stworzyć ścieżkę do wrażliwych danych lub kontroli nad systemem.

Vinh Nguyen, starszy doradca techniczny w Anthropic i stypendysta Council on Foreign Relations, ostrzegł, że cztery błędy niskiego poziomu mogą połączyć się w rezultat o wysokiej wadze. Argumentował, że obecna strategia triage Microsoftu może zbyt nisko wyceniać to ryzyko.

Microsoft odpowiedział, że łączenie podatności od dawna stanowi część jego oceny luk. Ta odpowiedź dotyczy tego, czy firma rozumie tę technikę. Nie rozstrzyga jednak w pełni, czy jej kadry, modele i procesy naprawcze mogą oceniać łańcuchy w szybko rosnącej kolejce.

Ludzcy recenzenci mają trudność z uwzględnieniem każdej możliwej relacji między setkami ustaleń. Liczba kombinacji szybko rośnie wraz z rozmiarem kolejki. System taki jak Mythos może wielokrotnie przeszukiwać te kombinacje i tworzyć wieloetapowe demonstracje.

To sprawia, że niezałatane ustalenia o umiarkowanej wadze trudniej jest odrzucić. Ich indywidualna powaga może pozostać umiarkowana, lecz ich wartość zmienia się, gdy inny błąd dostarcza brakujący krok.

Wyzwanie to podważa również statyczne oceny wagi. Praktyczne ryzyko podatności zależy od warunków wdrożenia, dostępnych uprawnień, osiągalnych usług i jej interakcji z innymi słabościami.

Microsoft stwierdził, że stale ponownie ocenia, czy problemy o niższym priorytecie powinny otrzymać wyższą klasyfikację. Takie adaptacyjne podejście staje się niezbędne, gdy AI odkrywa nowe zależności szybciej, niż zespoły przeglądowe potrafią je zmapować.

Firma dodaje automatyzację, aby weryfikować jakość i wagę ustaleń. Planuje także osadzić oparte na agentach testy bezpieczeństwa w procesie rozwoju, tak aby inżynierowie mogli wykrywać podatności podczas pisania kodu.

Przeniesienie wykrywania na wcześniejszy etap ma sens. Programista, który nadal rozumie zmieniony komponent, często może naprawić go skuteczniej niż odległy zespół reagujący na incydenty kilka miesięcy później. Wcześniejsze testowanie zmniejsza też liczbę wydanych wersji wymagających poprawek.

Jednak przeniesienie Mythos do etapu rozwoju nie eliminuje zaległości w istniejącym oprogramowaniu. Microsoft musi zabezpieczać obecne produkty, jednocześnie zmieniając proces tworzenia przyszłych wersji.

Musi też unikać automatyzowania błędnych ocen. Agent triage, który zawyża wagę każdego znaleziska, wyczerpuje możliwości zespołów inżynieryjnych. Taki, który zaniża znaczenie użytecznego ogniwa w łańcuchu ataku, tworzy fałszywe poczucie bezpieczeństwa.

Organizacje będą potrzebować raportów bogatych w dowody, obejmujących odtwarzalne zachowanie, dotknięte konfiguracje, realistyczne warunki wstępne ataku oraz proponowane poprawki. Potrzebują też trwałego zapisu łączącego każde znalezisko z decyzjami projektowymi, testami i późniejszymi incydentami.

Dla zespołów inżynieryjnych przeszukiwalna baza wiedzy może zachować ten kontekst między kodem, notatkami z incydentów i dokumentami technicznymi. Nie może zdecydować o wadze podatności, ale może ograniczyć wysiłek potrzebny do odtworzenia wcześniejszych decyzji.

Prawdziwa rywalizacja nie toczy się więc między Mythos a inżynierami Microsoftu. Chodzi o wykrywanie z szybkością maszyn kontra system organizacyjny oparty na wolniejszych raportach, indywidualnie poddawanych weryfikacji.

Microsoft może niemal natychmiast kupić większą moc obliczeniową. Znacznie dłużej trwa powiększenie grona doświadczonych inżynierów, którzy rozumieją starszy komponent.

Mozilla pokazuje, dlaczego naprawy wciąż wymagają ludzkich inżynierów

Firefox pokazuje, że AI może zwielokrotnić liczbę użytecznych odkryć bez automatyzowania najtrudniejszej części usuwania problemów.

Doświadczenia Mozilli zapewniają najjaśniejsze publiczne porównanie, ponieważ jej inżynierowie opisali zarówno korzyści, jak i obciążenie pracą.

W kwietniu 2026 roku Firefox wydał 423 poprawki błędów, w porównaniu z 31 w kwietniu 2025 roku. Mythos pomógł wykryć podatności o wysokiej wadze, w tym błędy, które pozostawały w przeglądarce przez ponad dekadę.

Model miał wykryć problemy w sandboxie Firefoksa, warstwie izolacji mającej ograniczać szkody powodowane przez złośliwy kod. Podatności sandboxa są szczególnie cenne, ponieważ ich wykorzystanie często wymaga kreatywnej sekwencji działań.

Inżynierowie Mozilli powiedzieli badaczom bezpieczeństwa Firefoksa, że najnowsze systemy znacznie poprawiły się względem wcześniejszych narzędzi AI do skanowania. Lepsze przepływy pracy agentów mogły testować potencjalne znaleziska i odfiltrowywać część słabych wyników przed zgłoszeniem.

Mozilla nie pozwalała jednak AI wdrażać wynikowych poprawek. Każdy istotny błąd nadal wymagał, by jeden inżynier napisał poprawkę, a drugi ją zrecenzował.

Zespół prosił AI o proponowanie poprawek, ale wyniki te zwykle służyły jako punkty wyjścia. Nie były gotowymi do produkcji zamiennikami ludzkiej pracy.

Ta luka wyjaśnia zaległości Microsoftu. Znalezienie podejrzanej ścieżki kodu jest jednym, ograniczonym zadaniem. Naprawa szeroko wdrożonego produktu korporacyjnego wymaga większego łańcucha odpowiedzialności.

Inżynier musi potwierdzić zgłoszenie względem właściwej wersji oprogramowania. Zespół musi ustalić, czy wada dotyczy usług chmurowych, instalacji lokalnych, czy obu. Musi stworzyć testy regresji i sprawdzić sąsiednie komponenty.

Poprawka przechodzi następnie przez przegląd, integrację, testy jakościowe, przygotowanie wydania i komunikację z klientami. Wrażliwe szczegóły muszą pozostać pod kontrolą, dopóki klienci nie mogą zainstalować ochrony.

Duzi dostawcy stoją przed dodatkowym ograniczeniem. Aktualizacja zabezpieczeń może wywołać problemy operacyjne w niezliczonych środowiskach. Pośpiech przy wdrażaniu poprawki może zamienić jedno ryzyko bezpieczeństwa na przestoje, uszkodzone dane lub problemy ze zgodnością.

Systemy AI do programowania mogą pomagać w kilku punktach. Mogą proponować testy, identyfikować powiązane funkcje, podsumowywać historię zmian i porównywać potencjalne poprawki. Żadne z tych działań nie przenosi odpowiedzialności z inżynierów.

Wcześniejsze badania własne Microsoftu wzmacniają to ograniczenie. Badanie z 2025 roku wykazało, że wiodące modele nadal miały trudności z debugowaniem wielu zadań w SWE-bench Lite, benchmarku zbudowanym na rzeczywistych problemach oprogramowania. Badacze twierdzili, że modele potrzebują bogatszych danych interakcyjnych pokazujących, jak agenci korzystają z debuggerów przed proponowaniem poprawek.

Modele cyberbezpieczeństwa szybko poprawiły się po tym badaniu, ale walidacja pozostaje kluczowa. Rzeczywiste środowiska zawierają nieudokumentowane zachowania i ograniczenia biznesowe, których benchmarki nie mogą w pełni odzwierciedlić.

Krajobraz konkurencyjny również się poszerza. OpenAI opracowało modele skoncentrowane na cyberbezpieczeństwie, podczas gdy Microsoft opisał wielomodelowy system bezpieczeństwa, który wykrył 16 podatności w komponentach sieciowych i uwierzytelniających Windows.

Palo Alto Networks miało znaleźć 75 błędów podczas testowania modeli Anthropic i OpenAI, wobec typowego miesięcznego zakresu od pięciu do dziesięciu. Jego badacze nadal obserwowali odsetek wyników fałszywie dodatnich bliski 30% w różnych produktach, zanim dostrojenie do środowiska poprawiło rezultaty.

Opiekun projektu Curl, Daniel Stenberg, zgłosił skromniejszy wynik. Mythos znalazł jeden błąd o niskiej wadze, kilka wyników fałszywie dodatnich oraz inny problem, który projekt uznał za nieistotny.

Przypadki te nie pozwalają wyciągnąć prostego wniosku, że Mythos zawsze przytłacza każdy cel. Wyniki zależą od bazy kodu, narzędzi, promptów, dostępnego kontekstu i ludzkiego operatora.

Microsoft ma też znacznie większą i bardziej zróżnicowaną powierzchnię produktową niż jeden projekt open source. Zalew zgłoszeń dotyczących SharePoint, Microsoft 365, Teams i Copilot może jednocześnie obciążyć kilka wyspecjalizowanych zespołów.

Niepewność ma znaczenie, ponieważ Anthropic kontroluje dużą część publicznych danych o wydajności. Niezależni opiekunowie projektów i partnerzy testowi dostarczyli cennych dowodów, ale żaden wspólny audyt nie mierzy jeszcze jakości wykrywania, czasu usuwania problemów i wyników produkcyjnych u różnych dostawców.

Panel Anthropic zlicza również rzeczywiste błędy, które mogą być już znane lub których opiekunowie zdecydują się nie naprawiać. Jego wskaźnika trafności nie należy mylić z odsetkiem znalezisk, które stają się poważnymi publicznymi ostrzeżeniami.

Ostrożny wniosek jest nadal istotny. Mythos przekroczył próg, przy którym eksperckie organizacje otrzymują wystarczająco dużo użytecznych znalezisk, by zmienić plany zatrudnienia i wydawania oprogramowania.

Nie przekroczył progu, przy którym model może bezpiecznie zamknąć kolejkę, którą sam tworzy.

Ryzykiem jest zdolność do usuwania problemów, a nie pojedynczy model AI

Najgłębszą podatnością Microsoftu jest luka między skalowalnym wykrywaniem a rzadką wiedzą o produktach.

Oczywista interpretacja przedstawia Anthropic jako pretendenta, a Microsoft jako przytłoczonego dotychczasowego lidera. Ta rywalizacja ma znaczenie, ale może odwracać uwagę od szerszego ograniczenia.

Anthropic chce, aby Mythos pomagał obrońcom zabezpieczać ważne systemy, zanim atakujący uzyskają równoważny dostęp. Microsoft również udostępnia zatwierdzony dostęp przez Foundry. Obie firmy współpracują, nawet gdy model Anthropic ujawnia słabości produktów Microsoftu.

Podstawowy konflikt dotyczy obietnicy obrony z szybkością AI i rzeczywistości usuwania problemów z szybkością ludzi.

Doświadczeni inżynierowie bezpieczeństwa robią więcej niż tylko edytują wadliwy kod. Rozumieją granice systemów, modele zagrożeń, zależności klientów i konsekwencje wydań. Duża część tej wiedzy jest specyficzna dla jednego produktu lub komponentu.

Starszy kod pogłębia niedobór. Oryginalni autorzy mogli odejść. Dokumentacja może pomijać założenia projektowe. Testy mogą obejmować normalne działanie, nie odzwierciedlając wrogich danych wejściowych.

Dług techniczny, czyli skumulowana praca inżynieryjna wynikająca z wcześniejszych kompromisów, staje się długiem bezpieczeństwa, gdy kompromisy te ukrywają zachowania możliwe do wykorzystania. AI może ujawnić ten dług znacznie szybciej, niż organizacja jest w stanie go spłacić.

Wewnętrzne Microsoft Security Response Center historycznie obsługiwało setki lub tysiące zgłoszeń w intensywnych okresach. ProPublica wcześniej informowała o obawach związanych z niedoborem personelu, podczas gdy Microsoft twierdził, że stale ocenia zasoby potrzebne do reagowania na problemy bezpieczeństwa.

Bodźce biznesowe są trudne. Nowe funkcje mogą generować widoczne przychody i zainteresowanie klientów. Utrzymanie bezpieczeństwa zwykle zapobiega stratom, które nigdy nie stają się zauważalne.

Wykrywanie wspierane przez AI utrudnia utrzymanie tej nierównowagi. Każda nowa funkcja rozszerza kod, który maszyny mogą analizować. Każda odroczona refaktoryzacja tworzy dodatkowe interakcje, które przyszłe modele mogą badać.

Obawa wykracza poza Microsoft. Wolontariusze opiekują się bibliotekami open source osadzonymi w produktach komercyjnych i infrastrukturze publicznej. Mały zespół może otrzymać technicznie prawidłowe zgłoszenie, nie mając czasu na jego odtworzenie lub naprawę.

Odpowiedzialne ujawnianie informacji pomaga, opóźniając publikację szczegółów. Nie tworzy jednak możliwości inżynieryjnych. Okno ujawnienia może stać się odliczaniem, którego niedofinansowane projekty nie są w stanie dotrzymać.

Ostrzeżenie Five Eyes stwierdzało, że zaawansowane możliwości AI w zakresie wykrywania podatności będą się rozpowszechniać, i wzywało organizacje do przygotowania się. Znaczenie tego ostrzeżenia leży mniej w jednej przewidywanej dacie, a bardziej w kierunku rozwoju.

Atakujący nie potrzebują dokładnie usługi Mythos. Potrzebują modeli i narzędzi, które potrafią analizować kod, testować hipotezy i łączyć słabości przy coraz mniejszym nakładzie pracy ludzkiej.

Dostęp do kodu źródłowego jest pomocny, ale nie zawsze konieczny. Atakujący mogą analizować komponenty open source, odtwarzać kod z plików binarnych, badać starszy ujawniony kod lub testować wystawione usługi.

Microsoft oświadczył, że jego procesy bezpieczeństwa zakładają, iż zdeterminowani przeciwnicy mogą uzyskać kod. Taki model zagrożeń jest właściwy. Pytanie operacyjne brzmi, czy firma potrafi naprawić wynikające z tego znaleziska, zanim atakujący przekształcą je w niezawodne techniki.

Istnieje też ryzyko nadmiernej reakcji. Jeśli Microsoft skieruje inżynierów do każdego znaleziska AI bez zdyscyplinowanej walidacji, może opóźnić cenną pracę nad bezpieczeństwem i utrzymaniem produktów.

Zespoły potrzebują więc lepszego ustalania priorytetów, a nie rezygnacji z niego. Oceny wagi muszą uwzględniać łańcuchy ataków, rzeczywistą ekspozycję wdrożeń, znane wykorzystanie oraz dostępność środków kompensacyjnych.

Muszą też mierzyć przepustowość usuwania problemów. Zliczanie wykrytych błędów nagradza model za powiększanie kolejki. Zliczanie zamkniętych zgłoszeń może nagradzać pochopne klasyfikacje. Użyteczna metryka musi odzwierciedlać zweryfikowaną redukcję ryzyka bez zachęcania do powierzchownych poprawek.

Przejrzystość wobec klientów będzie mieć znaczenie. Kupujący muszą wiedzieć, czy dostawcy skracają okresy ekspozycji, poprawiają jakość poprawek i ograniczają powracające klasy defektów. Sama duża liczba wykryć nie potwierdza ani postępu, ani porażki.

Cykl informacyjny Google przejdzie do kolejnego ogłoszenia modelu. Kolejka Microsoftu pozostanie, podobnie jak wiedza o produktach i praca testowa potrzebne do jej zamknięcia.

Co obserwować po zakończeniu cyklu informacyjnego Google

Trzy sygnały pokażą, czy Microsoft dostosowuje swój system bezpieczeństwa, czy jedynie przetrwał pierwszą falę Mythos.

Pierwszym sygnałem będzie historia poprawek Microsoftu dla zgłoszonych zaległości SharePoint. Wewnętrzny plan przewidywał miesiące pracy, przy czym ważne znaleziska miały sięgać sierpnia, a błędy o umiarkowanej wadze następować później.

Microsoft nie opublikował pełnej liczby łączącej aktualizacje bezpieczeństwa z odkryciami Mythos. Przyszłe ostrzeżenia mogą ujawnić, czy liczba znalezisk o wysokim priorytecie spada oraz czy powiązane błędy powracają w tych samych komponentach.

Trwałe zmniejszenie liczby takich problemów wspierałoby twierdzenie Microsoftu, że może łączyć wykrywanie przez AI ze skutecznym usuwaniem usterek. Dalsze narastanie wskazywałoby, że zdolność wykrywania wciąż przewyższa przepustowość inżynieryjną.

Drugim sygnałem będzie to, czy Microsoft zmieni sposób klasyfikowania powiązanych podatności. Firma twierdzi, że łączenie już teraz wpływa na analizę ryzyka, ale Mythos może testować kombinacje na skalę, która stanowi wyzwanie dla analizy pojedynczych przypadków.

Wypatruj nowych wytycznych dotyczących poziomu istotności, zautomatyzowanej analizy łańcuchów ataków lub raportów grupujących powiązane luki w ścieżki ataku. Takie zmiany wskazywałyby, że Microsoft przeprojektowuje triage pod kątem rzeczywistych możliwości AI.

Jeśli ustalenia o niższym priorytecie nadal będą czekać bez widocznej analizy powiązań, pozostaną obawy, że ryzyko związane z łańcuchami luk jest zbyt nisko wyceniane.

Trzecim sygnałem będą wyniki konkurencyjnych modeli cyberbezpieczeństwa w niezależnych testach. OpenAI, Microsoft, Anthropic, dostawcy rozwiązań bezpieczeństwa i laboratoria rządowe rozwijają lub oceniają systemy wykrywające podatności.

Porównywalne wyniki kilku modeli potwierdziłyby, że Microsoft mierzy się z ogólnobranżową zmianą możliwości, a nie z tymczasowym wzrostem związanym z jednym podglądem Anthropic. Duże różnice w liczbie fałszywych alarmów lub walidacji exploitów wskazywałyby natomiast, że projekt operacyjny ma równie duże znaczenie jak surowa inteligencja modelu.

Deweloperzy powinni obserwować, czy dostawcy publikują pomiary obejmujące cały proces. Przydatne raportowanie uwzględniałoby zgłoszone potencjalne problemy, potwierdzone podatności, zaakceptowany poziom istotności, medianę czasu naprawy, regresje oraz zasięg wdrożenia.

Kupujący z sektora przedsiębiorstw powinni zadać powiązane pytanie: czy ich dostawcy potrafią przekształcić zautomatyzowane wykrywanie w zweryfikowaną ochronę klientów? Dostawca, który znajduje więcej błędów, lecz nie potrafi bezpiecznie ich załatać, zwiększył widoczność problemów, ale nie wykonał całego zadania z zakresu bezpieczeństwa.

Pracownicy umysłowi i liderzy produktów również mają tu swoją rolę. Rejestry incydentów, decyzje architektoniczne i ograniczenia klientów muszą pozostać dostępne dla inżynierów oceniających ustalenia AI. Lepsza pamięć organizacyjna skraca czas między alertem modelu a możliwą do obrony naprawą.

Kolejny nagłówek w google news prawdopodobnie podkreśli większą liczbę podatności lub silniejszy model. Bardziej znaczący wynik pojawi się jednak w mniej rzucających się w oczy danych operacyjnych.

Czy Microsoft zdoła zmniejszyć kolejkę, zachować jakość poprawek i identyfikować niebezpieczne kombinacje, zanim zrobią to atakujący? Czytelnicy powinni śledzić te trzy sygnały i domagać się dowodów, że wykrywanie z szybkością AI przekłada się na obronę wspomaganą przez AI, a nie jedynie na szybciej rosnącą listę nierozwiązanych zagrożeń.