Claude Security jest w publicznej becie: co obiecuje “Scan to Fix”, a czego nie

Produkt bezpieczeństwa Anthropic jest teraz publiczną wersją beta dla Claude Enterprise, a jego jednolinijkowe hasło to sekwencja, a nie przymiotnik: od skanowania po naprawę, wszystko bezproblemowo. Mechanika kryjąca się za tym hasłem jest jasno opisana na stronie produktu — Claude skanuje Twoją bazę kodu za pomocą Claude Mythos, weryfikuje ustalenia i proponuje poprawki, które możesz przejrzeć i zatwierdzić. Trzy czasowniki, jedna nazwa modelu i ograniczenie zakresu, które łatwo przeoczyć przy pobieżnym czytaniu: to wersja beta, stworzona z myślą o klientach Enterprise, a nie o każdym, kto akurat ma repozytorium.

Interesujące pytanie nigdy nie brzmiało, czy model językowy potrafi znaleźć lukę. Modele robią to od jakiegoś czasu, czasem wystarczająco dobrze, by zawstydzić ludzi, którzy napisali kod. Interesujące jest to, co dzieje się między momentem pojawienia się ustalenia a momentem jego zamknięcia, ponieważ w tej luce żyją zaległości bezpieczeństwa: kolejka prawdopodobnych problemów, sortowana przez nikogo, przypisana wszystkim, zamykana przypadkiem. Odpowiedzią Anthropic jest potok o czterech etapach, a każdy etap stawia twierdzenie, które można zbadać osobno.

Co oznacza „publiczna beta Claude Enterprise”

Informacja o dostępności jest niezwykle bezpośrednia i warto ją zacytować, a nie parafrazować: dostępne w publicznej becie dla Claude Enterprise. Pod nią znajdują się dwa przyciski — kontakt ze sprzedażą i przeczytaj samouczek. Żaden z nich nie jest formularzem rejestracji. W praktyce oznacza to, że nabywcą jest firma, która ma już umowę Enterprise i zespół ds. bezpieczeństwa o wystarczającej pozycji, by poprosić o nowy skaner, a nie pojedynczy inżynier, który chce skierować coś na projekt poboczny.

Istnieje drugi, lżejszy sposób wejścia. Wtyczka Claude Security do Claude Code jest w wersji beta. To inny program o innej historii wdrożenia — skanowanie, walidacja i łatanie wewnątrz Claude Code przy zachowaniu kodu w Twoim środowisku — i to jest wersja, która ma znaczenie dla zespołu, którego przeszkodą nie jest budżet, lecz zasada określająca, gdzie kod źródłowy może trafić.

Skanowanie nie zatrzymuje się.

Pierwsze udokumentowane zachowanie to dogłębne skanowanie początkowe: Claude uruchamia je jednokrotnie na bazie kodu, a następnie kontynuuje skanowanie w miarę zmian kodu. To krótkie zdanie o dużych konsekwencjach operacyjnych. Jednorazowe skanowanie to fotografia. Bazy kodu nie są fotografiami; są pogodą. Znalezisko, które było trafne w dniu audytu i zostało częściowo naprawione przez trzy kolejne scalenia, jest gorsze niż brak znaleziska, ponieważ pochłania uwagę osób, które muszą je ponownie przeczytać.

Ciągłe skanowanie to również ta część produktu, którą najtrudniej podrobić. Wymaga ono, aby skaner rozumiał, które zmiany mają znaczenie, co jest inną umiejętnością niż znajdowanie podatności w statycznym drzewie. Strona nie opisuje, jak działa ta priorytetyzacja, a ten artykuł nie będzie próbował tego odgadnąć.

Jedyna oś, w której twierdzenie jest konkretne

Anthropic twierdzi, że Claude Security śledzi przepływy danych między plikami i repozytoriami, aby znajdować luki w zabezpieczeniach, których skanery oparte na dopasowywaniu wzorców mogą nie wykryć. To najbardziej sprawdzalne twierdzenie w całym opisie produktu, ponieważ wskazuje mechanizm, a nie rezultat.

Dopasowywanie wzorców, jak sama nazwa wskazuje, szuka znanego złego schematu: wywołania funkcji ze skażonym argumentem, ciągu znaków doklejanego do zapytania, znanego niebezpiecznego API. Jest szybkie, tanie i dlatego tradycyjne skanery słyną z dwóch rzeczy naraz — wychwytywania tej samej klasy błędu wszędzie, gdzie się pojawia, oraz zasypywania zespołu wynikami, które okazują się nieosiągalne. Alternatywą jest śledzenie wartości od miejsca, w którym wchodzi do systemu, do miejsca, w którym jest używana, przez granice między plikami i usługami. Tam kryją się prawdziwe błędy, ale też tam analiza staje się kosztowna, ponieważ narzędzie musi utrzymać więcej kontekstu, niż mieści się w jednej funkcji.

