AI nauczyło się pisać kod odporny na ataki, których baliśmy się najbardziej. Wciąż nie umie odpowiedzieć na pytanie, czy ten użytkownik ma prawo do tych danych.

Trzy tygodnie temu opisaliśmy Bad Epoll i postawiliśmy tezę, że zdolności AI w bezpieczeństwie mają teksturę — obszary, w których model jest już nadludzki, i sąsiednie, w których jest ślepy. Wtedy chodziło o znajdowanie luk: AI błyskawicznie wykrywa błędy zapisane wprost w kodzie, jak dwudziestodziewięcioletni błąd w Squidzie, ale mija te, które istnieją tylko w splocie zdarzeń w czasie, jak wyścig w jądrze Linuksa. 22 lipca firma Xint — komercyjne ramię zespołu Theori, tego samego, którego autonomiczny system znalazł dwuletni błąd w Redisie — opublikowała badanie, które pokazuje tę samą teksturę z drugiej strony. Nie w znajdowaniu luk, lecz w ich tworzeniu: gdy AI samo pisze kod.

Wynik jest zaskakujący dokładnie tam, gdzie spodziewano się potwierdzenia obaw. Badacze weszli w tę analizę, oczekując lawiny błędów iniekcji — SQL injection, XSS — i luk w kontroli dostępu typu IDOR, czyli klasyki dziurawego kodu. Znaleźli coś przeciwnego. Iniekcje ledwie się pojawiły. A błędy, które zdominowały wyniki, to te, które wymagają zrozumienia całej aplikacji naraz — i które rosną wraz z jej wielkością. To jest ta sama granica co przy Bad Epoll, tylko przesunięta na drugą stronę klawiatury. AI opanowało to, co lokalne. Wciąż jest ślepe na to, co wymaga rozumowania o całości.

Co dokładnie zmierzono

Xint zbudował trzy scenariusze odpowiadające temu, jak ludzie faktycznie używają dziś AI do kodu. Pierwszy: nowa aplikacja z dobrze napisanej specyfikacji, tak jak robi to doświadczony programista nadzorujący proces. Drugi: nowa aplikacja z niedbałego polecenia „po prostu to zbuduj", reprezentująca rosnącą rzeszę przygodnych koderów. Trzeci: istniejąca, dojrzała aplikacja (Gnuboard7), przeniesiona do nowoczesnej architektury i „zahartowana" przez AI — żeby sprawdzić, czy samo utwardzanie wprowadza nowe luki. Każda dostała trzydziestominutowy skan analizujący i kod źródłowy, i zachowanie w działaniu.

Łącznie: 434 luki nadające się do wykorzystania — 196 w nowych aplikacjach, 238 w tej jednej przeniesionej. I tu od razu pierwsza uczciwość metodologiczna, o której trzeba powiedzieć: część „brownfield" to pojedyncza aplikacja, więc jej wyniku nie należy czytać jako statystyki, lecz jako ilustrację. To sam Xint zaznacza. Wartość badania nie leży w bezwzględnej liczbie, tylko w rozkładzie — w tym, jakie błędy się pojawiły, a jakie nie.

Najczęstsze były braki ograniczeń ruchu i ochrony przed przeciążeniem — 93 przypadki wyczerpania zasobów i podatności na odmowę usługi. To luki, które powstają, gdy programista prosi AI wyłącznie o funkcje, nie o odporność: efektem nie jest kradzież danych, lecz serwer, który atakujący może przewrócić albo rozkręcić do niekontrolowanych kosztów. Drugie w kolejności — 88 przypadków — były błędy autoryzacji i tak zwane IDOR, gdzie użytkownik uzyskuje dostęp do danych spoza swoich uprawnień. Trzecie, 54 przypadki, to przekraczanie granic dostępu i pokrewne. Wśród luk krytycznych prym wiodły zaszyte na stałe sekrety — klucze API i dane uwierzytelniające wprost w kodzie, 11 przypadków — oraz zdalne wykonanie kodu przez pozostawiony tryb debugowania, 6 przypadków.

Sedno: gdzie AI się poprawiło, a gdzie utknęło

Teraz najważniejsze, bo to jest właściwa teza tego badania, a nie sama liczba luk.

