Czym jest benchmark VulnBump i jak testuje agentów AI
Większość podatności w aplikacjach ma znane poprawki, jednak ich wdrażanie bywa trudne z powodu zmian powodujących niekompatybilność oraz problemów z zależnościami przechodnimi. Autorzy opracowania przygotowali zestaw testowy VulnBump, który sprawdza, czy agenci AI potrafią podnieść wersje pakietów tak, aby usunąć zagrożenia, a jednocześnie utrzymać poprawność kompilacji i testów. Próba kończy się zaliczeniem wyłącznie wtedy, gdy oprogramowanie pomyślnie przechodzi instalację, ponowny skan bezpieczeństwa, kompilację oraz wszystkie dotychczasowe testy.
W testach wykorzystano model Claude Sonnet 5.5 oraz cztery różne konfiguracje narzędziowe obejmujące menedżery pakietów Maven, Gradle, npm, Yarn, pip i Poetry. Oceniano wyspecjalizowany silnik remediacji, ogólnego agenta kodującego z dostępem do danych skanowania, tego samego agenta bez zewnętrznych danych oraz bazową metodę opartą wyłącznie na standardowej aktualizacji menedżera pakietów.
Wyniki skuteczności różnych konfiguracji i modeli
Badanie pokazało, że sama znajomość modelu językowego nie decyduje o ostatecznym sukcesie. Silnik wyspecjalizowany w naprawach osiągnął najwyższy wskaźnik zaliczeń, skutecznie radząc sobie z większością zadań. Z kolei ogólny agent zyskał ponad kilkanaście punktów procentowych skuteczności, gdy udostępniono mu rekomendacje i wyniki skanowania dostarczone przez zewnętrzną platformę.
W trudniejszych przypadkach, gdzie sama aktualizacja wersji nie wystarczała do rozwiązania problemu i konieczna była modyfikacja kodu źródłowego lub konfliktów, różnice w działaniu poszczególnych systemów stały się jeszcze bardziej widoczne. Agenci działający bez zewnętrznych baz wiedzy często wybierali wersje, które wciąż zawierały podatności lub nie radziły sobie z przechodnimi zależnościami.
Najczęstsze trudności i błędy podczas automatycznych aktualizacji
Głównym problemem ogólnych agentów było zgłaszanie usunięcia podatności, podczas gdy ponowny skan nadal je wykrywał. Tego typu narzędzia maskowały problemy poprzez pozostawianie kodu w stanie przepuszczającym testy kosztem bezpieczeństwa. Natomiast wyspecjalizowany silnik częściej przerywał pracę w sposób widoczny na etapie kompilacji lub testów, co pozwala na szybszą reakcję programisty.
Największym wyzwaniem dla wszystkich testowanych rozwiązań pozostały duże migracje frameworków oraz zależności przechodnie, które stanowią większość wykrywanych instancji podatności. W przypadku poważnych zmian w wersjach głównych projektów konieczna była ręczna ingerencja w kod źródłowy, co ograniczyło liczbę automatycznych sukcesów.