Zwróć jednak uwagę na zastrzeżenie zawarte w tym zdaniu. Może nie wykryć. To właściwe słowo, gdy dostawca nie ma żadnego benchmarku, na który mógłby wskazać, i jest to również powód, dla którego to twierdzenie należy sprawdzić na własnej bazie kodu, a nie przyjmować jako właściwość produktu.

Weryfikacja adwersarialna i model zagrożeń, który możesz edytować

Drugi etap to ten, który odnosi się do problemu fałszywych alarmów, jaki zna każdy zespół bezpieczeństwa. Każde wykrycie przechodzi weryfikację adwersaryjną, zanim trafi do zespołu. Coś próbuje obalić wykrycie, zanim zobaczy je człowiek: wykazać, że dane wejściowe w rzeczywistości nie mogą dotrzeć do ujścia (sink), albo że ścieżka jest chroniona na wcześniejszym etapie, albo że dany kod jest martwy.

Druga połowa tego samego zdania jest po cichu najciekawszą decyzją projektową na stronie. Model zagrożeń, który zespół może edytować, decyduje o tym, co warto oznaczyć. W praktyce oznacza to, że definicja istotności trafia w ręce klienta. Skaner, który samodzielnie określa wagę, zawsze jest trochę w błędzie, ponieważ waga zależy od kontekstu: nieuwierzytelniony punkt końcowy w wewnętrznym narzędziu administracyjnym to inny problem niż ten sam punkt końcowy w publicznym internecie, a żaden dostawca nie może wiedzieć, na który z nich patrzy. Umożliwienie edycji modelu zagrożeń jest uczciwym przyznaniem tego.

To również generuje dodatkową pracę. Model zagrożeń, którego nikt nie utrzymuje, staje się filtrem ukrywającym rzeczy, o których nikt nie pomyślał — czyli dokładnie odwrotnie niż to, do czego służy skaner. Wartość wyniosą z tego te zespoły, które traktują model zagrożeń jako żywy dokument z właścicielem — tak samo, jak traktują runbooki.

Patch jest jednostką danych wyjściowych

Każde zgłoszenie zawiera zalecaną poprawkę do przeglądu i zatwierdzenia przez zespół, a Claude oznacza zgłoszenie jako naprawione, gdy poprawka zostanie wdrożona. W tym zdaniu mieszczą się dwa twierdzenia i należy je rozdzielić.

Po pierwsze, wynik skanowania to zmiana, a nie zgłoszenie. To różnica między poinformowaniem inżyniera, że w jego kodzie jest problem, a pokazaniem mu, jak wygląda poprawiony kod. Sprowadza do minimum najmniej przyjemną część pracy w bezpieczeństwie — zrozumienie cudzego kodu na tyle dobrze, by go naprawić bez psucia tego, co robi — i robi to dla osoby, która rozumie ten kod najsłabiej. Na tym polega też ryzyko: poprawka, która wygląda na poprawną i przechodzi przegląd, bo recenzent był zmęczony, jest nowym błędem z zielonym znacznikiem.

Drugie twierdzenie dotyczy zamykania zgłoszeń. Claude oznacza ustalenie jako naprawione, gdy poprawka zostanie wdrożona, więc zgłoszenia się zamykają, zamiast gromadzić. Zaległości nie oznaczają porażki wykrywania. To porażka ewidencji: ta sama podatność jest zgłaszana siedem razy w siedmiu skanach, a kolejka rośnie szybciej, niż ktokolwiek jest w stanie ją opróżnić. Śledzenie ustalenia aż do commita, który je rozwiązuje, to mechanizm, dzięki któremu ciągły skaner da się znieść, a nie wpędza w demoralizację.

Anthropic wyraźnie zaznacza, że człowiek pozostaje w pętli, a każda poprawka wymaga przeglądu i zatwierdzenia. Każdy, kto to wdraża, powinien traktować to jako zdanie nośne, a nie jako zastrzeżenie na dole.

Dwa wydania, jeden kierunek

Claude Security nie powstał w próżni. Anthropic udostępnił Code Review w wersji ogólnie dostępnej 15 października 2026 r., a ciągłe skanowanie i śledzenie poprawek w Claude Security pojawiły się 21 października 2026 r. w publicznej becie dla Claude Enterprise. Czytane łącznie, oba mówią coś o kierunku: przegląd kodu zmierza od bramy, przez którą zmiana przechodzi na końcu, ku procesowi, który działa równolegle ze zmianą w miarę jej powstawania. Odstęp między tymi dwiema datami jest na tyle krótki, że produkty należy oceniać jako jedną historię o tym, dokąd zmierza praca nad bezpieczeństwem, a nie jako dwa niepowiązane wydania.

Co nie zostało opublikowane i liczba, która by to rozstrzygnęła

Lista niewiadomych jest tutaj dłuższa niż lista deklaracji, co jest normalne w przypadku publicznej bety, a nie skandalem. Nie jest publikowane, jak dużą część bazy kodu obejmuje skanowanie. Czas trwania skanowania nie jest publikowany. Wskaźniki fałszywych trafień nie są publikowane. Benchmarki wykrywania nie są publikowane. Brak niezależnej oceny. Ceny za stanowisko nie są publikowane, podobnie jak lista obsługiwanych języków.

