Chcesz, żeby Claude Code przejrzał aplikację webową pod kątem podatności, ale ogólne pytanie czy jest bezpieczna daje mgliste odpowiedzi.
Powodem jest to, że bez zawężenia zakresu i konkretnych klas podatności model odpowiada powierzchownie, zamiast systematycznie sprawdzić kod.
Rozwiązanie: prowadź review po klasach zagrożeń, wskazuj konkretne miejsca wejścia danych, żądaj dowodu w kodzie i weryfikuj każdy zgłoszony problem u źródła.
Claude Code, agentowe narzędzie CLI od Anthropic, potrafi czytać cały projekt i rozumieć przepływ danych, więc dobrze nadaje się do wstępnego przeglądu bezpieczeństwa aplikacji webowej. Ma jednak swoje granice: nie zastąpi pełnego audytu ani testów penetracyjnych i potrafi zarówno przeoczyć realną dziurę, jak i zgłosić fałszywy alarm. Klucz w tym, żeby nie pytać ogólnie, tylko poprowadzić review metodycznie, klasa podatności po klasie, i każdy wynik potraktować jak hipotezę do potwierdzenia w kodzie.
Jak to wygląda w praktyce
Gdy rzucisz pytanie sprawdź, czy ta aplikacja jest bezpieczna, dostaniesz zwykle listę ogólników: pamiętaj o walidacji, używaj zapytań parametryzowanych, szyfruj hasła. To poprawne rady, ale nie mówią, czy Twój kod faktycznie ma problem i gdzie. Bez ukierunkowania model nie przekopie się systematycznie przez wszystkie punkty wejścia danych. Bywa też odwrotnie: model oznaczy jakiś fragment jako podatny, choć w kontekście całej aplikacji zagrożenia nie ma, bo dane są walidowane wcześniej, w miejscu, którego akurat nie przeczytał.
Dlaczego Claude Code tak działa
Review bezpieczeństwa to zadanie o ogromnym zakresie. Model działa na ograniczonym oknie kontekstu i realizuje to, o co go poprosisz. Jeśli prośba jest ogólna, odpowiedź też będzie ogólna, bo model nie wie, na czym Ci najbardziej zależy, i nie ma budżetu uwagi, żeby jednocześnie i dokładnie sprawdzić wszystko. Do tego wnioski o bezpieczeństwie bywają zależne od kontekstu spoza jednego pliku: to, czy dane są niebezpieczne, zależy od tego, skąd przychodzą i gdzie trafiają. Model, który nie widzi całej ścieżki, może się pomylić w obie strony. Dlatego jego rolą jest wskazać podejrzane miejsca, a Twoją potwierdzić je faktami.
Jak to rozwiązać krok po kroku
Prowadź review po klasach podatności, jedna na raz. Poproś osobno o wstrzyknięcia SQL, o cross-site scripting, o błędy autoryzacji i kontroli dostępu, o niebezpieczne przetwarzanie danych wejściowych, o zarządzanie sekretami. Węższe pytanie daje głębszą odpowiedź.
Wskaż miejsca wejścia danych. Poproś, żeby model prześledził dane od punktu wejścia, czyli parametrów żądania, formularzy i nagłówków, aż do miejsca, gdzie trafiają do bazy, do widoku albo do komendy systemowej. To tam mieszkają realne podatności.
Żądaj dowodu w kodzie, nie ogólnika. Przy każdym zgłoszeniu proś o konkretny plik, linię i wyjaśnienie, dlaczego dany fragment jest podatny i jak można go wykorzystać. Twierdzenie bez wskazania miejsca jest bezużyteczne.
Każ zaproponować poprawkę i uzasadnienie. Dla potwierdzonej dziury poproś o konkretną zmianę, na przykład zapytanie parametryzowane zamiast sklejania stringów albo poprawne kodowanie danych w widoku, wraz z krótkim wyjaśnieniem, co to zmienia.
Sprawdzaj każdy wynik u źródła. Otwórz wskazany kod i sam oceń, czy zagrożenie jest realne w kontekście całej ścieżki danych. Odsiewaj fałszywe alarmy: jeśli dane są już walidowane wcześniej, zgłoszenie może być puste.
Traktuj to jako pierwszą warstwę, nie ostatnią. Wnioski z przeglądu Claude Code są punktem wyjścia. Przy aplikacji, od której zależy biznes, dołóż automatyczne skanery i, gdy stawka jest wysoka, profesjonalny audyt oraz testy penetracyjne.
Jak sprawdzić, że zadziałało
Dobrze przeprowadzony review kończy się listą konkretów: plik, linia, klasa podatności, opis jak ją wykorzystać i proponowana poprawka. Każdą pozycję potwierdź, otwierając wskazany kod i śledząc ścieżkę danych. Po wprowadzeniu poprawki sprawdź, czy problem faktycznie zniknął: przy wstrzyknięciu SQL zobacz, czy zapytanie jest już parametryzowane, przy cross-site scripting, czy dane wychodzące do widoku są poprawnie kodowane. Jeśli masz środowisko testowe, spróbuj odtworzyć atak i potwierdź, że po zmianie nie działa. Review uznajesz za wartościowy, gdy zamienił mgliste zalecenia w potwierdzone, naprawione miejsca w kodzie.
Szkolenie Claude Code - od zera do zespołu agentów AI
Tryb planowania, tryby uprawnień, komendy, MCP, hooki i systemy multi-agent - wszystko na żywym kodzie podczas trzydniowego szkolenia. Prowadzi Łukasz Matuszewski. Szkolenie ma terminy gwarantowane - odbędzie się niezależnie od liczby zgłoszeń.
Czy Claude Code potrafi znaleźć podatności w aplikacji webowej?
Claude Code czyta cały projekt i rozumie przepływ danych, więc nadaje się do wstępnego przeglądu bezpieczeństwa, ale nie zastąpi pełnego audytu ani testów penetracyjnych. Potrafi zarówno przeoczyć realną dziurę, jak i zgłosić fałszywy alarm, bo wnioski o bezpieczeństwie zależą od kontekstu spoza jednego pliku. Jego rolą jest wskazać podejrzane miejsca, a Twoją potwierdzić je faktami.
Dlaczego ogólne pytanie czy aplikacja jest bezpieczna daje mgliste odpowiedzi?
Review bezpieczeństwa ma ogromny zakres, a model działa na ograniczonym oknie kontekstu i realizuje to, o co go poprosisz. Przy ogólnym pytaniu nie wie, na czym Ci najbardziej zależy, i nie ma budżetu uwagi, żeby jednocześnie dokładnie sprawdzić wszystko, więc odpowiada listą ogólników zamiast konkretów. Węższe pytanie o jedną klasę podatności daje głębszą odpowiedź.
Jak poprowadzić z Claude Code review bezpieczeństwa krok po kroku?
Prowadź je po klasach podatności, jedna na raz: osobno wstrzyknięcia SQL, cross-site scripting, błędy autoryzacji i kontroli dostępu, niebezpieczne przetwarzanie danych wejściowych i zarządzanie sekretami. Poproś, żeby model prześledził dane od punktu wejścia aż do bazy, widoku albo komendy systemowej, i przy każdym zgłoszeniu żądaj pliku, linii i wyjaśnienia.
Jak potwierdzić, że zgłoszona podatność jest prawdziwa?
Każdą pozycję sprawdź u źródła: otwórz wskazany kod i oceń, czy zagrożenie jest realne w kontekście całej ścieżki danych, odsiewając fałszywe alarmy, bo jeśli dane są walidowane wcześniej, zgłoszenie może być puste. Po poprawce sprawdź, czy problem zniknął, a jeśli masz środowisko testowe, spróbuj odtworzyć atak i potwierdź, że po zmianie już nie działa.
Komentarze (0)
Brak komentarzy...