Claude Security Plugin: skaner podatności w terminalu

23 lipca 2026 roku Anthropic udostępnił w wersji beta narzędzie, które warto obejrzeć z bliska: Claude Security Plugin dla Claude Code. W skrócie działa tak — z poziomu istniejącej sesji w terminalu uruchamiasz wieloagentowy skan podatności repozytorium, a znaleziska, które wybierzesz, narzędzie zamienia w pliki łatek do samodzielnego przejrzenia i zastosowania. Możesz przeskanować niezacommitowane zmiany przed commitem albo puścić analizę całej bazy kodu, nie wychodząc z dotychczasowego przepływu pracy.

Wtyczka jest dostępna w becie dla wszystkich użytkowników Claude Code. Poniżej rozkładamy ją na części: co realnie robi, czym różni się od klasycznego SAST-a, gdzie jest najbardziej użyteczna, jakie ma ograniczenia — i, co najważniejsze, jak wpiąć ją w proces, żeby nie stała się generatorem fałszywego poczucia bezpieczeństwa.

Co dokładnie robi wtyczka

Trzy elementy opisu producenta są istotne, bo każdy niesie konsekwencje praktyczne.

Wieloagentowość. Skan nie jest pojedynczym przebiegiem jednego modelu, lecz pracą wielu agentów. W praktyce takie podejście pozwala rozdzielić zadania — inny agent może szukać błędów w obsłudze uwierzytelniania, inny w zapytaniach do bazy, inny analizować przepływ danych z wejścia użytkownika. Zwiększa to pokrycie i redukuje ryzyko, że jeden „wątek myślenia” przeoczy całą klasę problemów.

Działanie wewnątrz sesji Claude Code. To nie osobny produkt z własnym panelem, tylko rozszerzenie narzędzia, którego programista już używa. Konsekwencja jest większa, niż się wydaje: znika tarcie. Historycznie największym problemem narzędzi bezpieczeństwa nie była jakość detekcji, lecz to, że wymagały wyjścia z przepływu pracy — a więc były używane rzadko albo wcale.

Znaleziska → pliki łatek. Narzędzie nie zatrzymuje się na raporcie. Dla wybranych znalezisk generuje propozycję poprawki jako patch, który człowiek przegląda i sam stosuje. Ta konstrukcja jest właściwa: model proponuje, człowiek decyduje. Nie ma tu automatycznego wprowadzania zmian w kodzie bez przeglądu — i dobrze, bo automatyczne „naprawianie” bezpieczeństwa bez weryfikacji bywa groźniejsze niż sam błąd.

Czym to się różni od klasycznego SAST

Zestawmy to z narzędziami, które zespoły mają dziś w pipeline’ach.

Cecha	Klasyczny SAST	Skaner oparty na LLM
Podstawa działania	reguły, wzorce, analiza przepływu	rozumienie kodu w kontekście
Fałszywe alarmy	dużo, zwłaszcza bez strojenia	mniej powtarzalnych, ale możliwe konfabulacje
Nowe/nietypowe wzorce	słabo — nie ma reguły, nie ma znaleziska	lepiej — nie wymaga wcześniejszej reguły
Logika biznesowa	praktycznie nie wykrywa	ma szansę wykryć
Powtarzalność	wysoka (ten sam kod → ten sam wynik)	niższa (możliwa wariancja)
Uzasadnienie znaleziska	odwołanie do reguły	wyjaśnienie w języku naturalnym
Propozycja poprawki	rzadko lub szablonowa	konkretny patch w kontekście

Największą przewagą podejścia opartego na modelu jest wykrywanie problemów logiki biznesowej — czyli tej klasy błędów, na których klasyczne narzędzia zawodzą najbardziej. Skaner regułowy świetnie znajdzie konkatenację w zapytaniu SQL, ale nie zauważy, że w danym endpoincie nikt nie sprawdza, czy zalogowany użytkownik jest właścicielem obiektu, do którego sięga. Tymczasem to właśnie broken access control od lat prowadzi w zestawieniach realnych podatności — pisaliśmy o tym w przewodniku po OWASP Top 10 dla aplikacji webowych.

Największą słabością jest powtarzalność i podatność na konfabulację. Model może opisać przekonująco brzmiącą podatność, która nie istnieje, albo pominąć realną przy kolejnym uruchomieniu. Dlatego nie traktuj wyniku jak wyroku, tylko jak hipotezę do potwierdzenia — dokładnie ta sama dyscyplina, o której pisaliśmy przy znajdowaniu 0-dayów przez modele, gdzie kluczowym krokiem było odtworzenie błędu przez człowieka.

