Anthropic OSS Scanner: darmowe skany i raporty bez kontroli człowieka

8 października 2026 r. Anthropic uruchomił bezpłatny OSS Scanner dla projektów open source. Zakwalifikowane repozytoria mają być skanowane okresowo, a ich opiekunowie otrzymywać raporty o możliwych lukach. Ustalenia powstają automatycznie i mogą zostać wysłane bez wcześniejszej oceny przez człowieka.

Projekt trzeba zgłosić i uzyskać jego przyjęcie do programu. Dla opiekuna oznacza to dostęp do wyników bez opłaty za skanowanie, ale także pracę nad ustaleniem, czy zgłoszony błąd rzeczywiście występuje, jak poważny jest w danym projekcie i czy proponowana poprawka działa.

Który projekt może zostać przyjęty

Anthropic kieruje program do ugruntowanych projektów open source o istotnym znaczeniu dla infrastruktury lub bezpieczeństwa użytkowników. Przy ocenie bierze pod uwagę między innymi narażenie na ataki zdalne, liczbę użytkowników i projektów zależnych, wiek i częstotliwość aktualizacji kodu oraz jego zastosowanie. Każde zgłoszenie jest rozpatrywane indywidualnie; sama otwarta licencja nie wystarcza do przyjęcia.

Przed zgłoszeniem warto więc ustalić, gdzie niezaufane dane trafiają do kodu, kto korzysta z projektu i dlaczego wykryta w nim luka mogłaby mieć szersze skutki. Jeśli nie wynika to jasno z zastosowania repozytorium, opiekun może krótko wyjaśnić jego znaczenie dla bezpieczeństwa. Zupełnie nowe projekty zwykle nie spełniają warunków, a fork musi mieć odrębny charakter i samodzielnie wykazać swoje znaczenie.

Istotna jest również zdolność zespołu do obsługi wyników. Program jest przeznaczony przede wszystkim dla projektów, które radzą sobie już z potwierdzonymi zgłoszeniami poważnych luk. Szybsze dostarczenie kolejnych, niezweryfikowanych ustaleń zwiększa liczbę spraw wymagających oceny po stronie opiekunów.

Jak zgłosić repozytorium

Główny opiekun otwiera pull request w repozytorium programu OSS Scanner i dodaje katalog projektu z plikiem project.yaml. Zgłaszający musi być głównym opiekunem albo mieć jego upoważnienie; gdy projekt jest utrzymywany w ramach pracy dla organizacji, potrzebna jest także jej zgoda. Zgłoszenie jest publiczne, podobnie jak wpisane do konfiguracji adresy poczty elektronicznej.

Obowiązkowe dane to adres repozytorium do pobrania oraz primary_contact, czyli adres odbiorcy raportów i wiadomości o problemach z budowaniem projektu. Potrzebny jest też Dockerfile, który instaluje zależności i przygotowuje kod do audytu. Może znajdować się w repozytorium projektu albo obok pliku project.yaml w zgłoszeniu do programu. Przydatny, choć opcjonalny, jest plik threat_model.md: pozwala opisać ważne fragmenty kodu, niezaufane wejścia, zakres wyłączeń i sposób oceniania wagi błędów.

Konfiguracja dopuszcza dodatkowych odbiorców raportów. Można też podać publiczny klucz OpenPGP, aby wiadomości były szyfrowane; w takim wariancie raporty trafiają wyłącznie do głównego kontaktu, bez kopii do innych adresów. Przed otwarciem pull requestu opiekun może sprawdzić konfigurację narzędziem validate.py i zbudować przygotowany obraz, aby wykryć brakujące zależności.

Co trafia do opiekuna po skanie

Po przyjęciu projektu i pierwszym skanie wyniki są wysyłane pocztą elektroniczną. Zgłoszenie ma zawierać opis podejrzewanej luki, sposób jej odtworzenia oraz propozycję poprawki, jeśli model potrafi ją przygotować. Późniejsze skany mają szukać zarówno nowych problemów, jak i tych pominiętych wcześniej; częstotliwość może zależeć od obciążenia programu.

W procesie działają automatyczne etapy ponownego sprawdzania błędów i analizy ich przyczyn. Nie oznacza to ręcznego zatwierdzenia raportu przed wysłaniem. Zgłoszenie może powielać znany problem, błędnie określać jego wagę albo opierać się na nietrafnym założeniu o modelu zagrożeń projektu. Szczegółowy opis i dołączony patch są materiałem do odtworzenia błędu oraz przetestowania zmiany, a nie potwierdzeniem, że poprawka nadaje się już do wdrożenia.

To rozróżnienie ma znaczenie również wtedy, gdy opis wskazuje poważną lukę. Opiekun musi ustalić warunki jej wystąpienia, sprawdzić, których wersji dotyczy, i ocenić skutki proponowanej zmiany dla działania projektu. Na wiadomość z wynikami można odpowiedzieć uwagami, także gdy ustalenie okaże się nietrafne.

Kontrola odbiorcy i ujawnianie luk

Zasady OSS Scanner przewidują ręczne sprawdzenie, czy zgłoszenie pochodzi od uprawnionego opiekuna, czy adres odbiorcy należy do kontaktów bezpieczeństwa projektu i czy środowisko obejmuje właściwy kod. Uprawnienie odbiorcy jest sprawdzane ponownie przed wysyłką. Ta kontrola chroni dostęp do poufnych wyników; nie jest oceną każdej luki opisanej przez model.

Automatyczny, niezweryfikowany raport nie uruchamia terminu publicznego ujawnienia i Anthropic nie zamierza samodzielnie publikować takich ustaleń. Inna zasada obowiązuje, jeśli firma później potwierdzi konkretną lukę ręcznie w swojej procedurze skoordynowanego ujawniania i powiadomi o tym opiekuna: ujawnienie może wówczas nastąpić po 90 dniach od takiego powiadomienia. Samo otrzymanie wiadomości ze skanera nie rozpoczyna tego odliczania.

Raport może opisywać jeszcze niezałataną lukę, dlatego dostęp do niego powinny mieć osoby uprawnione do utrzymania projektu. Opiekun może wstrzymać kolejne automatyczne wiadomości przez ustawienie disabled: true w konfiguracji albo wycofać zgłoszenie. Po rezygnacji ewentualne zgłoszenia trafiają do projektu standardową ścieżką skoordynowanego ujawniania, z ręczną weryfikacją po stronie Anthropic.

Dlaczego audyt działa bez internetu

Przygotowanie projektu wymaga pobrania zależności, więc etap budowania obrazu ma dostęp do sieci. Następnie skan odbywa się w odizolowanym środowisku bez dostępu do internetu. Dockerfile musi zatem zawierać wszystko, czego kod i testy potrzebują podczas późniejszego audytu; brak zależności może zatrzymać budowanie, zanim skaner przeanalizuje projekt.

Przed wysłaniem wyników system automatycznie sprawdza też, czy zgłoszenie dotyczy kodu przyjętego projektu, a nie jedynie jego zależności. Raporty są przechowywane w odizolowanym środowisku chmurowym z dostępem ograniczonym do uprawnionych pracowników Anthropic. Dla zespołu utrzymującego projekt pozostaje to poufna informacja o możliwej luce, której znaczenie i proponowaną poprawkę trzeba ocenić we własnym kodzie.

Przeczytaj także: