Wprowadzenie do problemu / definicja
Automatyzacja wykrywania podatności z wykorzystaniem modeli AI znacząco zwiększyła skalę identyfikowania potencjalnych błędów bezpieczeństwa. Nie oznacza to jednak automatycznego wzrostu poziomu ochrony. Najtrudniejszy etap nadal pozostaje po stronie człowieka: trzeba ustalenia zweryfikować, ocenić ich realny wpływ, skontaktować się z maintainerami i doprowadzić do wdrożenia poprawek.
Najnowsze obserwacje wokół programu Project Glasswing pokazują, że branża wchodzi w nową fazę. Problemem nie jest już wyłącznie znalezienie słabości, ale przetworzenie ogromnej liczby wyników w użyteczne operacyjnie zgłoszenia i rzeczywiste działania naprawcze.
W skrócie
Project Glasswing, wykorzystujący model Claude Mythos do wyszukiwania podatności w projektach software’owych, wygenerował dziesiątki tysięcy ustaleń dotyczących potencjalnych luk. Tylko część z nich trafiła jednak do formalnego procesu ujawnienia, a jeszcze mniejsza liczba została oznaczona jako naprawiona.
Wniosek jest prosty: wzrost skali wykrywania nie przekłada się automatycznie na wzrost bezpieczeństwa. Organizacje muszą dziś odróżniać sygnał od szumu, a to nadal wymaga czasu, kompetencji i dobrze zaprojektowanego procesu triage’u.
Kontekst / historia
W ostatnich latach cyberbezpieczeństwo coraz mocniej eksperymentuje z generatywną AI i modelami frontier w obszarze identyfikowania błędów w kodzie. Narracja rynkowa skupiała się głównie na przyspieszeniu discovery, czyli znajdowania nowych podatności, a Project Glasswing stał się jednym z najbardziej wyrazistych przykładów tego trendu.
Analiza publicznego rejestru zgłoszeń związanego z projektem pokazała jednak wyraźną dysproporcję między liczbą wykrytych ustaleń a liczbą przypadków, które rzeczywiście przeszły przez proces coordinated vulnerability disclosure. To zmienia perspektywę: historycznie barierą było odnalezienie podatności, dziś coraz częściej ograniczeniem staje się zdolność ludzi i organizacji do obsługi masowo generowanych wyników.
Analiza techniczna
Dane związane z Project Glasswing wskazują, że Claude Mythos wygenerował 26 153 ustalenia dotyczące potencjalnych podatności od startu programu w kwietniu 2026 roku. Spośród nich 2 736 trafiło do rejestru ujawnień, co oznacza, że zostały zgłoszone odpowiednim opiekunom projektów lub znajdowały się w procesie disclosure. Jedynie 202 przypadki oznaczono jako naprawione. Dodatkowo 245 zgłoszeń wycofano, a 191 pozostawało na etapie przed ujawnieniem.
Taki rozkład danych dobrze pokazuje naturę problemu w modelu AI-driven vulnerability discovery. Duża liczba ustaleń nie oznacza automatycznie dużej liczby podatności gotowych do publikacji. Model może trafnie wychwytywać wzorce przypominające słabości bezpieczeństwa, ale wiele z nich wymaga dodatkowej analizy kontekstu wykonania, potwierdzenia exploitability, określenia warunków brzegowych i oceny wpływu na rzeczywiste środowisko.
W praktyce to właśnie ten etap pozostaje słabo podatny na pełną automatyzację. AI może znacząco zwiększyć przepustowość wykrywania, ale nadal nie gwarantuje jakości wymaganej w procesach ujawniania, eskalacji i remediacji.
Istotny problem dotyczy też klasyfikacji severity. Model miał oceniać wiele ustaleń bardziej agresywnie niż maintainerzy projektów. Znaczna część zgłoszeń kierowanych do dalszej obsługi otrzymywała wysokie lub krytyczne priorytety, podczas gdy opiekunowie oprogramowania rzadziej potwierdzali tak poważną rangę. To może prowadzić do zawyżania priorytetów i przeciążenia zespołów odpowiedzialnych za naprawy.
Branża obserwuje również problem niestabilności wyników generowanych przez skanery AI. Powtarzalność rezultatów bywa ograniczona, a różne uruchomienia tych samych narzędzi na tym samym kodzie mogą zwracać odmienne zestawy ustaleń. Z perspektywy bezpieczeństwa to poważne wyzwanie, ponieważ procesy audytowe i operacyjne wymagają wysokiej precyzji, przewidywalności oraz możliwości odtworzenia wyniku.
W efekcie współczesny pipeline bezpieczeństwa wygląda inaczej niż jeszcze kilka lat temu: wykrywanie staje się tańsze i szybsze, natomiast walidacja pozostaje kosztowna, czasochłonna i zależna od ekspertów. To właśnie tutaj tworzy się nowe operacyjne wąskie gardło.
Konsekwencje / ryzyko
Najbardziej widocznym skutkiem takiego modelu pracy jest przeciążenie zespołów AppSec, PSIRT, product security oraz maintainerów open source. Jeśli liczba zgłoszeń rośnie szybciej niż zdolność organizacji do ich obsługi, ryzyko nie maleje proporcjonalnie do liczby wykryć.
- Rośnie zmęczenie alertami, co obniża jakość triage’u i zwiększa szansę przeoczenia faktycznie krytycznej podatności.
- Błędna priorytetyzacja może kierować zasoby do ustaleń o ograniczonym znaczeniu zamiast do problemów rzeczywiście wymagających pilnej reakcji.
- Koszt procesu przesuwa się z samego discovery na ręczne potwierdzanie, kontakt z dostawcami i testowanie poprawek.
- Opóźnienia w disclosure i patchingu sprawiają, że użytkownicy końcowi nie odczuwają realnej poprawy bezpieczeństwa mimo dużej liczby wykryć.
Z perspektywy zarządczej to ważny sygnał: liczba findings nie powinna być mylona z liczbą potwierdzonych zagrożeń ani z faktycznie zredukowanym ryzykiem.
Rekomendacje
Organizacje wdrażające AI do wykrywania podatności powinny traktować takie narzędzia jako wzmacniacz pracy ekspertów, a nie zamiennik procesu vulnerability management. Kluczowe staje się zbudowanie warstwy operacyjnej, która poradzi sobie z masą wyników bez utraty jakości.
- Wdrożyć wieloetapowy triage, łączący automatyczne filtrowanie z ręczną oceną według jasno określonych kryteriów.
- Standaryzować zgłoszenia poprzez przypisanie CWE, metryk CVSS, warunków exploitacji i dowodu wpływu.
- Wyraźnie oddzielać findings od confirmed vulnerabilities, aby raportowanie nie mieszało surowych sygnałów z potwierdzonym ryzykiem.
- Stosować deduplikację i korelację wyników z wielu silników zamiast traktować każde ustalenie jako odrębny incydent.
- Budować priorytetyzację opartą na kontekście biznesowym, ekspozycji systemu, środkach kompensujących i realnej możliwości nadużycia.
- Mierzyć skuteczność procesu wskaźnikami takimi jak true positive rate, median time to validate, median time to disclose oraz median time to patch.
- Zabezpieczyć zasoby dla zespołów odpowiedzialnych za disclosure coordination, ponieważ stają się one kluczowym elementem całego łańcucha.
Po stronie technicznej najlepsze rezultaty może dać łączenie AI z analizą statyczną, analizą dynamiczną, fuzzingiem oraz dodatkowymi metodami potwierdzania ścieżek wykonania. Im więcej niezależnych sygnałów wspiera dane ustalenie, tym mniejsze ryzyko marnowania czasu na false positive.
Podsumowanie
Project Glasswing pokazuje, że nowym ograniczeniem w cyberbezpieczeństwie nie jest już wyłącznie zdolność do znajdowania potencjalnych podatności. Coraz większym problemem staje się obsłużenie skali wygenerowanych wyników i przełożenie ich na skuteczne, terminowe działania naprawcze.
AI może produkować ogromną liczbę wartościowych wskazań, ale bez dojrzałego procesu walidacji, klasyfikacji i remediacji organizacje otrzymują przede wszystkim strumień dodatkowej pracy. Przewagę zyskają te podmioty, które potrafią zamienić masowe wykrywanie w mierzalną redukcję ryzyka, a nie jedynie w rosnącą liczbę alertów.
Źródła
- Dark Reading — Mythos Vulnerability Firehose Hits a Human Bottleneck — https://www.darkreading.com/application-security/mythos-vulnerability-firehose-hits-human-bottleneck
- VulnCheck — Analysis of Anthropic Project Glasswing Vulnerability Disclosure Ledger — https://www.vulncheck.com/
- Anthropic — Vulnerability Disclosure Ledger / Project Glasswing materials — https://red.anthropic.com/