Anthropic wprowadził wtyczkę Claude Security dla Claude Code w wersji beta. Claude Code to oparty na terminalu agentowy asystent programistyczny firmy Anthropic, a wtyczka rozszerza go o obszar analizy bezpieczeństwa, tradycyjnie zajmowany przez dedykowane narzędzia statycznego testowania bezpieczeństwa aplikacji (SAST). Wtyczka wykonuje wieloagentowe skanowanie podatności repozytorium bezpośrednio w istniejącej sesji Claude Code i konwertuje wybrane znaleziska na pliki poprawek, które użytkownik przegląda i stosuje ręcznie. Anthropic podkreślił elastyczność narzędzia podczas premiery, zauważając, że może ono wykonać zarówno kompleksowe skanowanie całej bazy kodu, jak i sprawdzić zmiany z poziomu terminala tuż przed zatwierdzeniem (commit).

Co dodaje wtyczka

Wtyczka wprowadza jedno polecenie, /claude-security, które wyświetla menu trzech zadań, zgodnie z oficjalną dokumentacją:

• Skanowanie bazy kodu — całe repozytorium lub jego wybrany podzbiór
• Skanowanie zmian — diff gałęzi, diff pull requesta lub pojedynczy commit
• Sugestie poprawek — konwersja znalezisk z raportu na pliki .patch

Instalacja wymaga dwóch poleceń z oficjalnego marketplace Anthropic. Jeśli marketplace nie zostanie znaleziony, należy najpierw uruchomić /plugin marketplace add anthropics/claude-plugins-official. Kod źródłowy wtyczki jest publicznie dostępny w repozytorium claude-plugins-official, obecnie w wersji 0.10.0.

Jak skonstruowany jest potok skanowania

Skanowanie jest zaimplementowane jako dynamiczny przepływ pracy — skrypt orkiestracji w języku JavaScript, który rozdziela pracę między podagentami. Skrypt definiuje sześć faz:

1. Inwentaryzacja: podział repozytorium na komponenty. Każdy katalog najwyższego poziomu musi zostać przeskanowany lub jawnie pominięty z podaniem powodu.
2. Model zagrożeń: jeden modelarz na komponent, generujący punkty wejścia, ujścia (sinks), granice zaufania oraz pliki, które badacz musi przeanalizować w całości.
3. Badanie: jeden badacz na każdą komórkę komponent × kategoria.
4. Przeczesywanie (Sweep): wypełnianie luk w obszarach niepokrytych przez macierz.
5. Panel: trójlensowa weryfikacja adversarialna, po jednym głosującym na każde pole widzenia (lens).
6. Adversarialny (tylko przy maksymalnym wysiłku): ponowna ocena marginesowych akceptacji, a następnie red-team każdego ocalałego.

Badanie odbywa się w czterech stałych kategoriach: injection-and-input, auth-and-access, memory-and-unsafe oraz crypto-and-secrets. Pole widzenia memory-and-unsafe jest pomijane dla komponentów napisanych w całości w językach bezpiecznych pamięciowo, co oznacza, że czysty komponent w Pythonie lub TypeScript otrzymuje trzy pola widzenia zamiast czterech.

Skala operacyjna uruchomienia jest sterowana przez cztery odrębne poziomy intensywności: low, medium, high i max. W zależności od wybranego poziomu egzekwowane są określone progi: maksymalna liczba komponentów jest ograniczona do 12 dla poziomów low i medium, rosnąc do 24 dla poziomów high i max; komórkom macierzy przypisuje się 1 badacza na niższych poziomach, co rośnie do 2 na poziomach high i max; liczba operacji wypełniania luk rośnie od 0 na poziomie low, do 1 na medium, aż do 2 dla high i max. W przypadku ograniczonego zakresu lub małego diffa proces kondensuje się do konfiguracji z jednym badaczem zamiast wdrażania pełnej macierzy. Zapewnia to, że ocena pozostaje ściśle proporcjonalna do celu, przy zachowaniu identycznego standardu weryfikacji.

System wykorzystuje agentów w warstwie modeli: orkiestrator działa na modelu Opus, podczas gdy kartograf repozytorium i eksplorator kodu read-only działają na modelu Sonnet. Model sesji jest dziedziczony przez badaczy i weryfikatorów, a agenci skanujący są ograniczeni wyłącznie do narzędzi read-only.

Jak znalezisko zdobywa swoje miejsce w raporcie

Fałszywe pozytywy od dawna stanowią trwałe wyzwanie w automatycznym wykrywaniu podatności, często zmuszając zespoły bezpieczeństwa do segregacji hałaśliwych raportów. Architektura wtyczki rozwiązuje ten problem, wymagając, aby kandydat na znalezisko nie trafił do raportu jedynie dlatego, że badacz go zidentyfikował. Jest uwzględniany dopiero po przejściu panelu.

Każdy kandydat jest oceniany przez trzech niezależnych weryfikatorów, po jednym na pole widzenia: REACHABILITY, IMPACT i DEFENSES. Każdy zwraca ustrukturyzowany werdykt TRUE_POSITIVE lub FALSE_POSITIVE z jednym lub dwoma wierszami wskazującymi decydujący plik:wiersz. Kworum akceptacji wynosi 2 z 3. Jeśli mniej niż trzech głosujących zwróci wynik, kandydat nie może zostać zachowany wcale.

Wynik panelu ogranicza również deklarowaną pewność znaleziska. Jednogłośny panel 3/3 pozwala na górny limit pewności na poziomie high; kworum 2/3 ogranicza ją do medium. Znalezisko nie może deklarować większej pewności, niż wynika z przeprowadzonej weryfikacji.

