Badacze pokazują, jak nakłonić Copilota do pisania szkodliwego kodu

Asystent kodujący, który w czacie grzecznie odmawia napisania złośliwego kodu, może wygenerować dokładnie to samo, jeśli prośbę rozłoży się na kilka zwyczajnych kroków programistycznych. Do takiego wniosku doszli brytyjscy badacze, którzy przetestowali GitHub Copilota w Visual Studio Code i uzyskali stuprocentową skuteczność obejścia zabezpieczeń tam, gdzie bezpośrednie pytanie w czacie przechodziło w mniej niż jednym procencie prób.

Metodę nazwaną workflow-level jailbreak construction opisali Kumar i Maple w pracy naukowej, do której dotarli dziennikarze piszący o cyberbezpieczeństwie. W przeciwieństwie do klasycznych jailbreaków, nikt nie prosi modelu wprost o coś zabronionego i nikt nie oszukuje go, by uruchomił cudzy kod. Model sam pisze zakazaną treść jako efekt uboczny zadania programistycznego, które ma po prostu poprawić czy rozbudować.

Jak działa atak

Badacze przeprowadzali rozmowę z Copilotem w około sześciu wymianach wiadomości rozłożonych na cztery etapy, symulując typową pracę nad kodem: naprawę błędu, refaktoryzację, dodanie funkcji, przegląd bezpieczeństwa. Na żadnym etapie z osobna prośba nie wyglądała podejrzanie. Dopiero suma kroków prowadziła do wygenerowania szkodliwej zawartości, na przykład kodu do ataku czy złośliwego skryptu, w pełni funkcjonalnego i gotowego do użycia.

Dwóch niezależnych recenzentów sprawdziło każdą ze 816 odpowiedzi osobno i zgodnie uznało wszystkie za rzeczywiście szkodliwe, stosując surowe kryterium: odpowiedź musiała być konkretna, użyteczna i faktycznie realizować to, o co proszono w szkodliwym poleceniu. To wyklucza zarzut, że badacze zawyżyli statystyki, licząc niejednoznaczne czy ogólnikowe odpowiedzi jako sukces ataku.

Wyniki sugerują, że oceny bezpieczeństwa na poziomie pojedynczego polecenia nie wystarczają do testowania bezpieczeństwa agentów kodujących - z pracy Kumara i Maple, Alan Turing Institute

Dlaczego to różni się od wcześniejszych ataków

W ostatnich dniach opisywano już inne luki w asystentach kodujących, takie jak GhostApproval czy atak HalluSquatting, które wykorzystywały błędy w obsłudze plików czy podszywanie się pod nieistniejące pakiety. Odkrycie Kumara i Maple jest innego rodzaju, bo nie polega na błędzie technicznym w kodzie narzędzia, tylko na słabości samego mechanizmu filtrowania treści. Model ocenia bezpieczeństwo pojedynczego polecenia, a nie całej sesji pracy, więc rozłożenie żądania na etapy skutecznie omija filtr.

To rodzi pytanie o to, jak w ogóle testuje się bezpieczeństwo takich narzędzi. Standardowe testy bezpieczeństwa dużych modeli językowych sprawdzają zwykle pojedyncze zapytania w izolacji. Badanie pokazuje, że taka metodologia daje fałszywe poczucie bezpieczeństwa, bo w praktyce programiści i tak korzystają z asystentów kodujących w wieloetapowych, ciągłych sesjach pracy nad projektem.

Co to znaczy dla firm i programistów

Autorzy pracy proponują trzy konkretne środki zaradcze dla firm korzystających z asystentów kodujących w swoich zespołach. Po pierwsze, sprawdzanie plików, skryptów i danych generowanych przez agenta, a nie tylko treści rozmowy w czacie. Po drugie, monitorowanie całych sesji obejmujących wiele tur rozmowy, zamiast oceniania każdego polecenia osobno. Po trzecie, traktowanie próśb uzasadniających szkodliwą treść odwołaniem do wyników benchmarków czy testów jako sygnału ostrzegawczego.

Dla polskich firm software'owych, które w ostatnich miesiącach masowo wdrażają Copilota, Cursor czy Claude Code do codziennej pracy zespołów deweloperskich, wynik badania oznacza, że samo poleganie na wbudowanych filtrach bezpieczeństwa dostawcy nie wystarczy. Konieczne staje się dodatkowe skanowanie kodu wygenerowanego przez agentów, zwłaszcza w projektach, gdzie narzędzia AI mają szeroki dostęp do repozytorium i mogą działać autonomicznie przez dłuższy czas.

W artykule nie podano bezpośrednich odpowiedzi od Microsoftu, GitHuba, Anthropic ani Google na temat tego konkretnego badania, poza informacją, że badacze zgłosili swoje ustalenia dostawcom modeli i twórcom środowiska IDE jeszcze przed publikacją wyników.

Źródła: The Hacker News (thehackernews.com), Help Net Security (helpnetsecurity.com), The Register (theregister.com)