Analiza / Opinia
Recenzent trafił w linijkę z podatnością i jej nie nazwał
Agent recenzujący kod trafił w linijkę, w której adres od użytkownika szedł prosto do Kernel#open w Rubym, ale nie nazwał podatności, bo zabrakło mu wiedzy o jednej funkcji z biblioteki standardowej Ruby. Kodus wyciąga z tego, że o jakości przeglądu decyduje harness wokół modelu, i przyznaje, że własny graf wywołań doklejał do promptu, zamiast dać agentowi narzędzie getCallers w trakcie rozumowania. Firma zapisuje teraz pulę kandydatów sprzed filtrów, żeby widzieć, w którym z czterech miejsc ginie błąd, choć w całym wpisie nie pada ani jedna liczba z ewaluacji.
Napisała AI, żeby oszczędzić Ci czytania setek źródeł. · Jak to działa
Analiza / Opinia · 4 min ·
Pull request przepuszczał adres URL podany przez użytkownika prosto do Kernel#open w Rubym. Agent sprawdzający tę zmianę trafił dokładnie w tę linijkę, prześledził wartość aż do miejsca, w którym wpisuje ją użytkownik, i zgłosił nawet kilka uwag do sąsiedniego kodu. Nie nazwał tylko rzeczy najważniejszej: Kernel#open potrafi w tym kontekście otworzyć połączenie sieciowe, więc atakujący może kazać serwerowi wysłać żądanie pod dowolny adres.
Dosypanie modelowi reszty repozytorium nic by nie dało, bo właściwy kod miał już przed sobą, a prośba o uważniejszą lekturę diffa najpewniej skończyłaby się kolejnym pewnym siebie przebiegiem po tych samych linijkach. Zabrakło wiedzy o jednej funkcji z biblioteki standardowej Ruby.
Kodus, firma budująca własny silnik do przeglądu kodu, opisał ten nieudany przegląd na blogu jako moment, po którym w firmie przestali odpowiadać zmianą modelu na każdy przeoczony błąd. Kupuję tę diagnozę: model pracuje wewnątrz większego systemu, który buduje mu prompt, podaje narzędzia i decyduje, kiedy przegląd się kończy. Ten system nazywa się harness i przy przeglądzie kodu często waży na wyniku tyle samo, co same wagi modelu.
Czytaj dalej za darmo
Podaj e-mail, aby odblokować pełną treść i cały serwis. Zapiszemy Cię do newslettera.
