Adwersaryjny przegląd kodu: czego ten termin nie obejmuje

Adwersaryjny przegląd kodu to czytanie kodu źródłowego z pytaniem napastnika w głowie (jak można by sprawić, żeby to zrobiło coś, czego robić nie powinno) zamiast z pytaniem opiekuna, czy kod jest poprawny i uporządkowany. To, co dostarczamy pod tą nazwą, to podpisana dokumentacja ustaleń: każde potwierdzone ustalenie stopniowane według faktycznie osiągniętego dowodu, każda zbadana i uznana za solidną powierzchnia zapisana wraz z metodą, która ją badała, wytworzona przez recenzentów niezależnych od autora waszego kodu, rozstrzygnięta przez wskazaną z nazwiska osobę, na którą wasz nabywca, ubezpieczyciel lub klient może się powołać, i wycofana na piśmie, jeśli się nie obroni. Ta strona mówi, co to dodaje do pozostałych znaczeń, jakie wyrażenie przybrało, i ile to kosztuje.

Co to wyrażenie znaczy dzisiaj

W naszym odczytaniu rynku (wyszukiwanie we wrześniu 2026 r., nie spis) nazwę noszą cztery praktyki. Każda robi coś realnego. Dwie pierwsze są przyrządami na naszej własnej ławie.

Krytyczny prompt. Jeden agent pisze zmianę; drugi, w świeżym kontekście i często z innej rodziny modeli, czyta różnicę przez wrogie okulary. To usuwa samoocenę, co ma znaczenie tam, gdzie się stosuje: zmierzona na ośmiu modelach sędziujących preferencja własna była duża u jednego, umiarkowana u dwóch, bliska zeru u dwóch i lekko odwrócona u trzech (preferencja własna, arXiv:2410.21819). Jako praktyka daje ramę napastnika; nie daje sama z siebie zachowanej dokumentacji, miary tego, jak skorelowane były obie lektury, ani podpisu.

Orkiestrator dwóch recenzentów. Dwie rodziny modeli przeglądają tę samą zmianę niezależnie (czasem ślepo względem siebie), potem krytykują się nawzajem, a jedna z nich podsumowuje wynik, często sama wprowadzając poprawkę. Faza ślepa jest słuszna. Jako forma pozostawia model recenzujący sędzią własnych ustaleń i zarazem ich naprawiaczem, a sama z siebie nie wytwarza ani wzorca prawdy, ani miary korelacji.

Zespół platformowy. Produkt przeglądowy uruchamia kilka modeli wewnątrz własnego potoku i zwraca komentarze do pull requesta z poziomami wagi; nazwę nosi głównie przez sąsiedztwo, bo ci, którzy sami się tak opisują, uprawiają w przeważającej mierze dwie pierwsze praktyki. Wielość modeli jest tu decyzją projektową dostawcy; w postaci, w jakiej jest sprzedawana, forma nie ujawnia, który model co powiedział, na jakim dowodzie, ani jak często zgadzają się, myląc się. Daje objętość i integrację. Wątek komentarzy to nie audyt.

Dom ludzi myślących jak napastnik. Czytelnicy z ofensywnym doświadczeniem czytają kod źródłowy tak, jak zrobiłby to napastnik, czy to jako firma, czy jako tłum. To tu wymyślany jest atak, którego nikt nie sformułował, i to jest praktyka, którą nasza ma zasilać, a nie zastępować. Jako forma nie oddziela sama z siebie swojego dowodu od swojego wyroku, a niezależność jej recenzentów od siebie nawzajem pozostaje niezmierzona, jak u wszystkich.

Trzy własności, jedno słowo

Trzy własności pakuje się w słowo adwersaryjny: ramę zadania (pytanie napastnika), niezależność błędów między recenzentami oraz niezależność organizacyjną tego, kto podpisuje.

Drugi model, wybrany przez was, wycelowany w to, co mu pokażecie, oceniony przez was, nie jest przeciwnikiem. Jest drugim losowaniem z rozkładu, w którym już stoicie. Wynikają z tego trzy luki i żadna nie jest problemem jakości modelu.

