AI w przeglądzie kodu pod kątem bezpieczeństwa: metoda

AI w przeglądzie kodu pod kątem bezpieczeństwa przydaje się do trzech zadań: mapowania miejsc, którymi atakujący może wejść do systemu, sprawdzania hipotez o podatnościach oraz oceniania znalezisk, a wniosek agenta liczy się dopiero wtedy, gdy ma dowód w kodzie. Agent czyta szybciej niż człowiek i nie męczy się przy dziesięciotysięcznej linii, ale równie szybko uzasadni podatność, której w systemie nie ma. O wartości takiego agenta decyduje więc proces wokół niego: dowody, kalibracja oceny i granice dostępu.

Przegląd kodu to jedno z zastosowań AI w cyberbezpieczeństwie, obok pracy SOC i wykrywania phishingu. Pytanie, czy agenta do audytu chmury budować samodzielnie, czy kupić gotową platformę, rozbiera artykuł w CyberKatalogu o agentach AI w audycie bezpieczeństwa chmury.

Do czego AI nadaje się w przeglądzie kodu pod kątem bezpieczeństwa?

AI sprawdza się tam, gdzie praca polega na czytaniu dużej ilości kodu i łączeniu odległych fragmentów: od endpointu, przez warstwę uwierzytelniania, do miejsca, w którym dane trafiają do zapytania, systemu plików albo parsera. Człowiek robi to wybiórczo, bo ma ograniczony czas, a agent może robić to systematycznie. Gorzej radzi sobie z wiedzą o tym, jak system jest wdrożony naprawdę, bo konfiguracji produkcyjnej w repozytorium często nie ma.

Mapowanie, sprawdzanie hipotez i ocenę rozdzielamy na osobne tryby pracy, bo każdy ma inny cel i inny typowy błąd.

Do każdego trybu agent dostaje tylko jego zasady, dzięki czemu w kontekście ma wyłącznie to, czego potrzebuje do bieżącego zadania.

Jak agent AI do audytu bezpieczeństwa kodu dowodzi, że podatność jest osiągalna?

Osiągalność dowodzimy cytatem, a nie rozumowaniem o tym, jak system prawdopodobnie działa. Łańcuch idzie od żądania, przez trasę i warstwę uwierzytelniania oraz autoryzacji, do handlera i miejsca wykonania niebezpiecznej operacji (sink), a każdy jego krok ma kotwicę w pliku i linii. Kotwica bez numeru linii nie jest dowodem, bo recenzent nie sprawdzi jej w minutę.

Powierzchnię uznajemy za zamkniętą dopiero po wyliczeniu wszystkich parametrów żądania, które na niej są. Lista hipotez kończy się razem z pomysłami agenta, a lista parametrów razem z kodem, więc tylko druga mówi coś o pokryciu.

Osobna reguła dotyczy identyfikatorów. Podatność, która wymaga tokenu, UUID-a albo adresu e-mail, jest osiągalna bez uwierzytelnienia tylko wtedy, gdy udowodniono, skąd atakujący weźmie ten identyfikator bez logowania. Jeśli tego dowodu brakuje, mamy do czynienia z problemem autoryzacji, czyli z inną klasą znaleziska i inną wagą.

Wyniki negatywne zapisujemy równie starannie jak pozytywne. Wektor, który sprawdzono i który nie działa, trafia do bazy znalezisk razem z powodem, żeby ani człowiek, ani kolejny przebieg agenta nie szli tą samą drogą drugi raz. Baza jest prowadzona osobno dla każdego repozytorium.

Jak ocenić wagę podatności znalezionej przez AI?

Do oceny wagi służy zwykle CVSS. Specyfikacja CVSS 4.0, prowadzona przez organizację FIRST, dzieli metryki na cztery grupy: Base, Threat, Environmental i Supplemental. Base opisuje samą podatność, a Environmental dotyczy środowiska konkretnego odbiorcy. Specyfikacja każe też oznaczać, z jakich grup policzono wynik (CVSS-B, CVSS-BT, CVSS-BE albo CVSS-BTE), bo te same liczby z różnych kombinacji znaczą co innego, i zaleca uzupełnianie Base o Threat i Environmental, zanim wynik posłuży do oceny ryzyka (źródło 1).

Kalibrację opieramy na tym podziale. Warunek ustawiony przez wdrażającego, na przykład utwardzona konfiguracja, obniża wynik środowiskowy (CVSS-BE), ale nie bazowy, bo wynik bazowy zakłada najgorszy rozsądny przypadek w różnych wdrożeniach. Wynik wyprowadzony z konfiguracji serwera jednego wdrożenia obowiązuje tylko to wdrożenie. Infrastrukturę jako kod czytamy razem z kodem produktu, ponieważ warstwa filtrująca, która neutralizuje atak, często leży właśnie tam.

Dokument z wynikami rozróżnia dwa statusy, których nigdy nie mieszamy: potwierdzone w kodzie i potwierdzone na środowisku. Raport mówi, co uruchomiono, a co tylko przeczytano. Przy ponownym teście poprawki potrzebna jest próba kontrolna z wynikiem dodatnim, ponieważ płaski wynik pomiaru czasu może znaczyć, że luka została naprawiona, ale równie dobrze, że kod z luką nigdy nie został osiągnięty.