Badacze spodziewali się, że dominować będą iniekcje i błędy kontroli dostępu — bo to historycznie najczęstsze grzechy niedbałego kodu. Stało się odwrotnie. Iniekcje niemal się nie pojawiły. Błędy typu IDOR w mniejszych aplikacjach stanowiły ledwie 11 procent znalezisk. Wniosek Xint jest tu jednoznaczny: wiodące laboratoria naprawdę poprawiły modele w tych obszarach. AI nauczyło się pisać kod odporny na ataki, których branża bała się najbardziej i o których mówiła najgłośniej.

Ale ta sama autoryzacja, która w małej aplikacji trzymała się dobrze, załamywała się wraz z jej wzrostem. W dużej, przeniesionej aplikacji odsetek błędów IDOR skoczył z 11 do 28 procent. Xint ujmuje to jednym zdaniem: precyzyjna kontrola uprawnień wytrzymuje w małych aplikacjach i pęka, gdy aplikacja rośnie. I to jest dokładnie ten punkt, w którym badanie przestaje być listą luk, a staje się obserwacją o naturze AI.

Zastanówmy się, dlaczego akurat te dwie kategorie zachowują się tak różnie. Iniekcja SQL jest błędem lokalnym — istnieje albo nie w jednym miejscu, w jednej linijce, która buduje zapytanie z niesprawdzonych danych. Żeby ją naprawić, wystarczy spojrzeć na tę linijkę. Model, wytrenowany na milionach przykładów bezpiecznego budowania zapytań, nauczył się tego wzorca i stosuje go odruchowo. To jest ten sam rodzaj kompetencji, którą AI pokazuje, znajdując błąd w Squidzie: wzorzec zapisany wprost, rozpoznawalny na miejscu.

Autoryzacja w dużej aplikacji jest błędem globalnym. Pytanie „czy ten użytkownik ma prawo sięgnąć po ten obiekt" nie ma odpowiedzi w żadnej pojedynczej linijce. Odpowiedź zależy od tego, kim jest użytkownik, jak zdefiniowano role w innej części systemu, jak powiązano zasoby w trzeciej, co ustalono w regułach biznesowych w czwartej. Żeby to poprawnie napisać, trzeba trzymać w głowie całą aplikację naraz i rozumować o relacjach między jej częściami. A to jest dokładnie to, czego model nie robi dobrze — tak samo jak nie „widzi" wyścigu w jądrze, bo ten istnieje nie w kodzie, lecz w relacji między dwoma wątkami w czasie.

To jest jedna granica, po obu stronach klawiatury. Gdy AI szuka luk, opanowuje błędy statyczne i mija te istniejące tylko w splocie zdarzeń. Gdy AI pisze kod, opanowuje wzorce lokalne i zawodzi tam, gdzie poprawność zależy od kontekstu całości. W obu przypadkach linia demarkacyjna biegnie w tym samym miejscu: między tym, co da się rozstrzygnąć, patrząc na jeden fragment, a tym, co wymaga rozumowania o systemie jako całości. To nie są dwie osobne słabości. To jedna, widziana raz od strony obrony, raz od strony tworzenia.

To potwierdza się poza tym jednym badaniem

Trzeba tu zachować ostrożność wobec źródła, bo Xint nie jest bezstronny: firma sprzedaje autonomiczny pentest oparty na AI, więc teza „kod generowany przez AI wymaga skanowania" jest po jej stronie interesu. Gdyby to było jedyne źródło, należałoby traktować je z rezerwą.

Ale nie jest. Niezależny projekt Vibe Security Radar prowadzony przez Georgia Tech, śledzący publicznie zgłaszane luki przypisane kodowi generowanemu przez AI, odnotował ten sam kształt problemu z innej strony: to właśnie błędy architektoniczne rosły najszybciej — ścieżki eskalacji uprawnień wzrosły o 322 procent, a wady projektowe architektury o 153 procent. To są dokładnie te podatności, które, cytując tamten projekt, wymagają głębokiego rozumowania kontekstowego, by je wykryć. Dwa niezależne pomiary, jedna konkluzja: AI radzi sobie coraz lepiej z lokalnym, a jego słabość przesuwa się ku temu, co architektoniczne i całościowe.

To spina się też z raportem Bitdefendera, o którym pisaliśmy — tam chodziło o to, że boimy się nie tych zagrożeń, które realnie tną. Tu jest analogicznie, tyle że o kodzie: baliśmy się iniekcji, a AI akurat je opanowało; mniej mówiliśmy o autoryzacji i odporności na przeciążenie, a to właśnie tam kod pisany przez AI jest najsłabszy. Uwaga podąża za tym, co głośne, a nie za tym, co realnie dziurawe.

Co z tego wynika dla obrońcy

Pierwszy wniosek jest praktyczny i wprost z zaleceń Xint. Nie sprawdzaj tylko, czy kod od AI się kompiluje — sprawdzaj, jak się zachowuje w działaniu i ile zużywa zasobów, bo najczęstsze luki to brak ograniczeń ruchu i ochrony przed przeciążeniem, których w samym kodzie źródłowym nie widać. Szukaj też zaszytych na stałe sekretów — kluczy API i danych osobowych wprost w kodzie — bo to najczęstsza luka o wadze krytycznej, a modele wciąż wstawiają je z nawyku wyniesionego z danych treningowych.

Drugi jest ważniejszy i wynika wprost z tekstury, którą opisaliśmy. Skoro autoryzacja pęka wraz ze wzrostem aplikacji, to przegląd uprawnień do obiektów musi być intensywniejszy tam, gdzie aplikacja jest większa i ma więcej punktów wejścia — nie mniej, jak podpowiadałaby intuicja „duży projekt, dojrzały, pewnie przemyślany". Jest odwrotnie: im więcej endpointów, tym większa szansa, że AI zgubiło gdzieś regułę „kto ma prawo do czego", bo nie utrzymało całości w głowie. Podwójnie sprawdzaj precyzyjne uprawnienia do obiektów, gdy liczba endpointów rośnie.

Trzeci jest najszerszy i domyka to, co prowadzimy od Bad Epoll. Skoro AI ma stałą, przewidywalną granicę — świetne lokalnie, słabe kontekstowo — to obrona nie polega na tym, żeby ufać mu równomiernie albo nie ufać w ogóle. Polega na tym, żeby wiedzieć, gdzie ta granica leży, i tam kierować ludzką uwagę. Pozwól AI pisać obronę przed iniekcją, bo robi to już lepiej niż niejeden człowiek. Ale logikę autoryzacji — pytanie, kto ma prawo do czego w skali całego systemu — trzymaj pod ludzkim okiem, bo to jest dokładnie ten rodzaj rozumowania o całości, w którym model jest najsłabszy. To nie jest argument przeciw pisaniu kodu z AI. To mapa, gdzie mu ufać, a gdzie sprawdzać.

Jedna myśl na koniec

Najciekawsze w tym badaniu jest to, że dobra wiadomość i zła są tą samą wiadomością. AI naprawdę się poprawiło — i to dokładnie tam, gdzie najgłośniej wieszczono katastrofę. Ale ta poprawba obnażyła, gdzie leży prawdziwa, trwalsza słabość: nie w pojedynczej niebezpiecznej linijce, którą łatwo rozpoznać i której model nauczył się unikać, lecz w cichym pytaniu, na które trzeba znać całą aplikację, żeby odpowiedzieć — czy ten użytkownik ma prawo do tych danych. Model potrafi napisać tysiąc linii, z których każda z osobna jest bezpieczna, i przeoczyć, że razem pozwalają jednemu użytkownikowi czytać dane drugiego. Bo bezpieczeństwo nie zawsze mieszka w linijce. Czasem mieszka w relacji między nimi — a to jest miejsce, którego model wciąż nie widzi, czy szuka luk, czy je tworzy.

Źródła

Xint (Theori) — oryginalne badanie luk w aplikacjach tworzonych przez AI, z metodologią trzech scenariuszy (greenfield ze specyfikacji, greenfield z niedbałego polecenia, brownfield migrowany i hartowany), rozkładem 434 luk oraz kluczową obserwacją o poprawie w iniekcjach i załamaniu autoryzacji wraz z rozmiarem aplikacji: https://go.xint.io/the-top-security-vulnerabilities-generated-by-ai-code

SecurityWeek — omówienie badania Xint z pełnym rozkładem kategorii luk, cytatami z raportu o skali aplikacji i wnioskiem o realnej poprawie modeli w obszarze iniekcji i kontroli dostępu: https://www.securityweek.com/vibe-coded-apps-riddled-with-exploitable-security-flaws/

Cloud Security Alliance / Georgia Tech Vibe Security Radar — niezależny projekt śledzący luki przypisane kodowi generowanemu przez AI, z danymi o wzroście błędów architektonicznych (eskalacja uprawnień +322%, wady projektowe +153%) jako podatności wymagających głębokiego rozumowania kontekstowego: https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/