Anthropic OSS Scanner oferuje bezpłatne audyty open source, ale opiekunowie muszą weryfikować wyniki AI

Anthropic uruchomił 8 października Anthropic OSS Scanner, oferując kwalifikującym się projektom open source cykliczne audyty podatności bez opłat. Usługa stanowi znaczące rozszerzenie badań nad bezpieczeństwem wspomaganych przez AI. Przenosi jednak istotny ciężar na opiekunów projektów, ponieważ raporty trafiają do nich bez weryfikacji przez człowieka.

To właśnie ten kompromis definiuje uruchomienie usługi. Anthropic twierdzi, że jego modele mogą analizować więcej kodu, niż badacze bezpieczeństwa firmy są w stanie ręcznie przejrzeć. OSS Scanner usuwa to ograniczenie procesu weryfikacji, przesyłając surowe ustalenia bezpośrednio do uczestniczących projektów.

Moment jest niewygodny dla opiekunów projektów open source. Google niedawno wstrzymał część swojego programu nagród za zgłaszanie podatności w open source po otrzymaniu rosnącej liczby nieprawidłowych zautomatyzowanych zgłoszeń. Projekt curl również zakończył program bug bounty, gdy opiekunowie zaczęli mieć trudności z niskiej jakości zgłoszeniami.

Anthropic uważa, że jego raporty oferują obecnie znacznie lepsze dowody niż ustalenia generowane przez AI, które wcześniej frustrowały opiekunów projektów. Wstępne opinie projektów potwierdzają to twierdzenie w wybranych przypadkach. Publiczna usługa nie wykazała jednak jeszcze, jak jej trafność utrzyma się w szerszym zakresie repozytoriów.

Anthropic OSS Scanner wymienia weryfikację przez człowieka na szybkość

Anthropic OSS Scanner daje opiekunom projektów wcześniejszy dostęp do potencjalnych podatności, ale każdy uczestniczący projekt staje się odpowiedzialny za potwierdzenie wniosków modelu.

Według ogłoszenia OSS Scanner uczestniczące projekty otrzymują okresowe skany od najsilniejszych modeli Anthropic. Modele te obejmują Claude Mythos, którego Anthropic opracował do zaawansowanych prac w dziedzinie cyberbezpieczeństwa.

Raporty są w całości generowane przez model. Anthropic nie obiecuje, że badacz bezpieczeństwa zweryfikuje ustalenie, zanim trafi ono do projektu. Firma wyraźnie ostrzega, że raporty mogą być błędne lub nieprawidłowe.

Każdy raport ma zawierać więcej niż tylko podejrzaną lokalizację w kodzie. Anthropic podaje, że dostarcza wyjaśnienie, instrukcje reprodukcji oraz propozycję poprawki, gdy jest ona dostępna. Raport może również obejmować analizę historii kodu wskazującą, kiedy pojawił się podejrzewany błąd.

Te dowody mają znaczenie, ponieważ opiekunowie potrzebują powtarzalnego sposobu odróżniania rzeczywistej podatności od wiarygodnie brzmiącego wyniku modelu. Konkretny scenariusz reprodukcji pozwala inżynierowi uruchomić odpowiedni kod i sprawdzić, czy zgłoszone zachowanie rzeczywiście występuje.

Propozycja poprawki może skrócić kolejny etap. Nie eliminuje jednak potrzeby przeglądu, testów, kontroli zgodności i koordynacji z podmiotami zależnymi. Poprawki bezpieczeństwa czasem zmieniają zachowanie, na którym użytkownicy lub zależne oprogramowanie po cichu polegają.

Anthropic przetestował ten proces z dziesiątkami projektów open source, zanim szerzej udostępnił możliwość zapisów. Według firmy wczesne skany wygenerowały setki raportów. Anthropic twierdzi, że kilka ustaleń można było połączyć w exploity umożliwiające nieuwierzytelnione zdalne wykonanie kodu.

