Twoja aplikacja działa. Klika się, loguje, zapisuje dane. Wygląda jak skończona. I właśnie dlatego jest najbardziej niebezpieczna - bo "działa" i "jest bezpieczna" to dwa różne zdania, które tylko udają synonimy.
Apka, która działa, robi to, co chcesz. Apka bezpieczna nie robi tego, czego chce ktoś inny. Różnicę widać dopiero wtedy, gdy ten ktoś inny już siedzi w Twojej bazie danych i czyta hasła użytkowników jak gazetę przy śniadaniu.
Dobra wiadomość: nie musisz wynajmować pentestera za stawkę wyższą niż Twój pierwszy samochód. Claude Code potrafi zrobić audyt bezpieczeństwa Twojego kodu, wskazać dziury i od razu zaproponować łaty. Pokażę Ci to krok po kroku.
Czego ten audyt szuka
Claude Code rozumie, co Twój kod robi, a nie tylko jak wygląda.
Szuka konkretnych klas problemów:
- Wstrzyknięcia (injection) - SQL injection, command injection, wstrzyknięcia do NoSQL, XXE. Czyli sytuacje, w których użytkownik wpisuje w formularz coś, co Twoja apka grzecznie wykonuje jak polecenie.
- Uwierzytelnianie i autoryzacja - zepsute logowanie, eskalacja uprawnień, dostęp do cudzych danych przez podmianę ID w adresie. Klasyk gatunku: zmieniasz
user=123nauser=124i nagle czytasz cudzą korespondencję. - Wyciek danych - hasła i klucze API wklejone na sztywno w kodzie, wrażliwe dane lądujące w logach.
- Kryptografia - słabe algorytmy, marne zarządzanie kluczami, generator losowości, który losowy jest tylko z nazwy.
- Walidacja danych wejściowych - brak sprawdzania tego, co przychodzi z zewnątrz.
- Błędy logiki biznesowej - race conditions, czyli wyścigi, w których dwa żądania robią coś naraz i wychodzi z tego bałagan.
- Cross-Site Scripting (XSS) - cudzy skrypt uruchamiany w przeglądarce Twojego użytkownika.
- Łańcuch dostaw - podatne biblioteki, których używasz, bo "wszyscy używają".
Przewaga nad klasycznymi skanerami (tzw. SAST) jest jedna, ale za to gruba: te narzędzia szukają wzorców, jak ktoś, kto sprawdza tekst pod kątem literówek bez czytania treści. Claude rozumie sens kodu. Wie, kiedy eval() jest bombą, a kiedy niegroźnym fragmentem testu. Dzięki temu mniej krzyczy o byle co i celniej trafia w realne dziury.
Krok 0: przygotowanie
Potrzebujesz Claude Code zainstalowanego i działającego w terminalu lub wtyczkę w Visual Studio Code. Funkcja audytu jest dostępna dla wszystkich użytkowników z płatnym planem oraz dla kont API rozliczanych pay-as-you-go.
Upewnij się, że masz najnowszą wersję. Claude Code zwykle aktualizuje się sam, ale ręcznie zrobisz to tak:
claude update
Wejdź do katalogu z projektem i odpal Claude Code:
cd /sciezka/do/twojej/apki
claude
Jeszcze jedno, zanim zaczniesz: rób audyt na kodzie, który jest pod kontrolą wersji (git). Nie dlatego, że coś się zepsuje, tylko dlatego, że gdy zaczniesz wprowadzać poprawki, chcesz móc cofnąć każdą zmianę jednym ruchem. Bezpieczeństwo to też możliwość powiedzenia "nie, jednak nie tak".
Krok 1: uruchom /security-review
To jest ten moment, dla którego tu jesteś. W Claude Code wpisz:
/security-review
I tyle. Claude bierze Twój kod, analizuje go pod kątem podatności i wypluwa listę znalezisk - każde z wyjaśnieniem, oceną ważności i podpowiedzią, jak to naprawić.
To nie jest sucha lista błędów w stylu "linia 42, problem". Dostajesz wytłumaczenie, dlaczego coś jest dziurą i co się stanie, jeśli zostawisz to tak, jak jest. Czyli dokładnie to, czego potrzebujesz, żeby zdecydować, co łatać najpierw.
Domyślnie komenda przegląda zmiany oczekujące na Twojej gałęzi - to, co dopiero co napisałeś i jeszcze nie scaliłeś. To celowe. Najtaniej naprawia się dziurę zanim trafi do głównego kodu, tak jak najłatwiej zawrócić z drogi, zanim wsiądziesz do złego pociągu, a nie trzy stacje później.
Uwaga: domyślnie audyt patrzy tylko na świeże zmiany
Tu jest haczyk, o który łatwo się potknąć. /security-review domyślnie sprawdza tylko zmiany oczekujące na Twojej gałęzi w git - to, co dopiero napisałeś i jeszcze nie scaliłeś. Jeśli odpalisz go na projekcie, w którym wszystko jest już dawno zacommitowane, Claude może odpowiedzieć, że nie ma czego sprawdzać. Nie dlatego, że kod jest czysty, tylko dlatego, że nie widzi żadnego diffa.
To rozsądny domyślny wybór, bo łapie dziury zanim wsiąkną w główny kod. Ale kiedy przejmujesz starszy projekt albo chcesz przejść przez całość raz a porządnie, potrzebujesz czegoś innego.
Najprostszy sposób: nie polegaj na automatycznym wykrywaniu diffa, tylko powiedz Claude wprost, co ma zrobić. Zamiast samej komendy napisz w czacie:
"Zrób pełny audyt bezpieczeństwa całego projektu, nie tylko zmian w git. Przejrzyj wszystkie pliki źródłowe i wypisz znaleziska z oceną ważności."
Claude potraktuje to jak normalne zadanie i przeczyta kod niezależnie od tego, co siedzi w gicie.
Krok 2: każ naprawić
Tu zaczyna się różnica między skanerem a partnerem. Klasyczne narzędzie pokazuje Ci problem i zostawia z nim sam na sam, jak mechanik, który mówi "no, popsute" i wraca do kanapki.
Claude może od razu naprawić. Po przejrzeniu listy mówisz mu wprost, na przykład:
"Napraw to wstrzyknięcie SQL w endpoincie logowania, użyj zapytań parametryzowanych."
Albo, jeśli ufasz mu na tyle, żeby zająć się drobnicą:
"Załataj wszystkie znaleziska o wysokim priorytecie i pokaż mi diff przed zapisaniem."
I tu ważna zasada, której trzymaj się jak poręczy na oblodzonych schodach: czytaj diff przed zatwierdzeniem. Claude jest dobry, ale to Ty bierzesz odpowiedzialność za swój kod. Poprawka bezpieczeństwa, której nie rozumiesz, to nie poprawka - to kolejna niewiadoma, tylko lepiej ubrana.
Naprawiaj iteracyjnie. Załataj, odpal /security-review jeszcze raz, sprawdź, czy dziura zniknęła i czy łatka nie otworzyła nowej.
Krok 3: zostaw sobie miejsce na zdrowy rozsądek
Tu muszę przyhamować entuzjazm, bo inaczej nie byłbym wobec Ciebie uczciwy. Automatyczny audyt to potężne narzędzie, ale ma swoje granice i lepiej je znać, niż odkrywać w boju.
To uzupełnienie, nie zamiennik. Claude łapie wiele typowych podatności, ale nie zastępuje Twojego myślenia ani ludzkiego przeglądu kodu przy poważniejszych rzeczach. Traktuj go jak drugą parę oczu, bardzo dobrą i nieznużoną, ale nie jak wyrocznię.
Tyle wystarczy na start
Bezpieczeństwo nie jest stanem, do którego się dochodzi i odhacza. Jest nawykiem, jak zamykanie drzwi na klucz. Z tą różnicą, że teraz masz kogoś, kto przy każdym wyjściu sprawdza, czy drzwi są zamknięte. Wpisz /security-review i zobacz, co ten ktoś znajdzie w Twojej apce. Założę się, że coś znajdzie.