Luka pierwsza: inny dostawca to nie niezależny świadek

Dwa modele różnych firm mają różne dane treningowe, więc zgoda jest potwierdzeniem, a milczenie uspokojeniem; taki jest tok rozumowania. Badanie obejmujące ponad 350 modeli wykazało, że gdy dwa modele oba się mylą, zgadzają się na tę samą błędną odpowiedź znacznie częściej niż przypadek (średnio 60 % w jednym rankingu i 42 % w drugim), przy czym pary od różnych dostawców były uwzględnione w całym badaniu; jego twierdzenie o różnych dostawcach jest wnioskiem z modelu regresyjnego badania, a nie analizą wyłącznie par międzydostawczych (Kim i in., ICML 2025, arXiv:2506.07962). Mierzono testy porównawcze i selekcję życiorysów, a nie przegląd podatności, więc nikomu nie daje liczby pokrycia dla kodu; ustala natomiast, że różni dostawcy nie są automatycznie niezależni. To, że powinno to zmienić sposób, w jaki czytacie zgodę drugiego recenzenta co do waszego kodu, jest naszym wnioskiem. Badacze tekstów uczynili z tej samej myśli regułę pięć wieków temu: odpis, o którym wykazano, że pochodzi od innego zachowanego odpisu, skreśla się z rachunku, nie dlatego że jest błędny, lecz dlatego że nie wnosi świadectwa.

Kanałem korelacji, który się przeocza, nie jest dostawca. Jest nim zlecenie: prompt, narzędzia, pakiet dowodowy i rama roli korelują recenzentów ponad podziałem na dostawców, a dwa modele, którym poda się ten sam wyselekcjonowany pakiet, dzielą wszystko, co ten pakiet pomija. Traktujemy zlecenie jako część aparatu i składamy je do akt przeglądu. Napastnik może użyć dowolnego modelu przepracowuje, na co to pozwala, a na co nie.

Luka druga: nikt nie decyduje, kiedy nie należy pytać o opinię

Niektóre twierdzenia mają wyrocznię, coś, co odpowiada na nie bez niczyjej opinii. Czy ta ścieżka się wykonuje? Wykonajcie ją. Czy specyfikacja dopuszcza tę wartość? Przeczytajcie ją. Tam, gdzie wyrocznia istnieje, test, który się wykonał, bije model, który rozumował, a także człowieka, który rozumował.

Zapytany, czy wyrażenie regularne pasuje do ścieżki, agent recenzujący wytworzy płynną opinię o tym, czy pasuje. Skierowanie tego pytania zamiast tego do wykonania jest decyzją inżynierską i w naszym odczytaniu większość narzędzi przeglądowych jej nie podjęła, ponieważ kategorię kupuje się na ustalenia na pull requesta, a ustalenie, które okazuje się dwuminutowym skryptem, nie jest ustaleniem. Znamy tę trudność od środka: zbudowaliśmy kontrolę, która miała wymusić właśnie takie kierowanie, i wydaliśmy ją z autotestem zdefiniowanym i nigdy niewywołanym. Co rozstrzyga ustalenie jest sekcją zwłok.

Twierdzenia bez wyroczni (jak poważne, czy to założenie zaufania jest do przyjęcia, czy napastnikowi chciałoby się) są kwestią osądu, a żadna ilość wyjścia modelu nie zamienia osądu w fakt.

Luka trzecia: nikt nie podpisał

Wewnętrzne uruchomienie agentów (na ilu modelach i przy jak odizolowanych kontekstach by nie było) daje wasze własne słowo o waszym własnym kodzie, przy czym nikt spoza waszej organizacji nie odpowiada za ani jedno jego zdanie. Z naszego doświadczenia to właśnie ta własność, o którą prawnicy nabywcy, underwriter ubezpieczyciela cybernetycznego i zespół bezpieczeństwa klienta korporacyjnego pytają najpierw, bo to ta, której wasz zespół nie dostarczy o własnej pracy.

Pod rządami Cyber Resilience Act większość producentów może dokonać samooceny, a następnie jest rozliczana z każdego dokumentu, który za nią stoi: sprawozdań z przeprowadzonych prób, w dokumentacji technicznej (załącznik VII pkt 6), potwierdzających obowiązek testowania (załącznik I część II pkt 3), przechowywanych dziesięć lat albo przez okres wsparcia, jeśli jest dłuższy (artykuł 13 ustęp 13). Zgłaszanie aktywnie wykorzystywanych podatności rozpoczęło się 11 września 2026 r.; rozporządzenie stosuje się w pełni od 11 grudnia 2027 r. Ocena zewnętrzna wspiera dokumentację, którą kompletujecie; nie jest tą dokumentacją, a my nie jesteśmy jednostką notyfikowaną. Normy mogą się przesunąć, termin zgłoszeń nie omawia harmonogram.

Co od nas dostajecie

Nic z poniższego nie jest tajemnicą. Dobrze prowadzony zespół mógłby przyjąć każdy z tych punktów. To, co kupujecie, to że wszystkie są wykonane, zapisane i podpisane, jako dokumentacja, którą możecie wręczyć komuś, kogo nie było w pokoju.

1. Najpierw wyrocznia. Twierdzenie rozstrzygalne kierowane jest do wykonania, kompilacji albo specyfikacji, zanim zamówi się w jego sprawie jakąkolwiek opinię. Nasze narzędzie do pakietów przeglądowych odmawia zbudowania zlecenia bez jego pakietu dowodowego, a zlecenie podaje, czego ten pakiet pokazać nie może, tak by milczenie instancji o czymś, czego nigdy nie otrzymała, czytać jako milczenie, a nie jako nieobecność.
2. Instancje są liniami modeli, a zlecenie jest w aktach. Recenzenci to odrębne rodziny modeli; instancje z dostępem do plików budują własny materiał dowodowy z kodu źródłowego, instancje bez niego czytają tylko to, co niesie zlecenie. Zlecenie, narzędzia i pakiet, które każda otrzymała, są częścią akt. Instancja, która nie odpowiedziała, jest odnotowana jako nieobecna, nigdy jako zgoda; instancja, która okazuje się dzielić kontekst z inną, zostaje oznaczona i niepoliczona, wraz z tym razem, gdy jedna z naszych okazała się mieć w kontekście nasz własny dokument ustaleń.
3. Ślepe odpowiedzi są utrwalane, zanim powstanie rozstrzygnięcie. To, co powiedziała każda instancja, dosłownie, wraz z jej kopertą (model, uprząż, data, otwarte pliki), zostaje zapisane, zanim ktokolwiek je porówna.
4. Zliczanie głosów niczego nie ustala. Ustalenia nie zamykają się przez głosowanie. Tam, gdzie recenzenci nie zgadzają się co do tego, co robi kod, rozstrzyga kod źródłowy; tam, gdzie odrzucenie opiera się na „niepewne”, twierdzenie trafia do zachowanej kolejki z osobą odpowiedzialną, terminem ważności i kryterium ponownego otwarcia, i zostaje na nowo wystawione świeżej linii modeli. Potwierdzenie wspina się po szczeblu dowodowym: ślad w kodzie źródłowym, dowód z kompilacji, test, odtworzenie w działaniu, a dla każdego twierdzenia probabilistycznego wskaźnik z przedziałem i zachowane dzienniki poszczególnych prób; wszystko, co zatrzymuje się poniżej szczebla, jest tylko prawdopodobne, co jest innym rozstrzygnięciem, a nie słabszym szczeblem. Powierzchnia zbadana i uznana za solidną jest odnotowana wraz z metodą, która ją badała, i z kontrolą, która pokazała, że ta metoda potrafi znaleźć to, czego szukała.
5. Podpisuje osoba wskazana z nazwiska i wycofuje się na piśmie. Pod oznaczeniem, na które wasi opiekunowie i wasz nabywca mogą się powołać, również wtedy, gdy ustalenie było nasze. Publikujemy przypadki, w których zawiodły nasze własne przyrządy, bo praktyka, która nie potrafi pokazać wam, gdzie się myliła, nie ma żadnej pozycji tam, gdzie twierdzi, że ma rację.