To poważna kategoria podatności, ponieważ atakujący może potencjalnie wykonać kod bez uprzedniego zalogowania się do dotkniętego systemu. Anthropic nie opublikował jednak kompletnej, niezależnej oceny tych wczesnych wyników.

Uruchomienie usługi rozszerza działania, którymi Anthropic wcześniej zajmował się w ramach programu skoordynowanego ujawniania podatności. W tym procesie badacze bezpieczeństwa weryfikowali ustalenia przed powiadomieniem opiekunów projektów. Publiczne ujawnienie następowało zwykle zgodnie z określonym harmonogramem.

OSS Scanner tworzy odrębną szybką ścieżkę. Jego automatyczne ustalenia są prywatnie wysyłane e-mailem do opiekunów, a Anthropic twierdzi, że nie będzie ich automatycznie publikować zgodnie ze standardowym terminem ujawnienia.

Jeśli Anthropic później potwierdzi ustalenie w ramach swojego programu z weryfikacją przez człowieka, raport może trafić do istniejącego procesu ujawniania firmy. Do tego czasu automatyczny raport pozostaje niezweryfikowanym prywatnym zgłoszeniem.

To rozróżnienie jest kluczowe. Anthropic nie oferuje certyfikacji, że oprogramowanie objęte programem jest bezpieczne. Oferuje kolejne źródło hipotez dotyczących podatności, popartych odtwarzalnymi dowodami tam, gdzie system działa skutecznie.

Liczby wyjaśniają, dlaczego Anthropic zmienił swój proces

Usługa istnieje, ponieważ modele Anthropic mogą generować kandydatów na ustalenia znacznie szybciej, niż badacze firmy są w stanie je zweryfikować.

Anthropic podaje, że podczas skanowania istotnych projektów oprogramowania w ciągu poprzednich sześciu miesięcy wykrył ponad 29 000 potencjalnych podatności. W tym okresie jego badacze ręcznie przejrzeli około 6 000 raportów.

Oznacza to, że ponad 23 000 potencjalnych ustaleń pozostało poza zakończonym procesem weryfikacji przez człowieka. Część będzie reprezentować rzeczywiste problemy bezpieczeństwa. Inne okażą się duplikatami, nieporozumieniami, błędami o niewielkim wpływie lub nieprawidłowymi wnioskami modelu.

Anthropic twierdzi również, że opiekunowie projektów coraz częściej prosili o zbiorczy dostęp do niezweryfikowanych wyników. Firma podaje, że wysłała niemal 5 000 niezweryfikowanych ustaleń do projektów, które poprosiły o otrzymanie wszystkiego, co było dostępne.

Liczby te wyjaśniają operacyjną logikę stojącą za Anthropic OSS Scanner. Dalsze wymaganie ręcznej weryfikacji ograniczałoby liczbę repozytoriów, które Anthropic mógłby objąć. Usunięcie tego wymogu jednocześnie zwiększa zasięg, częstotliwość i niepewność.

Firma łączy tę zmianę z poprawą wydajności modeli. Anthropic twierdzi, że modele językowe znajdowały mniej niż 20 procent podatności w benchmarku CyberGym na początku 2025 roku. Według firmy wynik przekroczył 85 procent w 2026 roku.

Benchmark jest znormalizowanym zestawem testowym, a nie gwarancją działania w praktyce. Rzeczywiste repozytoria zawierają nietypowe systemy budowania, nieudokumentowane założenia, generowany kod i specyficzne dla projektu granice bezpieczeństwa.

Model może też zidentyfikować rzeczywisty błąd oprogramowania, nie oceniając prawidłowo jego wpływu na bezpieczeństwo. Odczyt poza granicami bufora w nieosiągalnym narzędziu testowym stwarza inne ryzyko niż taki sam błąd wystawiony przez usługę sieciową.

Własne liczby Anthropic ujawniają drugie ograniczenie. Znajdowanie potencjalnych problemów nie jest już jedynym deficytowym zasobem. Weryfikacja, priorytetyzacja, usuwanie problemów i ujawnianie stają się trudniejszymi częściami procesu.

Ta zmiana wywiera presję na projekty bez dedykowanych zespołów bezpieczeństwa. Duża biblioteka infrastrukturalna może zależeć od niewielkiej grupy opiekunów, którzy już zajmują się prośbami o funkcje, regresjami, problemami z pakietowaniem i wsparciem społeczności.

Nawet dobrze ustrukturyzowany raport pochłania uwagę. Ktoś musi odtworzyć zachowanie, potwierdzić dotknięte wersje, ocenić możliwość wykorzystania, zaprojektować bezpieczną poprawkę i skoordynować wydania.

Zespoły bezpieczeństwa od dawna wykorzystują analizę statyczną, fuzzing i skanowanie zależności do identyfikowania podejrzanego zachowania. Fuzzing dostarcza do oprogramowania nieoczekiwane dane wejściowe, aby ujawniać awarie lub inne błędy.

Skanowanie podatności przez AI dodaje warstwę rozumowania. Model może badać relacje między funkcjami, wywnioskować zamierzone zachowanie, analizować historię wersji i tworzyć ukierunkowany test.

Anthropic podaje, że jego modele czasami podejmowały nowe ścieżki dochodzenia po tym, jak konwencjonalne techniki nie znalazły niczego. Wcześniejsze badania obejmowały analizę historii kontroli wersji i pisanie programów proof-of-concept dla podejrzewanych podatności.

To szersze rozumowanie może wykrywać błędy, które narzędzia oparte na wzorcach pomijają. Może też tworzyć przekonującą, lecz błędną narrację. Jakość towarzyszących dowodów ma zatem większe znaczenie niż płynność wyjaśnienia.

Opiekunowie projektów open source stają się ostatnią warstwą weryfikacji

Bezpłatna usługa Anthropic przenosi kosztowne obliczenia modeli poza opiekunów projektów, ale nie eliminuje ludzkiego kosztu wstępnej oceny bezpieczeństwa.

Główni opiekunowie muszą dołączyć za pośrednictwem repozytorium zapisów projektu. Przesyłają pull request zawierający szczegóły konfiguracji i instrukcje budowania oprogramowania.

Każdy projekt podaje adres repozytorium, główny kontakt ds. bezpieczeństwa oraz Dockerfile. Dockerfile opisuje środowisko i polecenia potrzebne do zbudowania projektu wewnątrz kontenera.

Projekty mogą również dostarczyć model zagrożeń. Ten dokument wyjaśnia, które zasoby są istotne, gdzie wprowadzane są niezaufane dane oraz jak opiekunowie klasyfikują wagę problemu.

Ten kontekst może zapobiec oczywistym nieporozumieniom. W przeciwnym razie skaner mógłby uznać celowe zachowanie za podatność albo zawyżyć znaczenie kodu, który nigdy nie obsługuje niezaufanych danych wejściowych.

Anthropic buduje uczestniczące projekty w izolowanych maszynach wirtualnych. Konfiguracja może korzystać z dostępu do sieci, aby pobrać wymagane zależności. Właściwa analiza bezpieczeństwa działa bez dostępu do internetu, w utwardzonych piaskownicach.

Ustalenia są następnie wysyłane e-mailem do wyznaczonych kontaktów projektu. Opiekunowie mogą poprosić o szyfrowane dostarczanie, publikując klucz OpenPGP w konfiguracji zapisów.

Usługa jest ograniczona do kwalifikujących się projektów open source. Anthropic twierdzi, że kryteria kwalifikacji przypominają te stosowane w programie OSS-Fuzz Google. Projekty powinny mieć krytyczne znaczenie dla infrastruktury lub bezpieczeństwa użytkowników.

Ten standard odróżnia OSS Scanner od publicznego narzędzia, które każdy może skierować przeciwko dowolnemu repozytorium. Anthropic kontroluje zapisy i pokrywa koszt obliczeń modeli dla zaakceptowanych projektów.

Firma stosuje również bardziej eksperymentalne i wymagające większej liczby tokenów metody skanowania niż w swoim ogólnym komercyjnym produkcie bezpieczeństwa. To podejście pozycjonuje usługę open source jako poligon doświadczalny dla głębszych audytów.

Opiekunowie zachowują kontrolę po zapisaniu projektu. Mogą edytować konfigurację, aktualizować instrukcje budowania, wstrzymać skanowanie lub wycofać projekt za pośrednictwem kolejnego pull requestu.

Decydują też, co zrobić z każdym ustaleniem. Anthropic nie tworzy automatycznie publicznego zgłoszenia, nie przypisuje identyfikatora podatności ani nie narzuca terminu ujawnienia dla surowych automatycznych wyników.

Takie podejście zmniejsza ryzyko, że nieprawidłowy raport publicznie oskarży projekt o dostarczanie exploatowalnej wady. Pozwala też uniknąć ujawniania szczegółów technicznych, zanim opiekunowie ocenią poprawkę.

Prywatne dostarczanie nie rozwiązuje jednak ograniczeń przepustowości. Niewielki projekt może nadal otrzymać więcej wiarygodnych raportów, niż jego wolontariusze są w stanie przetworzyć. Anthropic nie ogłosił uniwersalnego limitu liczby raportów.

Projekty będą potrzebować własnych zasad przyjmowania zgłoszeń. Praktyczny proces powinien oddzielać odtwarzalne problemy dostępne z zewnątrz od awarii wymagających nierealistycznych warunków.

Zespoły potrzebują także trwałych zapisów technicznych. Przeszukiwalna baza wiedzy dla zespołów inżynieryjnych może zachować kroki reprodukcji, dotknięte wersje, decyzje dotyczące poprawek i zadania następcze.

Ta dokumentacja staje się ważna, gdy wiele raportów ma wspólną przyczynę źródłową. Bez niej różni opiekunowie mogą powtarzać to samo dochodzenie lub stosować niespójne poprawki w różnych gałęziach.

Skanowanie podatności przez AI staje teraz przed testem dokładności

Kluczowe pytanie nie brzmi już, czy model AI może znajdować podatności, lecz czy potrafi dostarczyć wystarczająco dużo zweryfikowanych, wartościowych sygnałów, aby uzasadnić uwagę opiekunów.

Najmocniejsze wczesne dowody Anthropic pochodzą od projektów, które przetestowały system. Współtwórca PostgreSQL Noah Misch powiedział, że kilka raportów zidentyfikowało błędy i zawierało poprawki niemal gotowe do użycia.

Anton Arapov z OpenSSL Corporation pozytywnie porównał surowe wyniki z raportami przygotowywanymi przez ludzi. Podkreślił wartość otrzymania działającego exploita, ponieważ inżynierowie mogą go bezpośrednio przetestować.

Najbardziej konkretny zgłoszony wynik pochodził od wolfSSL. Projekt otrzymał 74 zgłoszenia i uznał wszystkie poza dwoma za prawidłowe, zgodnie z informacją zwrotną opublikowaną przez Anthropic. Pięć zgłoszeń przekształciło się w rekordy Common Vulnerabilities and Exposures, powszechnie określane jako CVE.

Wynik ten sugeruje wysoką precyzję w ramach jednego wczesnego wdrożenia. Nie potwierdza jednak takiego samego wskaźnika dla różnych języków programowania, typów projektów, konfiguracji kompilacji i modeli zagrożeń.

Próbka pochodzi również z własnych materiałów premierowych Anthropic. Firma nie opublikowała kompletnego zbioru danych pokazującego każde zaakceptowane, odrzucone, zduplikowane i zakwestionowane zgłoszenie z pilotażu.

