Cisco Antares: małe modele AI szukają podatności

Cisco 21 lipca 2026 roku udostępniło dwa małe, otwartowagowe modele językowe przeznaczone do lokalizowania podatności w repozytoriach kodu. Antares-350M i Antares-1B nie mają automatycznie naprawiać aplikacji ani zastępować pentestera. Ich wąskie zadanie polega na wskazaniu plików, w których najprawdopodobniej znajduje się opisana klasa błędu lub znana podatność. To mniej efektowne niż autonomiczny agent piszący patch, ale w rzeczywistym AppSec właśnie odnalezienie właściwego fragmentu dużego, obcego repozytorium często pochłania najwięcej czasu.

Oficjalny komunikat Cisco potwierdza dostępność obu modeli na Hugging Face, zapowiada wariant Antares-3B i opisuje nowy Vulnerability Localization Benchmark. Producent twierdzi, że kompaktowe modele w tym wyspecjalizowanym teście przewyższają wiele większych modeli przy niższym koszcie. To są jednak wyniki Cisco dla konkretnego benchmarku, a nie niezależny dowód, że Antares wykryje każdą lukę w produkcyjnej aplikacji.

Co dokładnie robi Antares

Punktem wejścia jest informacja o problemie: opis CVE, kategoria CWE, treść advisory albo hipoteza analityka. Model przegląda repozytorium iteracyjnie. Wyszukuje nazwy, wzorce i zależności, czyta wybrane pliki, aktualizuje hipotezę, rezygnuje ze ślepych ścieżek i tworzy ranking miejsc wymagających kontroli człowieka. Wynikiem nie jest werdykt „system bezpieczny”, lecz lista kandydatów wraz ze śladem eksploracji terminalowej.

Ta różnica wyznacza prawidłowe użycie narzędzia. Antares może skrócić etap triage po publikacji CVE, wesprzeć analizę konkretnego CWE albo podpowiedzieć recenzentowi, od którego modułu zacząć. Nie potwierdza jednak osiągalności podatnej funkcji, wpływu kontroli kompensacyjnych, kompletności poprawki ani biznesowego skutku wykorzystania. Do tego nadal potrzebne są analiza przepływu danych, test uruchomieniowy, kontekst architektury i ekspercka weryfikacja.

Pytanie	Antares może pomóc	Nadal wymaga innej kontroli
Gdzie szukać kodu związanego z CWE?	ranking plików i ślad poszukiwań	potwierdzenie konkretnego przepływu
Czy zależność ma znane CVE?	może wskazać wrapper lub wywołanie	SCA, SBOM i wersja rzeczywista
Czy luka jest osiągalna z Internetu?	ograniczony kontekst kodu	DAST, architektura, konfiguracja
Czy poprawka zamyka cały wariant błędu?	ponowne wskazanie kandydatów	code review, test regresji, pentest
Czy repozytorium jest bezpieczne?	nie	cały program AppSec

Dlaczego model 350M lub 1B może mieć sens

W bezpieczeństwie kodu największy model nie zawsze jest najlepszym wyborem. Repozytoria zawierają własność intelektualną, sekrety, komentarze projektowe i nieopublikowane funkcje. Przesłanie całości do zewnętrznej usługi może naruszać politykę przetwarzania, umowy z klientami lub zasadę minimalizacji danych. Model uruchamiany lokalnie pozwala utrzymać kod w kontrolowanym środowisku i precyzyjniej rejestrować, jakie pliki zostały odczytane.

Mniejszy model zużywa też mniej pamięci i może działać częściej. Zamiast kosztownego skanu raz na kwartał zespół może uruchamiać wyspecjalizowane sprawdzenie po zmianie krytycznego modułu albo po publikacji nowego advisory. Warunkiem jest jednak pomiar wartości. Niska cena jednego przebiegu nie pomaga, jeśli wynik generuje tysiące fałszywych tropów. Zespół powinien mierzyć precision w pierwszych N plikach, czas analityka do potwierdzenia, odsetek pominiętych przypadków i stabilność wyników między wersjami modelu.

Lokalność nie oznacza automatycznie bezpieczeństwa. Wagi, tokenizer, kod ładowania modelu i kontener wykonawczy są nową częścią łańcucha dostaw. Przed wdrożeniem warto zastosować zasady z poradnika o bezpiecznych formatach modeli AI: przypiąć wersję i hash, preferować format bez dowolnego wykonania kodu, skanować artefakty, ograniczyć sieć i zweryfikować licencję.

Nowy benchmark nie jest certyfikatem jakości