Gdzie to realnie pomaga

Przed commitem, na zmienionym kodzie. To najmocniejszy scenariusz. Skanowanie wyłącznie diffa jest szybkie, kontekst jest świeży, a koszt naprawy najniższy w całym cyklu życia. Błąd wyłapany przed commitem kosztuje minuty; ten sam błąd znaleziony na produkcji przez zewnętrznego badacza kosztuje incydent.

Jako drugie spojrzenie przy code review. Recenzent-człowiek zwykle skupia się na poprawności funkcjonalnej i czytelności; kwestie bezpieczeństwa bywają trzecim priorytetem, zwłaszcza pod presją terminu. Automatyczne, kontekstowe wskazanie ryzykownych miejsc dobrze uzupełnia ludzki przegląd.

W obszarach o wysokim ryzyku. Uwierzytelnianie i autoryzacja, obsługa plików, deserializacja, zapytania do baz, budowanie poleceń systemowych, współbieżność. To miejsca, gdzie błąd ma największe konsekwencje — i gdzie warto celowo poświęcić dodatkowy przebieg analizy.

W starszym kodzie bez testów. Legacy, którego nikt nie chce dotykać, jest wdzięcznym celem dla analizy maszynowej: żmudne przeczesywanie tysięcy linii to dokładnie ten rodzaj pracy, w którym modele są dziś mocne, a ludzie szybko tracą czujność.

Czego to nie zastąpi

Tu potrzebna jest uczciwość, bo marketing wokół narzędzi AI w bezpieczeństwie bywa hojny.

Nie zastąpi testów penetracyjnych. Skaner widzi kod. Nie widzi działającego systemu: konfiguracji serwera, nagłówków, sposobu wdrożenia, interakcji między usługami, uprawnień w chmurze ani tego, co się dzieje, gdy trzy komponenty spotkają się w produkcji. Ogromna część realnych podatności nie wynika z błędu w kodzie, lecz z tego, jak kod został uruchomiony i połączony. Różnice między klasami weryfikacji rozpisaliśmy w tekście o pentestach, audytach i skanach.

Nie zastąpi modelowania zagrożeń. Narzędzie odpowiada na pytanie „czy w tym kodzie jest błąd”, a nie „czy w ogóle projektujemy to dobrze”. Decyzje architektoniczne — gdzie przebiega granica zaufania, co uwierzytelniamy, jak izolujemy komponenty — zapadają zanim powstanie pierwsza linia kodu. To domena modelowania zagrożeń.

Nie zastąpi analizy zależności. Największe ryzyko w nowoczesnych projektach często nie leży we własnym kodzie, tylko w setkach pakietów, które ciągniesz z rejestrów. Skaner kodu aplikacji nie odpowie na pytanie o złośliwą paczkę w łańcuchu dostaw — o czym boleśnie przypomniał robak Mini Shai-Hulud w npm i PyPI.

Nie zastąpi zarządzania sekretami ani konfiguracją. Wykrycie zahardkodowanego klucza w kodzie jest wartościowe, ale nie rozwiązuje problemu rotacji, zakresów i przechowywania — o tym piszemy w zarządzaniu sekretami.

Ryzyka, o których trzeba pomyśleć przed wdrożeniem

To narzędzie bezpieczeństwa, ale jego wdrożenie samo w sobie ma implikacje bezpieczeństwa. Cztery kwestie do przemyślenia zawczasu.

Gdzie trafia Twój kod. Analiza wymaga przetworzenia kodu źródłowego. Zanim uruchomisz skan na repozytorium klienta albo na systemie objętym umową o poufności, ustal warunki przetwarzania danych i uzyskaj zgodę. To nie jest formalność — to podstawowy wymóg umowny w większości projektów komercyjnych.

Fałszywe poczucie bezpieczeństwa. Największe ryzyko organizacyjne brzmi: „przeskanowaliśmy Claude’em, jest czysto”. Zielony wynik oznacza wyłącznie, że narzędzie nic nie znalazło — nie że kod jest bezpieczny. Zapisz tę różnicę w procesie, zanim ktoś użyje skanu jako argumentu za pominięciem pentestu.