Niezależny pomiar będzie wymagał czegoś więcej niż liczenia zgłoszeń. Badacze powinni analizować prawidłowość, wagę problemu, duplikację, czas potrzebny na odtworzenie, czas potrzebny na przygotowanie poprawki oraz liczbę regresji spowodowanych sugerowanymi poprawkami.

Nakład pracy opiekunów projektu to kolejna ważna metryka. Skaner, który znajduje więcej rzeczywistych defektów, może nadal stanowić obciążenie netto, jeśli każde prawidłowe zgłoszenie trafia pośród wielu przekonujących fałszywych alarmów.

To ryzyko nie jest teoretyczne. Inne społeczności open source doświadczyły fali automatycznych zgłoszeń podatności, którym brakowało wystarczających dowodów.

Google poinformowało, że wstrzymało część swojego Open Source Software Vulnerability Rewards Program po znacznym wzroście liczby automatycznych zgłoszeń. Według wyjaśnień firmy większość tych zgłoszeń była nieprawidłowa.

Projekt curl zakończył program bug bounty w styczniu 2026 roku. Jego opiekunowie wielokrotnie ostrzegali, że raporty generowane przez AI pochłaniają czas, nie zapewniając odpowiadającej temu wartości dla bezpieczeństwa.

Opiekunowie Linuxa również opisali zduplikowane automatyczne zgłoszenia jako trudne do zarządzania. Wiele osób może uruchomić podobne narzędzia, znaleźć ten sam wątpliwy wzorzec i niezależnie wysłać niemal identyczne zgłoszenia.

Model opt-in Anthropic rozwiązuje część tego problemu. Tylko upoważnieni opiekunowie mogą zgłosić projekt, a raporty trafiają bezpośrednio do wyznaczonych kontaktów. Nie ma finansowej nagrody zachęcającej osoby z zewnątrz do maksymalizowania liczby zgłoszeń.

Wymagany reproducer podnosi również standard dowodowy. Raport pokazujący obserwowalne zachowanie jest bardziej użyteczny niż taki, który jedynie oznacza wzorzec kodu jako niebezpieczny.

Mimo to reproducer może pokazać awarię bez udowodnienia istotnej ścieżki ataku. Może też zależeć od sztucznej opcji kompilacji lub konfiguracji, której rzeczywiści użytkownicy nigdy nie wdrażają.

Proponowane poprawki są kolejnym źródłem niepewności. Poprawka może wyciszyć test, pozostawiając podstawową podatność nienaruszoną. Może też wprowadzić inny błąd lub naruszyć kompatybilność w dalszych elementach łańcucha.

Wczesne wyniki uzasadniają uważne zainteresowanie, a nie automatyczne zaufanie. Anthropic OSS Scanner musi udowodnić, że jego wyniki pozostają użyteczne po rozszerzeniu programu poza współpracujące projekty pilotażowe.

OSS Scanner uzupełnia istniejące narzędzia bezpieczeństwa

Anthropic pozycjonuje swój skaner jako dodatkowy system wykrywania, a nie zastępstwo dla fuzzerów, baz danych zależności, przeglądu kodu ani skoordynowanego ujawniania podatności.

Najbardziej oczywistym porównaniem historycznym jest usługa Google OSS-Fuzz service, która stale testuje ważne projekty open source za pomocą infrastruktury fuzzingu.

OSS-Fuzz jest skuteczny, gdy narzędzia potrafią generować dane wejściowe uruchamiające istotne zachowania programu. Jest szczególnie przydatny dla oprogramowania przetwarzającego pliki, komunikaty sieciowe lub inne niezaufane dane.

Fuzzing zależy jednak od uprzęży testowych i obserwowalnych awarii. Niektóre błędy autoryzacji, wady logiki biznesowej i wieloetapowe ścieżki ataku nie powodują natychmiastowego crasha.

Duże modele językowe mogą analizować takie zależności. Potrafią śledzić dane między różnymi komponentami, uwzględniać deklarowany model bezpieczeństwa projektu i generować ukierunkowane eksperymenty.