Spośród nich tym, co zmienia decyzję zakupową, jest brakujący benchmark wykrywania. Bez niego “wychwytuje to, co pomijają skanery dopasowujące wzorce” jest twierdzeniem kierunkowym, którego nie można porównać ze skanerem już uwzględnionym w budżecie. Lista obsługiwanych języków jest druga: repozytorium wielojęzyczne to norma w firmie dowolnej wielkości, a skaner, który jest doskonały w trzech językach i nieobsługuje pozostałych pięciu, daje mylący obraz powierzchni ryzyka.

Nic z tego nie oznacza, że produkt nie działa. Oznacza to, że oceny musi dokonać kupujący, przy użyciu własnego kodu, i że demonstracja tego nie załatwi.

Jak to w ogóle ocenić?

Jeśli Twój zespół zamierza to wypróbować, użytecznym eksperymentem nie jest świeże repozytorium z celowo zaszyłą luką. Jest nim repozytorium, które ma już historię: usługa, w której w zeszłym roku doszło do incydentu, biblioteka ze znaną podatnością, której zamknięcie zajęło dwa tygodnie, moduł, którego wszyscy trochę się obawiają. Skieruj skan na takie repozytorium i porównaj to, co znajdzie, z ustaleniami, które Twój zespół już zapisał. Czułość wykrywania znanych problemów można zmierzyć nawet wtedy, gdy dostawca nie opublikował benchmarku, ponieważ stan faktyczny znajduje się w Twoim własnym systemie śledzenia incydentów.

Po drugie, uważaj na model zagrożeń. Jeśli pierwszą rzeczą, którą robi twój zespół, jest wyłączenie większości kategorii, aby skrócić kolejkę, to znaczy, że domyślny model nie odpowiada ryzyku, które faktycznie ponosi twój zespół, i powinieneś naprawić model, a nie filtr. Po trzecie, mierz etap, który ma znaczenie: ile czasu mija od pojawienia się znaleziska do scalenia poprawki. Ta liczba jest twoja, jest porównywalna między narzędziami i to właśnie na nią produkt faktycznie twierdzi, że wpływa.

Gdzie znajduje się router, a gdzie nie

Warto jasno określić tę granicę. Claude Security to aplikacja Anthropic. Nie hostujemy jej, nie sprzedajemy jej i nie możemy powiedzieć, co znalazła, a czego nie znalazła w Twoim repozytorium. Skaner działa na Claude Mythos i nie twierdzimy, że hostujemy ten model.

To, co robimy, to uruchamianie modeli. Jeden punkt końcowy zgodny z OpenAI, jeden klucz, ponad 200 modeli za nim, cena listowa dostawcy przekazywana bez doliczania marży i automatyczne przełączanie awaryjne między dostawcami, gdy któryś z nich zacznie szwankować. Claude Opus 5.5 jest w tym katalogu w cenie 4,00 USD za milion tokenów wejściowych i 20,00 USD za milion tokenów wyjściowych, z kontekstem 1 mln tokenów i odczytem z pamięci podręcznej po 0,20 USD za milion. To fakt dotyczący naszego katalogu, a nie twierdzenie o skanerze.

To, gdzie staje się to istotne, to ta część programu bezpieczeństwa, która nie jest skanerem: wewnętrzne narzędzie, które podsumowuje tysiąc znalezisk w coś, co człowiek może poddać triage’owi, agent, który przygotowuje biuletyn doradczy, etap przeglądu, który zespół chce zbudować wokół własnych reguł. To zwykłe wywołania modelu, a router to rozsądny sposób ich realizacji bez zakodowania na sztywno dostawcy. DSL routingu ma znaczenie, gdy jeden krok chce małego modelu do obsługi wolumenu, a następny chce ostrożnego modelu do oceny; automatyczny failover ma znaczenie, gdy wywołanie znajduje się w potoku, który działa o trzeciej nad ranem i nikt go nie obserwuje.

Czego beta tak naprawdę chce, żebyś zaufał

Jeśli odrzeć to z oprawy, produkt stawia trzy zakłady. Że model rozumujący nad kodem znajduje rzeczy, których nie znajdzie dopasowywanie wzorców. Że adwersaryjne drugie przejście wystarczy, by tłumić szum. Że znalezisko jest ukończone dopiero wtedy, gdy patch zostanie wydany, a kolejka zamknie się za nim. Trzeci zakład jest najmniej efektowny, ale ma największe szanse okazać się słuszny, ponieważ jest stwierdzeniem o procesie, a nie o inteligencji.

Pierwszy zakład to ten, który trzeba przetestować. Anthropic opublikował mechanizm — śledzenie przepływu danych między plikami i repozytoriami — i nie opublikował żadnej liczby, która pokazywałaby, jak dobrze to działa. To nie jest powód, by odrzucać produkt. To powód, by uruchomić go na repozytorium, którego historię już znasz, i oceniać go na podstawie ustaleń, które możesz zweryfikować, a nie tych, które robią wrażenie w demonstracji.