Cisco przygotowało Vulnerability Localization Benchmark obejmujący 500 zadań. Zadania wymagają poruszania się po nieznanych repozytoriach oraz rozpoznawania wzorców odpowiadających klasom CWE. To właściwsza miara niż ogólny benchmark programistyczny, ponieważ sprawdza lokalizację podatnego pliku, a nie wygenerowanie dowolnego kodu lub rozwiązanie zgłoszenia funkcjonalnego.

Benchmark ma jednak granice. Skończony zbiór nie reprezentuje wszystkich języków, frameworków, konwencji monorepo i błędów logiki biznesowej. Wynik może wzrosnąć przez dopasowanie do rozkładu zadań, niekoniecznie przez lepszą analizę nowej aplikacji. Nie wiadomo też, jak model poradzi sobie z kodem generowanym, wieloma repozytoriami, mikroserwisami, konfiguracją infrastruktury lub podatnością powstającą dopiero z połączenia kilku warstw.

Dlatego organizacja powinna zbudować własny zestaw ewaluacyjny. Najlepsze próbki pochodzą z usuniętych wcześniej błędów, zaakceptowanych wyników SAST, DAST i IAST, raportów bug bounty i testów penetracyjnych. Dane muszą być odseparowane od materiału użytego do dostrajania. Dla każdego przypadku trzeba znać prawidłowe pliki, wymagany kontekst i minimalny dowód, a nie tylko etykietę podatny/bezpieczny.

Jak włączyć Antares do CI/CD bez zablokowania zespołu

Najbezpieczniejszy pierwszy etap to tryb obserwacyjny. Model analizuje zmiany lub wybrane repozytoria, ale nie blokuje merge. AppSec porównuje wskazania z rezultatami istniejących narzędzi i decyzjami recenzentów. Dopiero po zebraniu danych można zbudować regułę bramki, najlepiej ograniczoną do krytycznych komponentów i dobrze mierzonych klas CWE.

Praktyczny przepływ może wyglądać tak:

system pobiera zatwierdzony opis podatności lub klasy CWE;
izolowany runner dostaje kopię repozytorium tylko do odczytu;
Antares zwraca ranking plików i ślad eksploracji;
reguły deterministyczne sprawdzają, czy model nie odczytał wyłączonych ścieżek;
SAST, SCA, secret scanning i testy jednostkowe dostarczają niezależnych sygnałów;
człowiek ocenia dowody i przypisuje właściciela;
poprawka przechodzi code review, test bezpieczeństwa i regresję.

Model nie powinien mieć poświadczeń do produkcji, możliwości publikowania paczek ani prawa samodzielnego zatwierdzania zmian. Warto wykorzystać wzorzec opisany w materiale o prompt injection w agentach CI/CD: oddzielić instrukcję sterującą od treści repozytorium, traktować komentarze i dokumentację jak niezaufane dane oraz wymagać jawnej zgody na operacje zmieniające stan.

Zagrożenia specyficzne dla analizy repozytorium przez AI

Kod jest jednocześnie materiałem analitycznym i wejściem kontrolowanym częściowo przez deweloperów oraz zależności zewnętrzne. Złośliwy pull request może zawierać komentarz próbujący przekonać model, że ma pominąć plik, ukryć wynik lub odczytać sekret. Nawet jeżeli Antares ma wąski zakres, cały wrapper, agent terminalowy i parser wyników muszą być odporne na instrukcje znajdujące się w danych.

Drugim problemem jest nadmierne zaufanie. Czytelny ślad poszukiwania może wyglądać wiarygodnie, choć model ominął alias, kod generowany albo inną gałąź konfiguracji. Ślad ma wspierać audyt, nie zastępować dowodu. Każde krytyczne wskazanie powinno zawierać plik, zakres, klasę problemu, źródło hipotezy oraz niezależny sposób weryfikacji.

Trzecie ryzyko to wyciek przez telemetrykę. Nawet przy lokalnym modelu system obserwowalności może wysyłać fragmenty promptów, ścieżki plików lub odpowiedzi do zewnętrznego SaaS. Projektując monitoring, stosuj zasady z przewodnika o obserwowalności agentów AI: redakcję danych, krótką retencję, kontrolę dostępu i osobne identyfikatory przebiegów bez kopiowania pełnego kodu.

Minimalna architektura bezpiecznego wdrożenia

Runner powinien być efemeryczny, bez dostępu przychodzącego i z domyślnie zablokowanym egress. Repozytorium montuje się tylko do odczytu, a katalog roboczy niszczy po zadaniu. Model oraz zależności są pobierane z wewnętrznego, podpisanego rejestru. Wyjście może trafić wyłącznie do kontrolowanego systemu wyników AppSec.

