Od linku do repozytorium do zweryfikowanych podatności

Pobieramy wskazaną przez Ciebie gałąź za pomocą płytkiego klonowania git z filtrem blobów przez HTTPS. Haki Git są wyłączone, dowiązania symboliczne są pobierane jako zwykłe pliki, a wszystkie protokoły inne niż HTTPS są odrzucane. Prywatne adresy sieciowe są blokowane, więc nie można skierować skanera do hostów wewnętrznych.

Kod z repozytorium nigdy nie jest uruchamiany: nie wykonujemy kompilacji, nie instalujemy pakietów ani nie uruchamiamy testów. Kopia robocza jest usuwana po zakończeniu skanowania.

Każdy źródłowy plik tekstowy jest wymieniony wraz z językiem programowania i rozmiarem. Pomijamy kod dołączony do projektu, pliki wygenerowane, zminimalizowane pakiety i pliki blokad zależności. Każdy plik otrzymuje ocenę ryzyka na podstawie niebezpiecznych operacji — kopiowania pamięci, uruchamiania powłoki, deserializacji, budowania zapytań SQL, renderowania szablonów, łączenia ścieżek, kodu kryptograficznego i uwierzytelniającego — oraz krytycznych ścieżek, takich jak parsery, obsługa protokołów i trasowanie żądań.

Jeśli repozytorium zawiera plik .oss-scanner/threat_model.md (ten sam plik, który odczytuje skaner Anthropic), plik SECURITY.md lub model zagrożeń podany podczas rejestracji projektu, skaner postępuje zgodnie z jego treścią. W przeciwnym razie model analizuje plik README, układ katalogów i pliki o najwyższym ryzyku, a następnie tworzy jego wstępną wersję: opis projektu, miejsca, do których trafiają niezaufane dane wejściowe, oraz zakres wyłączony z analizy.

Model zagrożeń wskazuje również pliki, na których należy się skupić, dzięki czemu audyt koncentruje się na kodzie, do którego atakujący rzeczywiście może uzyskać dostęp.

Pliki o najwyższym ryzyku są łączone w duże pakiety wraz z numerami wierszy i przesyłane do modelu rozumującego z dołączonym modelem zagrożeń. Model wyszukuje problemy, które zgłosiłby uważny audytor:

• bezpieczeństwo pamięci: przepełnienia, użycie po zwolnieniu pamięci, obcięcie liczby całkowitej
• wstrzykiwanie: SQL, poleceń, szablonów, przechodzenie przez ścieżki, SSRF
• logika uwierzytelniania, autoryzacji i sesji
• niebezpieczna deserializacja i błędna interpretacja danych przez parser
• niewłaściwe użycie kryptografii i obsługa sekretów

Szybkie skanowanie wykorzystuje Claude Haiku z umiarkowanym budżetem. Głębokie skanowanie projektów objętych programem wykorzystuje Claude Sonnet i analizuje do czterech razy więcej kodu.

Każde potencjalne zgłoszenie trafia do osobnego agenta weryfikującego, który otrzymuje nowy kontekst. Jego zadaniem jest obalenie zgłoszenia: prześledzenie przepływu danych, sprawdzenie, czy walidacja nie odbywa się w innym miejscu, oraz ustalenie, czy zgodnie z modelem zagrożeń atakujący rzeczywiście kontroluje dane wejściowe. Pozostają tylko zgłoszenia potwierdzone przez agenta lub ocenione przez niego jako prawdopodobne; pozostałe są zliczane jako odrzucone.

Dla zgłoszeń, które przejdą weryfikację, agent opisuje przyczynę źródłową, przygotowuje test odtwarzający błąd oraz minimalną proponowaną poprawkę w postaci ujednoliconego pliku różnicowego.

Duplikaty wynikające z tej samej przyczyny źródłowej są łączone. Polecenie git blame dla podatnych wierszy wskazuje najnowszy commit, który je zmienił — zwykle ten, który wprowadził błąd — dzięki czemu możesz dodać znacznik Fixes: i ustalić, których wydań dotyczy problem.

Raport jest zapisywany pod losowym, trudnym do odgadnięcia identyfikatorem. Możesz wyeksportować go jako Markdown na potrzeby ostrzeżenia o podatności, JSON do narzędzi lub SARIF 2.1.0 do skanowania kodu w GitHub.