Kolejne porównanie oferuje tradycyjna analiza statyczna. Bada ona kod źródłowy bez wykonywania kompletnego programu i stosuje reguły identyfikujące ryzykowne przepływy lub wzorce.

Analizatory statyczne są powtarzalne i mogą działać przy każdej zmianie oprogramowania. Ich użyteczność zależy od jakości reguł, obsługi języków oraz zdolności zespołu do zarządzania powtarzającymi się ostrzeżeniami.

Analiza składu oprogramowania koncentruje się na dołączonych pakietach i znanych podatnościach. Może poinformować zespół, że zależność odpowiada wersji dotkniętej problemem, ale zwykle nie odkrywa nieznanego wcześniej defektu.

Usługa Anthropic jest ukierunkowana na nieznane podatności w kodzie źródłowym. Jej modele nie ograniczają się do porównywania repozytorium z istniejącym katalogiem podatności.

We wszystkich tych podejściach nadal konieczny jest przegląd wykonywany przez ludzi. Inżynierowie bezpieczeństwa rozumieją kontekst wdrożenia, motywacje atakujących, wymagania dotyczące kompatybilności oraz konsekwencje wykraczające poza bezpośrednie środowisko testowe skanera.

Narzędzia mogą się też wzajemnie wzmacniać. Hipoteza wygenerowana przez AI może stać się celem fuzzingu. Awaria wykryta przez fuzzer może dostarczyć modelowi konkretnych dowodów do analizy przyczyny źródłowej.

Model może zaproponować poprawkę, podczas gdy analiza statyczna i testy regresyjne sprawdzą zmianę pod kątem nowych problemów. Analiza zależności może następnie zidentyfikować produkty zależne, które potrzebują zaktualizowanego wydania.

Standardowa polityka ujawniania Anthropic pozostaje istotna, gdy badacze firmy potwierdzają problem. Polityka ta zasadniczo zakłada powiadomienie, a następnie ujawnienie po 90 dniach lub po wydaniu poprawki.

Polityka dopuszcza krótsze terminy w przypadku krytycznych podatności aktywnie wykorzystywanych przez atakujących. Opisuje także przedłużenia dla opiekunów projektów, którzy czynią postępy w kierunku poprawki.

Surowe raporty OSS Scanner działają poza tym automatycznym harmonogramem. Anthropic twierdzi, że nie będzie ich publikować, chyba że później trafią do procesu podlegającego przeglądowi przez ludzi.

To rozdzielenie daje opiekunom projektów przestrzeń na zbadanie sprawy. Rodzi jednak także nierozstrzygnięte pytanie dotyczące zarządzania zgłoszeniami, które przez długi czas pozostają nierozwiązane.

Anthropic twierdzi, że może ostatecznie wprowadzić okresy ujawniania dla niektórych automatycznych zgłoszeń o wysokiej wadze. Firma obiecuje wcześniejsze powiadomienie oraz możliwość opuszczenia usługi przez projekty, jeśli polityka się zmieni.

Na razie oferta przedkłada prywatny dostęp obronny nad publiczną rozliczalność. To rozsądne stanowisko na etapie premiery, lecz w dużej mierze opiera się na odpowiedzialnej reakcji uczestniczących opiekunów projektów.

Co zdecyduje o powodzeniu usługi

Trzy sygnały pokażą, czy Anthropic OSS Scanner stanie się użyteczną infrastrukturą bezpieczeństwa, czy kolejnym wymagającym źródłem automatycznych raportów.

Pierwszym sygnałem będą doświadczenia nowo zapisanych projektów. Informacje zwrotne z pilotażu Anthropic pochodziły od uznanych zespołów o dużej wiedzy technicznej i dojrzałych procesach bezpieczeństwa.

Szersze uczestnictwo sprawdzi skaner w różnych językach, architekturach i modelach utrzymania. Wyniki powinny pokazać, czy jego wczesna dokładność przenosi się poza wybraną grupę.

