Dwa silniki, jeden audyt
Dlaczego drugi model AI czytający ten sam kod zmienia wyniki audytu i jak połączyć dwa raporty, nie podwajając szumu.
· 5 min czytania · Lina Source LLC
Poproś dwóch doświadczonych recenzentów o przeczytanie tego samego pull requesta, a dostaniesz dwie różne listy. Jeden zauważy, że identyfikator z adresu URL nigdy nie jest porównywany z sesją; drugi, że pętla ponowień przy każdym błędzie zostawia otwarte połączenie z bazą. Żaden się nie myli i żaden nie jest kompletny. Modele językowe zachowują się tak samo i z tego samego powodu: to, co recenzent zauważa, zależy od tego, co widział wcześniej.
Zgodność to sygnał
Pojedynczy model podaje własną pewność. Ta liczba coś znaczy, ale jest deklaracją własną: model ocenia własną pracę. Gdy dwa modele trenowane przez różne laboratoria, na różnych danych i z różnymi słabościami, niezależnie trafiają na tę samą słabość w tym samym pliku, ta zgodność jest dowodem spoza modelu. To najbliższa druga opinia, jaką może mieć zautomatyzowany przegląd.
Odwrotność liczy się tak samo. Znalezisko zgłoszone przez jeden silnik nie jest przez to błędne, a odrzucenie go oznaczałoby wyrzucenie dokładnie tych błędów, które pojedynczy recenzent wychwytuje dobrze. Powinno zostać zgłoszone i przypisane, żebyś sam mógł je ocenić.
Gdzie jeden silnik milczy
W praktyce oba silniki najbardziej się rozchodzą przy klasach błędów wymagających rozumowania, a nie dopasowywania wzorców:
- Błędy logiki: rabat naliczony dwa razy, automat stanów akceptujący zwrot po zwrocie, sprawdzenie własności wykonane na niewłaściwym obiekcie.
- Autoryzacja zależna od frameworka: middleware chroniący grupę tras, ale nie handler API zamontowany obok.
- Wycieki zasobów i pamięci: listenery, timery i połączenia otwierane przy każdym żądaniu i zwalniane tylko na ścieżce sukcesu.
- Prompt injection ukryty w komentarzach lub danych testowych, który czyta się jak nieszkodliwy tekst, jeśli go nie szukasz.
Jak dwa raporty stają się jednym
Scalanie to moment, w którym drugi silnik albo się zwraca, albo podwaja szum. Zasady, na których stanęliśmy:
- Znaleziska dopasowujemy po tym, co identyfikuje błąd, a nie po sformułowaniu: po klasie CWE i pliku, w którym siedzi.
- Dopasowanie zgłaszamy raz, z surowszą z dwóch ocen istotności, bo bezpieczniejszy odczyt jest tym, według którego się działa.
- Zostaje opis, z którym programista coś zrobi: dłuższy dowód, konkretna łatka, uporządkowane kroki.
- Potwierdzone znalezisko dostaje wysoką pewność i etykietę obu silników.
- Znalezisko widziane przez jeden silnik zostaje zachowane, oznaczone silnikiem, który je znalazł.
Oba silniki czytają to samo źródło równocześnie, więc audyt nie trwa dwa razy dłużej; kosztuje dwa razy więcej, i dlatego należy do planu Pro. Jeśli drugi silnik jest niedostępny albo zwróci coś bezużytecznego, audyt kończy się na pierwszym, zamiast się wywrócić.
Nic z tego nie czyni raportu prawdziwym. Dwa silniki mogą się zgodzić i oba się mylić; dowód cytowany pod każdym znaleziskiem jest właśnie po to, żebyś sprawdzał, a nie ufał. Potwierdzenie daje ci kolejność: gdy przychodzi sto znalezisk, a masz jedno popołudnie, zacznij od tych, które zobaczyli dwaj niezależni recenzenci.