Automatyczne patche bez zrozumienia. Wtyczka generuje łatki do przeglądu i to dobra decyzja projektowa — ale tylko wtedy, gdy przegląd jest realny. Zastosowanie zaproponowanej poprawki, której nikt nie rozumie, przenosi ryzyko, zamiast je usuwać. Poprawka bezpieczeństwa bywa subtelna i łatwo nią zepsuć logikę aplikacji.

Prompt injection przez analizowany kod. To ryzyko specyficzne dla narzędzi opartych na LLM: analizowany plik może zawierać treść adresowaną do modelu (w komentarzu, w stringu, w pliku README), próbującą wpłynąć na jego zachowanie. Przy skanowaniu cudzego kodu — bibliotek, forków, wkładu z zewnątrz — to realny scenariusz. Traktuj analizowany kod jako dane niezaufane, a wyniki jako wymagające weryfikacji; mechanikę tej klasy ataków opisujemy w przewodniku po prompt injection.

Jak wpiąć to sensownie w proces

Proponowany model dojrzałego użycia:

Warstwa lokalna (deweloper). Skan zmienionego kodu przed commitem. Cel: wyłapać oczywiste błędy najtaniej, jak się da. Bez blokowania pracy — to wsparcie, nie bramka.
Warstwa przeglądu (pull request). Wynik skanu jako komentarz dla recenzenta, obok klasycznych narzędzi. Cel: skierować uwagę człowieka na ryzykowne fragmenty.
Warstwa pipeline’u (CI). Tu nadal pracują narzędzia deterministyczne — SAST, analiza zależności, skan sekretów — bo bramka jakościowa wymaga powtarzalności. Model, którego wynik może się różnić między przebiegami, jest złym kandydatem na twardą bramkę blokującą wdrożenie.
Warstwa niezależna (okresowo). Test penetracyjny i przegląd architektury, obejmujące działający system, a nie sam kod. Ta warstwa jest niezastępowalna i to ona weryfikuje wszystkie poprzednie.

Zasada porządkująca całość: narzędzia deterministyczne do bramkowania, narzędzia oparte na modelach do poszerzania pokrycia. Mieszanie tych ról jest najczęstszym błędem przy wdrażaniu AI w bezpieczeństwie — analogiczne wnioski wyciągaliśmy przy ewaluacji modeli i przy bezpieczeństwie CI/CD w DevSecOps.

Jak zweryfikować pojedyncze znalezisko

Skoro wynik modelu jest hipotezą, potrzebna jest powtarzalna procedura jej sprawdzania. Poniższa kolejność zajmuje zwykle kilka minut na znalezisko i chroni przed dwoma błędami naraz: odrzuceniem realnej podatności i naprawianiem nieistniejącej.

1. Sprawdź, czy kod jest w ogóle osiągalny. Zanim ocenisz mechanikę błędu, ustal, czy wskazana funkcja jest wywoływana z jakiejkolwiek ścieżki dostępnej z zewnątrz. Martwy kod, funkcja używana wyłącznie w testach albo gałąź nieosiągalna przy obecnej konfiguracji obniżają priorytet niemal do zera.

2. Prześledź źródło danych. Kluczowe pytanie brzmi: czy dane trafiające w to miejsce pochodzą od użytkownika lub z systemu zewnętrznego? Jeśli wartość jest stała albo pochodzi z zaufanej konfiguracji wewnętrznej, znalezisko zwykle jest fałszywe. Jeśli przechodzi przez żądanie HTTP, kolejkę, plik albo integrację — jest realne.

3. Zweryfikuj istniejące zabezpieczenia. Modele bywają nadgorliwe, gdy walidacja znajduje się w innej warstwie — w middleware, dekoratorze, filtrze na wejściu albo w bibliotece ORM. Sprawdź całą ścieżkę, nie tylko wskazany fragment.

4. Odtwórz zachowanie. Najsilniejszy dowód to test. Napisz przypadek testowy odzwierciedlający scenariusz z opisu i sprawdź, czy aplikacja faktycznie zachowuje się tak, jak twierdzi model. Jeśli potwierdzisz — masz gotowy test regresyjny na przyszłość, co jest wartością samą w sobie.

5. Oceń skutek, nie klasę błędu. Ta sama klasa podatności może oznaczać coś zupełnie innego w zależności od kontekstu. Wstrzyknięcie w narzędziu administracyjnym uruchamianym lokalnie a wstrzyknięcie w publicznym endpoincie to dwa różne priorytety, mimo identycznej etykiety.