Publicznie udokumentowane poprawki dostarczą użytecznych dowodów. Odwołania do commitów, rekordy CVE i retrospektywy opiekunów mogą wskazać, które raporty przyniosły znaczące ulepszenia bezpieczeństwa.

Atrybucja jest opcjonalna, ale Anthropic zachęca projekty do umieszczania identyfikatora raportu skanera w odpowiednich commitach. Identyfikatory te mogą pomóc firmie mierzyć, które ustalenia doprowadziły do przygotowania poprawek.

Drugim sygnałem będzie jakość raportów w czasie. Anthropic powinno w końcu opublikować zagregowane dane dotyczące precyzji, duplikacji, wagi problemów i napraw, bez ujawniania nierozwiązanych podatności.

Najbardziej miarodajną wartością nie będzie łączna liczba potencjalnych ustaleń. Będzie nią odsetek zgłoszeń, które opiekunowie odtwarzają, akceptują i naprawiają bez nadmiernego nakładu pracy dochodzeniowej.

Malejący wskaźnik fałszywych alarmów wzmocni argument Anthropic, że modele językowe przekroczyły istotny próg użyteczności. Rosnące koszty triage osłabią ten argument.

Trzecim sygnałem będzie reakcja innych programów bezpieczeństwa. Google planuje ponownie przeanalizować wstrzymany proces nagród dla projektów open source po uporaniu się z nieprawidłowymi automatycznymi zgłoszeniami.

Udane wdrożenie Anthropic może wpłynąć na standardy dowodowe stosowane przez programy bug bounty i programy ujawniania podatności. Reproducery i testowalne poprawki mogą stać się oczekiwanym elementem każdego raportu generowanego przez maszynę.

Nieudane wdrożenie może zachęcić do stosowania ostrzejszych filtrów. Opiekunowie projektów mogą domyślnie odrzucać automatyczne ustalenia, chyba że uznana organizacja przeprowadzi walidację przez człowieka.

Anthropic musi też obserwować adaptację atakujących. Te same zdolności modeli, które pozwalają wykrywać problemy o charakterze obronnym, mogą pomagać złośliwym badaczom analizować szeroko wdrożone oprogramowanie.

Firma twierdzi, że stosuje kontrolę dostępu i monitorowanie wokół zaawansowanych możliwości cybernetycznych. OSS Scanner dodatkowo ogranicza ekspozycję, działając w izolowanych środowiskach i przekazując ustalenia prywatnie.

Środki te nie mogą wyeliminować szerszego wyścigu. Modele będą nadal się rozwijać, a podobne możliwości rozprzestrzenią się wśród dostawców, firm bezpieczeństwa i systemów lokalnych.

To sprawia, że szybkość napraw staje się coraz ważniejsza. Wykrycie podatności jako pierwszy zapewnia niewielką ochronę, jeśli projekt nie potrafi odtworzyć problemu, przygotować poprawki, przetestować jej i rozpowszechnić przed wykorzystaniem jej przez atakujących.

Opiekunowie projektów open source powinni oceniać tę usługę jako dodatkowe źródło informacji o bezpieczeństwie, a nie wyrok dotyczący ich kodu. Kwalifikujące się projekty mogą zapoznać się z wymaganiami uczestnictwa i zdecydować, czy dysponują wystarczającymi możliwościami triage.

Lepsze pytanie nie brzmi, czy skaner AI czasem popełnia błędy. Każda technika bezpieczeństwa ma ograniczenia. Pytanie brzmi, czy raporty Anthropic oszczędzają więcej czasu inżynierów, niż go zużywają.

Anthropic OSS Scanner musi teraz wykazać tę równowagę publicznie. Rezultaty osiągane przez opiekunów projektów w ciągu kolejnych kilku miesięcy będą ważniejsze niż liczba podatności, które modele firmy twierdzą, że potrafią znaleźć.