Jedno zweryfikowane znalezisko z uczciwą oceną jest warte więcej niż pięć zawyżonych, bo jedna zawyżona ocena kosztuje wiarygodność każdego późniejszego raportu.

Jak bezpiecznie dać agentowi AI dostęp do kodu i środowiska?

Kod badanego systemu agent ma wyłącznie do odczytu. Do działającego środowiska wchodzi tylko za wyraźną zgodą, cytowaną w zleceniu dosłownie, w trybie odczytu i bez żadnych działań destrukcyjnych. Klucze kryptograficzne odnotowuje jako istniejące, ale nigdy ich nie czyta ani nie cytuje.

Agent, który czyta cudzy kod, czyta też cudzy tekst, a model nie oddziela danych od poleceń tak, jak robi to parser. Według OWASP, w opisie ryzyka LLM01:2025, wstrzyknięcie polecenia (prompt injection) może przyjść pośrednio, z zewnętrznej treści takiej jak strony i pliki, i nie musi być czytelne dla człowieka, byle model je przetworzył (źródło 2). Wśród środków zaradczych OWASP wymienia między innymi ograniczenie uprawnień modelu do niezbędnych, zatwierdzanie przez człowieka działań uprzywilejowanych oraz oddzielanie treści niezaufanej, i zastrzega, że nie wiadomo, czy istnieją niezawodne metody całkowitego zapobiegania.

Dlatego wynik skanera, odpowiedź HTTP i zawartość pliku z badanego systemu są dla agenta dowodem do zacytowania, nigdy poleceniem do wykonania. Komentarz w kodzie, który każe agentowi coś zrobić, jest dla niego tekstem jak każdy inny.

Transkrypty i logi samego agenta zawierają fragmenty badanego kodu, więc są jego kopią. Przed pierwszym uruchomieniem ustalamy, dokąd trafiają, jak długo przechowuje je dostawca modelu i kto ma do nich dostęp. Znaleziska nie opuszczają prywatnej bazy znalezisk.

Kto sprawdza pracę agenta AI w przeglądzie bezpieczeństwa?

Autor nie ocenia własnej pracy. Gdy agent zgłasza, że skończył, jego twierdzenie sprawdza od zera weryfikator w świeżym kontekście, który nie ma żadnego interesu w tym, żeby wynik wyglądał dobrze. Ostatnie słowo należy do deterministycznej bramki, nie do modelu: skrypt przechodzi albo nie, niezależnie od tego, jak przekonująco brzmi uzasadnienie.

Wersję metody zapisujemy razem z wynikiem, bo ocena ma sens tylko wtedy, gdy wiadomo, według czego powstała.

Lista kontrolna: jak ocenić proces przeglądu kodu z agentem AI?

Kiedy zlecić przegląd bezpieczeństwa kodu z AI na zewnątrz?

Zewnętrzne wsparcie ma sens przede wszystkim wtedy, gdy wniosków agenta nie ma kto niezależnie zweryfikować, bo bez weryfikacji agent dostarcza głównie szum. Przydaje się też przy kodzie, którego znaleziska trzeba obronić przed dostawcą albo audytorem, a to wymaga dowodów w opisanej wyżej formie. Jest potrzebne również wtedy, gdy firma nie ma procesu obsługi podatności, ponieważ agent znajdzie więcej, niż zespół zdąży naprawić.

Jeśli firma podlega ustawie o krajowym systemie cyberbezpieczeństwa, obsługa podatności jest jej obowiązkiem, a artykuł o SZBI w ustawie o KSC pokazuje, które wymogi sprawdza się w systemach, a które w dokumentach. Agenta AI włączamy do przeglądu bezpieczeństwa kodu, architektury i CI/CD z naszej oferty cyberbezpieczeństwa i zgodności.

Najczęściej zadawane pytania

Czy AI może samodzielnie wykonać audyt bezpieczeństwa kodu?

Nie. Wniosek agenta bez dowodu w pliku i linii nie jest znaleziskiem, a pracę zamyka weryfikator w świeżym kontekście i deterministyczna bramka, nie sam agent. Agent szybko czyta kod i proponuje hipotezy, ale ocenę wagi i status znaleziska ustala niezależna weryfikacja.

Czy wysłanie kodu do agenta AI nie ujawnia go dostawcy modelu?

Logi i transkrypty agenta zawierają fragmenty badanego kodu, więc są jego kopią. Dlatego przed pierwszym uruchomieniem ustala się, dokąd trafiają, jak długo przechowuje je dostawca modelu i kto ma do nich dostęp.

Czym przegląd kodu z agentem AI różni się od skanera podatności?

Skaner zwraca wyniki według własnych reguł. Agent stawia hipotezy o konkretnym systemie i sprawdza je w kodzie krok po kroku, od żądania do miejsca wykonania niebezpiecznej operacji. Wynik skanera jest dla niego dowodem do zacytowania, a o wadze i statusie znaleziska decydują dowód, kalibracja i weryfikacja opisane wyżej.

Źródła

1. FIRST, "CVSS v4.0 Specification Document" - grupy metryk, nomenklatura CVSS-B, CVSS-BT, CVSS-BE i CVSS-BTE oraz zalecenie uzupełniania Base o Threat i Environmental (odczyt 28.10.2026)
2. OWASP GenAI Security Project, "LLM01:2025 Prompt Injection" - wstrzyknięcie pośrednie, niewidoczność dla człowieka, środki zaradcze (odczyt 28.10.2026)