6. Zapisz decyzję. Zarówno „naprawiamy”, jak i „odrzucamy jako fałszywe” warto udokumentować wraz z uzasadnieniem. Bez tego kolejny skan wygeneruje to samo znalezisko, a zespół przejdzie tę samą dyskusję od zera. Rejestr decyzji jest tym, co odróżnia proces od jednorazowej akcji.

Szerszy kontekst: rok, w którym AI weszła do pracy nad podatnościami

Ta premiera nie jest odosobniona — układa się w wyraźny trend 2026 roku. W ostatnich miesiącach widzieliśmy znalezienie realnego 0-daya w jądrze Linuksa z pomocą modelu, automatyczne wykrycia bezpieczeństwa wbudowywane w przeglądy kodu na platformach hostingowych oraz rozwój narzędzi lokalizujących podatności w dużych bazach kodu.

Kierunek jest jednoznaczny: analiza kodu pod kątem bezpieczeństwa staje się tańsza i dostępniejsza. Dla obrońcy to dobra wiadomość — pod jednym warunkiem. Ta sama technologia obniża koszt szukania błędów także po stronie atakującego. Przewagę zyskuje więc nie ten, kto ma dostęp do narzędzia, lecz ten, kto szybciej zamyka okno między znalezieniem błędu a jego naprawą u siebie.

Najczęstsze pytania (FAQ)

Czy to zastąpi nasz obecny SAST? Raczej uzupełni. Klasyczny SAST daje powtarzalność potrzebną do bramek w CI i jest przewidywalny; narzędzie oparte na modelu lepiej radzi sobie z logiką biznesową i nietypowymi wzorcami. Sensowne wdrożenie używa obu, w różnych rolach.

Czy mogę uruchomić to na kodzie klienta? Tylko po ustaleniu warunków przetwarzania i uzyskaniu zgody. Analiza wymaga przetworzenia kodu źródłowego, co przy projektach komercyjnych i objętych NDA jest kwestią umowną, a nie techniczną. Ustal to przed pierwszym skanem, nie po nim.

Czy zielony wynik oznacza, że kod jest bezpieczny? Nie. Oznacza, że narzędzie niczego nie znalazło w tym przebiegu. Brak znalezisk nigdy nie jest dowodem braku podatności — ani przy skanerze regułowym, ani przy modelu. To rozróżnienie warto zapisać w polityce, bo w praktyce bywa nadużywane.

Czy generowane łatki można stosować automatycznie? Odradzamy. Narzędzie celowo oddaje decyzję człowiekowi. Poprawki bezpieczeństwa bywają subtelne, a niezrozumiana zmiana potrafi przenieść problem w inne miejsce albo zepsuć logikę biznesową. Przegląd patcha jest częścią procesu, nie formalnością.

Od czego zacząć, jeśli chcemy to przetestować? Od jednego repozytorium o umiarkowanym ryzyku i porównania wyników z tym, co znajduje Wasz obecny stack. Zwróć uwagę na trzy rzeczy: ile znalezisk okazało się realnych po weryfikacji, czy pojawiły się klasy błędów nieznajdowane wcześniej, i ile czasu zajęła weryfikacja. Jeśli chcesz niezależnej oceny bezpieczeństwa aplikacji i procesu wytwarzania — odezwij się.

Podsumowanie

Claude Security Plugin to sensownie zaprojektowane narzędzie: działa tam, gdzie programista już jest, obniża tarcie do zera, wykrywa klasy błędów trudne dla narzędzi regułowych i oddaje ostatnie słowo człowiekowi, generując łatki do przeglądu, a nie stosując je samodzielnie.

Właściwe miejsce dla niego to przesunięcie bezpieczeństwa w lewo — wyłapywanie błędów przed commitem, gdy naprawa jest najtańsza. Niewłaściwe to traktowanie go jako dowodu bezpieczeństwa albo zamiennika niezależnej weryfikacji. Zielony wynik skanu i bezpieczna aplikacja to dwie różne rzeczy, a różnicę między nimi wypełniają konfiguracja, architektura, zależności i wdrożenie — czyli wszystko, czego skaner kodu z definicji nie widzi. Jeśli chcesz zweryfikować całość, a nie tylko kod — porozmawiajmy o teście penetracyjnym i przeglądzie architektury.

Źródła i dalsza lektura: Anthropic — dokumentacja Claude Code, MarkTechPost, OWASP Top 10, OWASP Top 10 for LLM Applications.