Odpytanie kilku modeli i przyjęcie większości to zespół modeli; w postaci, w jakiej jest sprzedawany, nie ujawnia kupującemu nic z powyższego. Gdy szukaliśmy we wrześniu 2026 r., nie znaleźliśmy żadnej praktyki oferującej ten zestaw jako protokół, który kupujący może skontrolować. To stwierdzenie o formie, nie o skuteczności wykrywania: o tym mówi to, co przekazujemy wam przed zakupem, poniżej.

Gdzie to się mieści w waszym zarządzaniu podatnościami

Znajdowanie nie jest tym, na czym zarabiamy honorarium. Skanery, fuzzery, platformy przeglądowe i wasi właśni inżynierowie wytwarzają już kandydatów szybciej, niż ktokolwiek zdoła ich rozstrzygnąć, a nasze zlecenia też coś znajdują; to produkt uboczny. To, za co nam się płaci, znajduje się tam, gdzie pęka cykl życia: rozstrzyganie: kandydat kierowany jest najpierw do swojej wyroczni, a potem stopniowany według osiągniętego szczebla dowodowego, tak by waga szła za dowodem, a nie za pewnością siebie modelu; zamknięcie: rozbieżność rozstrzyga kod źródłowy, a nie głosowanie, a „niepewne” trzymane jest w zachowanej kolejce z osobą odpowiedzialną, zamiast po cichu stawać się „ryzykiem zaakceptowanym”; oraz rękojmia: wynikiem jest dokumentacja, którą wskazana z nazwiska osoba spoza waszej organizacji podpisała i może wycofać, ta część dokumentacji technicznej, pakietu due diligence albo wniosku ubezpieczeniowego, której nie wytworzycie o własnej pracy. Postawcie nas w identyfikacji, a będziemy konkurować z waszym skanerem na liczby, w wyścigu, którego nie biegniemy. Postawcie nas tam, gdzie ustalenie staje się decyzją, której ktoś będzie później bronić, a dokumentacja jest produktem. Ustalenie to nie wyrok obejmuje pierwszy etap, a Co rozstrzyga ustalenie rozstrzygającą połowę drugiego; zachowana kolejka opisana jest powyżej. Zarządzanie podatnościami pod rządami Cyber Resilience Act przechodzi przez każdy etap wraz z odpowiadającym mu obowiązkiem z CRA.

Co mówimy wam przed zakupem

To chroni was, więc stoi na stronie, a nie w umowie.

• Sprzedajemy dokumentację, a nie skuteczność wykrywania. Nie wykazaliśmy, że panel znajduje więcej rzeczywistych defektów niż jeden dobry recenzent, i tego nie twierdzimy; zmierzyliśmy nasz pełny aparat wobec jednego taniego przejścia, w trybie prerejestrowanym i ocenianym na ślepo, i nie wygrał wyraźnie na żadnym z dwóch celów: jeden przegrał, a na drugim uruchomił własny próg precyzji jedynie przez usunięcie ustaleń, które audytor uznał za rzeczywiste. Zmierzyliśmy własną metodę i nie zarobiła na swój koszt. Raport przypadku, z którego pracujemy, mówi, że prostsza doktryna (jeden niezależny przegląd zewnętrzny wszystkiego, wobec czego zamierzacie działać, spory rozstrzygane przez czytanie kodu źródłowego, żadnej niezmierzonej liczby wypuszczonej na zewnątrz) pasuje do tych samych danych; jeśli to jedyne, co wyniesiecie z tej strony, wynieście to. Sprzedajemy dokumentację tego, że zostało to zrobione, pod podpisem. Niezależność między naszymi instancjami jest ograniczona procedurą i odnotowana, ale niezmierzona dla przeglądu kodu; nikt jej nie zmierzył. Każde ustalenie w dokumentacji osiągnęło nazwany szczebel albo jest oznaczone jako takie, które go nie osiągnęło.
• Gdzie autor jest w obiegu. Naszą regułą jest, że ten, kto podniósł sporne twierdzenie, nie rozstrzyga go sam. Nasza ława recenzencka to dwie osoby, co oznacza mniej zleceń, odmawianie pracy spoza naszej dziedziny oraz to, że reguła ta nie ma jeszcze żadnego mechanizmu, który by ją wymuszał; nasz własny raport przypadku wskazuje ten brak jako swoją największą nienaprawioną słabość. W praktyce sporne twierdzenie idzie do kodu źródłowego i do świeżej linii modeli, zanim zostanie zamknięte, rozstrzygnięcie jest odnotowane, a podpisujący wskazany, więc widzicie, które ustalenia zamknięto w ten sposób, i sami możecie je zważyć.
• Żadna metoda nie sięgnie defektu, którego żaden świadek nie podniósł. Kolacja wybiera tylko spośród tego, co zostało wypowiedziane. Testy, fuzzing, dowody i lektura specjalisty to odrębne drogi do tego samego miejsca, a poważny program stosuje je również.
• Jesteśmy niezależni od autora waszego kodu, ale nie bezinteresowni w każdej branży. CounterProof należy do grupy, która buduje infrastrukturę płatniczą i powierniczą dla aktywów cyfrowych. Jeśli budujecie na tych rynkach, nasza spółka powiązana może być waszym sąsiadem albo konkurentem. Mówimy wam na piśmie, co grupa buduje i gdzie działa, przed każdym zleceniem i zanim ruszą jakiekolwiek pieniądze, i nie wydajemy żadnej oceny kodu napisanego przez CounterProof ani przez jakąkolwiek spółkę z naszej grupy.