Zakres danych powinien być minimalny. Jeżeli zadanie dotyczy jednego serwisu, nie ma powodu udostępniać całego monorepo. Sekrety historyczne i pliki środowiskowe należy wykluczyć, a próby wejścia do zabronionej ścieżki logować. Wrażliwe repozytoria warto analizować w oddzielnych pulach wykonawczych.

Zespół powinien również prowadzić rejestr modelu: źródło, hash wag, wersję kodu wykonawczego, konfigurację, zbiór testów, znane ograniczenia i właściciela. To ta sama dyscyplina, którą opisujemy szerzej w artykule o rejestrze modeli AI i governance.

Jak mierzyć rezultat w AppSec

Najważniejszą metryką nie jest liczba wygenerowanych alertów. Liczy się skrócenie czasu od publikacji informacji o luce do znalezienia właściwego kodu oraz odsetek trafnych wskazań wśród pierwszych plików. Przydatne są także:

czas pracy eksperta potrzebny do potwierdzenia lub odrzucenia wyniku;
liczba rzeczywistych podatności odnalezionych wcześniej niż przez obecny proces;
false negative rate na kontrolowanym zestawie regresyjnym;
koszt jednego potwierdzonego wyniku, nie jednego przebiegu;
stabilność wyniku po zmianie promptu, wrappera albo modelu;
odsetek rekomendacji zamkniętych poprawką i ponownym testem.

Wynik Antares warto korelować z modelem zagrożeń. Plik dotyczący deserializacji w publicznym API ma inny priorytet niż ta sama klasa kodu w wyłączonym narzędziu deweloperskim. Proces threat modelingu dostarcza danych o aktywach, granicach zaufania i osiągalności, których sam model lokalizacyjny nie zna.

Co zespół powinien zrobić teraz

Pobrać model wyłącznie z oficjalnego źródła i przypiąć konkretną rewizję.
Uruchomić go w izolowanym runnerze na kilku wcześniej naprawionych lukach.
Porównać pierwsze N wskazań z SAST, SCA i wiedzą właścicieli kodu.
Sprawdzić, czy repozytorium może sterować agentem przez komentarze, README lub nazwy plików.
Zablokować zapis do repozytorium i dostęp do poświadczeń produkcyjnych.
Zdefiniować próg przejścia z trybu obserwacyjnego do ostrzegania, a dopiero później do blokowania.
Dokumentować fałszywe wyniki oraz przypadki pominięte, aby wykrywać regresje modelu.

FAQ

Czy Antares zastąpi SAST?

Nie. Cisco wprost umieszcza go obok, a nie zamiast istniejącego zestawu AppSec. SAST ma deterministyczne reguły i przepływy danych, SCA identyfikuje komponenty, DAST sprawdza zachowanie uruchomionej aplikacji, a pentest aplikacji webowej łączy technikę z logiką biznesową. Antares pomaga ustalić, gdzie człowiek powinien spojrzeć najpierw.

Czy otwarte wagi oznaczają otwarty kod i dane treningowe?

Nie zawsze. „Open weight” mówi przede wszystkim o dostępności parametrów modelu. Przed użyciem trzeba osobno sprawdzić licencję, kod wykonawczy, dokumentację zbioru, tokenizer oraz warunki redystrybucji. Nie należy automatycznie używać określenia open source dla całego systemu.

Czy model można od razu podłączyć do każdego commitu?

Technicznie może być wystarczająco mały, ale operacyjnie lepiej zacząć od pomiaru. Najpierw shadow mode, potem komentarz nieblokujący, a dopiero po potwierdzeniu jakości ograniczona bramka. Inaczej zespół może nauczyć się ignorować kolejny głośny skaner.

Najważniejszy wniosek

Antares jest interesujący nie dlatego, że obiecuje autonomiczne hakowanie lub magiczną naprawę kodu. Pokazuje bardziej realistyczny kierunek: mały model, wąskie zadanie, lokalne wykonanie, mierzalny benchmark i wynik przeznaczony do recenzji. Jeżeli organizacja zachowa izolację, wersjonowanie, niezależne kontrole i odpowiedzialność człowieka, może skrócić kosztowny etap lokalizacji podatności bez wysyłania całego repozytorium do zewnętrznej chmury.

Chcesz sprawdzić, czy analiza kodu wspierana przez AI daje wiarygodne wyniki i nie otwiera nowej ścieżki ataku? BreachRoad może połączyć audyt bezpieczeństwa AI z przeglądem AppSec i kontrolowanym testem pipeline. Skontaktuj się z nami, aby ustalić zakres pilotażu.