Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Wykrywanie podatności w nowoczesnych aplikacjach nie kończy się na identyfikacji podejrzanego wzorca w kodzie lub zależności. Równie ważne jest ustalenie, czy dana luka rzeczywiście istnieje, czy może zostać wykorzystana w praktyce oraz jaki ma realny wpływ na bezpieczeństwo organizacji. W tym właśnie obszarze, czyli triage podatności, coraz częściej testuje się duże modele językowe.
Choć LLM-y budzą duże oczekiwania jako wsparcie dla zespołów AppSec, ich skuteczność w klasyfikacji i priorytetyzacji luk nadal pozostaje ograniczona. Problem nie dotyczy wyłącznie trafności detekcji, ale także zdolności do rozumienia kontekstu technicznego, biznesowego i operacyjnego.
W skrócie
Modele językowe mogą przyspieszać analizę zgłoszeń bezpieczeństwa, jednak nie eliminują potrzeby eksperckiej walidacji. Największe wyzwania to wysoki poziom fałszywych alarmów, trudności z oceną osiągalności podatnego kodu, brak pełnego kontekstu środowiskowego oraz niespójność wyników między kolejnymi analizami.
- LLM potrafi wskazać podejrzaną konstrukcję, ale nie zawsze poprawnie ocenia jej znaczenie.
- Bez danych o runtime i architekturze model może błędnie zawyżać priorytet incydentu.
- Wyniki generatywne są mniej przewidywalne niż klasyczne silniki regułowe.
- AI najlepiej sprawdza się jako warstwa wspomagająca, a nie autonomiczny mechanizm decyzyjny.
Kontekst / historia
W ostatnich latach organizacje znacząco zwiększyły skalę skanowania kodu, bibliotek open source oraz pipeline’ów CI/CD. Wraz z tym wzrosła liczba alertów bezpieczeństwa, które muszą być ręcznie oceniane przez zespoły odpowiedzialne za bezpieczeństwo aplikacji. W praktyce duża część zgłoszeń okazuje się mało istotna, nieosiągalna lub błędnie sklasyfikowana.
Na tym tle pojawiła się nadzieja, że LLM-y pomogą uporządkować ten chaos i odciążą analityków. Jednak doświadczenia z wdrożeń i testów pokazują, że modele ogólnego przeznaczenia nie rozumieją wystarczająco dobrze zależności pomiędzy kodem, architekturą systemu, ekspozycją usługi i znaczeniem biznesowym konkretnej podatności.
Analiza techniczna
Najpoważniejszym ograniczeniem LLM-ów w triage podatności jest brak pełnej kontekstowości. Samo wykrycie podejrzanego wzorca nie wystarcza do ustalenia realnego ryzyka. Aby poprawnie ocenić alert, trzeba wiedzieć, czy dany kod działa w środowisku produkcyjnym, czy jest osiągalny z perspektywy atakującego, jakie dane przetwarza oraz jakie mechanizmy ochronne już istnieją.
Model językowy może poprawnie rozpoznać składnię ryzykownej konstrukcji, ale jednocześnie błędnie ocenić jej znaczenie. Dotyczy to między innymi użycia funkcji kryptograficznych, walidacji danych wejściowych czy sposobu obsługi uwierzytelniania. Ta sama technika może być krytyczna w jednym scenariuszu i marginalna w innym.
Drugim istotnym problemem jest reachability, czyli osiągalność podatnego kodu. Jeżeli biblioteka, funkcja lub ścieżka wykonania nie są wykorzystywane w runtime, rzeczywiste ryzyko eksploatacji może być dużo niższe niż sugeruje skaner. Bez powiązania analizy z przepływem wykonania oraz realnym użyciem komponentów model często zawyża priorytet zgłoszenia.
Kolejnym wyzwaniem pozostaje deterministyczność. Wyspecjalizowane narzędzia regułowe zwykle zapewniają większą przewidywalność wyników niż modele generatywne. LLM może dla tego samego zestawu danych raz uznać problem za fałszywy alarm, a przy kolejnym uruchomieniu nadać mu wysoki priorytet. Taka zmienność utrudnia budowę stabilnego procesu operacyjnego.
Nie można też pominąć kwestii kosztu i wydajności. W części zastosowań rozwiązania AI działają wolniej niż dojrzałe narzędzia SAST, DAST czy SCA, a dodatkowo wymagają warstwy orkiestracji, walidacji i kontroli. Skuteczne wdrożenie LLM do triage podatności wymaga więc nie tylko modelu, ale również odpowiednio zaprojektowanego procesu, zestawu reguł i integracji z istniejącym pipeline’em bezpieczeństwa.
Konsekwencje / ryzyko
Dla zespołów bezpieczeństwa podstawowym skutkiem niedojrzałego użycia AI jest wzrost kosztu operacyjnego. Jeżeli narzędzie generuje dużą liczbę niskiej jakości alertów, analitycy tracą czas na ręczną weryfikację zgłoszeń, które nie przekładają się na realne ograniczenie ryzyka.
Wpływa to również na relacje między działami bezpieczeństwa a zespołami developerskimi. Nadmiar automatycznych rekomendacji, pull requestów i eskalacji może obniżać zaufanie do narzędzi AppSec. W efekcie deweloperzy zaczynają ignorować część zgłoszeń, co osłabia skuteczność całego programu bezpieczeństwa.
Ryzyko dotyczy także jakości oprogramowania. Nadmierne poprawianie problemów, które nie są faktycznymi podatnościami, może prowadzić do regresji funkcjonalnych, spadku wydajności albo wprowadzania nowych błędów. W środowiskach produkcyjnych o dużej skali taki efekt uboczny ma już wymiar biznesowy, a nie tylko techniczny.
Rekomendacje
Organizacje powinny traktować LLM-y jako narzędzie wspierające analityków, a nie samodzielny system decyzyjny. Ostateczna priorytetyzacja podatności powinna opierać się na połączeniu analizy technicznej, wiedzy o architekturze, danych o ekspozycji usługi oraz wpływie biznesowym.
- Łączyć wyniki LLM z klasycznymi skanerami SAST, DAST i SCA.
- Uwzględniać reachability oraz rzeczywiste użycie komponentów w runtime.
- Rozszerzać analizę o kontekst organizacyjny, w tym krytyczność systemu i typ przetwarzanych danych.
- Wprowadzać ręczną walidację dla zgłoszeń o wysokim priorytecie.
- Mierzyć skuteczność narzędzi za pomocą wskaźników takich jak false positive rate, precision i czas do potwierdzenia podatności.
- Ograniczać automatyczne poprawki do dobrze znanych i powtarzalnych klas błędów.
- Budować warstwę kontrolną wokół modeli AI, aby zwiększyć spójność decyzji.
Warto również odejść od prostego polegania na bazowym CVSS i rozwijać politykę priorytetyzacji uwzględniającą ekspozycję usługi, osiągalność podatnego kodu, dostępność exploitów oraz wpływ na ciągłość działania organizacji.
Podsumowanie
Wykorzystanie LLM-ów do wykrywania i priorytetyzacji podatności pozostaje obiecującym, ale wciąż niedojrzałym kierunkiem rozwoju AppSec. Największe ograniczenia dotyczą braku kontekstu, wysokiego odsetka fałszywych alarmów, słabej oceny osiągalności oraz niestabilności klasyfikacji.
W praktyce oznacza to, że AI może zwiększać produktywność zespołów bezpieczeństwa tylko wtedy, gdy działa jako element szerszego, kontrolowanego procesu. Bez odpowiedniej walidacji i integracji z klasycznymi narzędziami LLM nie stanie się wiarygodnym źródłem prawdy w triage podatności.
Źródła
- Using LLMs to Find and Prioritize Vulnerabilities Is No Easy Task — https://www.darkreading.com/application-security/finding-and-prioritizing-vulnerabilities-no-easy-task
- Beyond Detection: What We Learned Testing Every AI Approach to Vulnerability Classification — https://www.blackhat.com/
- FIRST — Common Vulnerabilities and Exposures trends — https://www.first.org/
- Semgrep research on open source library runtime usage — https://semgrep.dev/