Rozbudowana argumentacja, wraz z własnymi ograniczeniami, znajduje się w naszym dokumencie roboczym, preprincie nierecenzowanym: research.counterproof.io (doi:10.5281/zenodo.22030516).

Pytania, które dostajemy

Czy adwersaryjny przegląd kodu to to samo co test penetracyjny? Nie. Test penetracyjny bada działający system; to czyta kod źródłowy przy ustalonym commicie i ustala twierdzenia wobec kodu. Oba myślą od strony napastnika, odpowiadają na inne pytania, a poważny program stosuje oba.

Czy nie mogę po prostu puścić dwóch modeli AI po własnym kodzie? Możecie, a drugi recenzent być może wydobędzie kandydatów, których pierwszy nie miał. Czego nie wytworzy, to niezależność organizacyjna: wasz zespół wybiera, co recenzenci widzą, formułuje pytania i ocenia odpowiedzi, a nikt z zewnątrz nie podpisał.

Platforma przeglądowa już uruchamia kilka modeli. Czy to nie panel? Nie. Zespół modeli, które wybiera dostawca, których pojedynczych odpowiedzi nie widzicie i których rozbieżności rozstrzygają się wewnątrz potoku, jest jednym narzędziem o wielu częściach. Panel to wiele narzędzi, których odpowiedzi zapisuje się osobno, a rozbieżności rozstrzyga kod źródłowy.

Czy adwersaryjny przegląd kodu dotyczy tylko kodu wygenerowanego przez AI? Nie. Metodzie jest obojętne, kto (lub co) napisał kod. Kod napisany przez maszynę sprawia jedynie, że lukę trudniej zignorować, bo rośnie objętość, a płynność ukrywa zgadywanie.

Czym to się różni od narzędzia do przeglądu kodu opartego na AI? Takie narzędzia generują ustalenia, a my używamy narzędzi tej klasy jako przyrządów. Czego narzędzie nie potrafi, to odpowiadać za swoje słowa ani podpisać.

Wnioski oznaczone jako takie powyżej, oraz tutaj: że zgodę drugiego recenzenta co do kodu należy dyskontować (Kim i in. mierzyli inne dziedziny); że zlecenie koreluje recenzentów; że te cztery praktyki są kształtem rynku i że narzędzia przeglądowe konkurują liczbą ustaleń na pull requesta (nasze odczytanie, jedno wyszukiwanie, wrzesień 2026 r.); że niezależność organizacyjna jest tym, o co nabywcy, ubezpieczyciele i kupujący korporacyjni pytają najpierw (nasze doświadczenie, nie badanie ankietowe). Jeśli coś tutaj jest błędne, poprawimy to na piśmie na tej stronie.