Co istotne, liczenie jest wykonywane w języku Python przez render raportu, a nie deklarowane przez model, który wygenerował znaleziska. verification.status w stemple rewizji jest ustawiane na verified tylko wtedy, gdy rejestr głosów udowadnia, że panel został uruchomiony dla każdego znaleziska w raporcie; w przeciwnym razie jest oznaczane jako unverified z podanym powodem. Dzięki temu własny rachunek raportu za swój rygor jest czymś, co można sprawdzić, a nie czymś, co trzeba przyjąć na wiarę.

Co skan zapisuje na dysku

Każdy skan tworzy w repozytorium katalog z sygnaturą czasową CLAUDE-SECURITY-<timestamp>/ zawierający trzy artefakty:

• CLAUDE-SECURITY-RESULTS.md — raport czytelny dla człowieka. Każde znalezisko nosi identyfikator taki jak F1, a także stopień ważności (HIGH/MEDIUM/LOW), pewność, identyfikator CWE, dokładną linię ujścia (sink), wpływ, scenariusz wykorzystania, warunki wstępne oraz rekomendację. Wykorzystanie identyfikatorów CWE (Common Weakness Enumeration) dostosowuje znaleziska do powszechnie przyjętego standardu klasyfikacji MITRE, czyniąc wyniki interoperacyjnymi z istniejącymi przepływami pracy w zakresie śledzenia i usuwania podatności.
• CLAUDE-SECURITY-RESULTS.jsonl — te same znaleziska, po jednym obiekcie JSON na wiersz.
• CLAUDE-SECURITY-REVISION-.json — stempel rewizji: który commit został przeskanowany, z jakim wysiłkiem, liczniki ważności oraz jak dokładnie zostało zweryfikowane uruchomienie. Nazwa pliku zawiera -dirty, gdy niezatwierdzone zmiany były częścią skanowanego drzewa.

Ten katalog jest jedyną zmianą, jaką skan wprowadza w checkout, i jest dostarczany z własnym plikiem .gitignore, aby przypadkowe git add nie mogło wciągnąć raportu do commita. Usunięcie tego pliku .gitignore umożliwia commitowanie raportu w celu prowadzenia ścieżki audytowej.

Poprawki i trzy warunki, które każda z nich musi spełnić

Zadanie naprawy rozwija każdą poprawkę w odizolowanej kopii (scratch clone) repozytorium, zapewniając, że drzewo robocze i indeks nigdy nie są modyfikowane. Agent niezależny od tego, który napisał poprawkę, następnie przegląda przygotowany diff i uruchamia własną suitę testów projektu wobec zmiany.

Plik poprawki jest zapisywany tylko wtedy, gdy weryfikator może z pewnością stwierdzić wszystkie trzy poniższe rzeczy: zmiana adresuje to konkretne znalezisko, nie wprowadza nowej podatności, a zachowanie w pozostałym zakresie jest niezmienione — przy czym zmiana dotycząca tego, jakie dane wejściowe kod akceptuje, liczy się jako zmiana zachowania. Każda modyfikacja, która osłabia bezpieczeństwo, jednocześnie twierdząc, że je naprawia, taka jak poluzowanie sprawdzenia uwierzytelniania czy wyłączenie testu, jest automatycznie odrzucana. Gdy weryfikator nie może zaświadczyć wszystkich trzech kryteriów, zamiast poprawki dostarczana jest krótka notatka wyjaśniająca powód.

Poprawki są umieszczane w folderze patches/ raportu jako F<n>.patch. Nic nie jest stosowane automatycznie. Notatka do poprawki jednoznacznie wskazuje, czy żaden test repozytorium nie pokrywa zmodyfikowanego kodu, wyjaśniając, że weryfikacja opiera się na przeglądzie kodu, a nie na wykonaniu testów. Anthropic zaleca stosowanie każdej poprawki za pomocą indywidualnego pull requesta.

Wymagania, koszt i model zaufania

Wtyczka wymaga płatnego planu z Claude Code w wersji 2.1.154 lub nowszej, z włączonymi dynamicznymi przepływami pracy w /config. Wymaga również środowiska Python 3.9.6 lub nowszego w ścieżce PATH jako python3 (wykorzystującego wyłącznie bibliotekę standardową) oraz narzędzia Git do skanowania zmian i tworzenia poprawek. Obsługiwane są systemy Linux, macOS i Windows, a skany wliczają się do limitu tokenów planu.

Działając w sesji użytkownika pod jego uprawnieniami, skan nie dodaje własnej izolacji, co oznacza, że zatwierdzone ustawienia .claude/, hooki i CLAUDE.md nadal obowiązują. Choć traktuje zawartość repozytorium jako dane, a nie instrukcje, nie jest to ochrona przed wrogimi repozytoriami; Anthropic zaleca stosowanie sandbox-runtime do piaskownicy nieznanych baz kodu.

Ponadto skany są niedeterministyczne i nie zastępują tradycyjnej analizy statycznej, skanowania zależności ani przeglądów kodu. Wtyczka wkracza w krajobraz obejmujący ugruntowane narzędzia takie jak Semgrep, Snyk i SonarQube, ale odróżnia się swoim potokiem wieloagentowym, który wykonuje semantyczną analizę ścieżek kodu, zamiast opierać się głównie na regułach dopasowywania wzorców. Jako produkt beta w wersji 0.10.0, jego zakres, dokładność i zestaw funkcji mogą ulec zmianie.

Źródła: dokumentacja wtyczki Claude Security, strona produktu Claude Security, kod źródłowy wtyczki, claude-plugins-official, ogłoszenie @claudeai oraz blog Claude Security public beta