AI napisało Ci aplikację w weekend. Nikt nie sprawdził, czy zostawiło otwarte drzwi od zaplecza

Fachowiec przyjeżdża rano i obiecuje, że nowe drzwi wejściowe będą gotowe przed obiadem. Są gotowe. Zamek błyszczy, framuga równa, klamka nie chrzęści.

Nikt nie sprawdza, czy ten zamek faktycznie się domyka, dopóki ktoś nie wejdzie do środka bez klucza, o trzeciej w nocy, z łomem.

Z kodem napisanym przez AI jest podobnie. Wygląda gotowo, kompiluje się, działa na pierwszy klik. Luki bezpieczeństwa w kodzie AI pojawiają się jednak w prawie połowie napisanych fragmentów, według najnowszego raportu Veracode z 2026 roku, a większość z nich wychodzi na jaw dopiero wtedy, gdy ktoś jest już w środku.

AI nigdy nie powie, że nie jest pewne, czy formularz logowania jest bezpieczny. Powie, że działa, i przejdzie do kolejnego zadania z entuzjazmem, jakiego nie miał żaden stażysta w historii informatyki.

Ten tekst to lista rzeczy do sprawdzenia, zanim kod trafi na produkcję. Nie po tym, jak ktoś się już włamie.

Dlaczego kod AI wygląda dobrze i bywa dziurawy jak sito

Daniil Komov / Pexels

Najnowszy 2026 GenAI Code Security Report firmy Veracode przetestował ponad 100 modeli AI na identycznych zadaniach programistycznych. Wynik: 44 procent wygenerowanych fragmentów kodu wprowadza poważną lukę bezpieczeństwa. Średni wskaźnik zdanych testów bezpieczeństwa wynosi 56 procent i od poprzedniego raportu prawie się nie zmienił.

To trochę jak zdawać egzamin na prawo jazdy z wynikiem 56 procent punktów i dostać prawo jazdy, bo akurat tyle wystarczyło w tym roczniku.

Najlepszy model w zestawieniu, GPT-5.5, zdaje 68 procent testów bezpieczeństwa. Brzmi nieźle, dopóki nie policzysz, że to wciąż oznacza porażkę w prawie co trzecim zadaniu.

Ciekawiej robi się przy konkretnych typach błędów. AI radzi sobie świetnie z kryptografią, 87 procent zdanych testów, i z SQL injection, 83 procent. Przy cross-site scripting wynik spada do 15 procent. Przy log injection do 12 procent.

To tak, jakby szef kuchni perfekcyjnie panierował kotlet, ale zapomniał, że najpierw trzeba włączyć piekarnik.

Model potrafi poprawnie zaszyfrować hasło, poprawnie napisać zapytanie do bazy danych i dodać ładny loading spinner. Zapomina tylko sprawdzić, czy to naprawdę Ty klikasz przycisk, czy ktoś, kto się pod Ciebie podszywa.

2038 dziur w 1400 aplikacjach zbudowanych na AI

John (Giannis) Tekeridis / Pexels

Cloud Security Alliance razem z firmą Escape.tech przeskanowały 1400 aplikacji zbudowanych w narzędziach do vibe codingu: Lovable, Base44, Bolt.new i Vibe Studio. Znalazły 2038 krytycznych luk bezpieczeństwa i ponad 400 wyciekniętych sekretów, czyli haseł, kluczy API i tokenów zostawionych wprost w kodzie.

To trochę jak zostawić zapasowy klucz pod wycieraczką, tylko że wycieraczka jest publicznym repozytorium na GitHubie, a klucz pasuje do bazy danych klientów.

W 175 przypadkach ujawnione dane obejmowały numery kart płatniczych, dokumentację medyczną i dane logowania. Nikt tego nie planował. Aplikacja po prostu działała, więc uznano sprawę za zamkniętą.

AI rzeczywiście zmienia to, kto może zbudować działającą aplikację bez bycia programistą, pisałem o tym szerzej przy okazji programowania z AI. Nie zmienia jednak tego, kto odpowiada, gdy w tej aplikacji wycieknie baza klientów. Odpowiada właściciel firmy, nie model językowy.

Model językowy nie dostanie wezwania od UODO.

Nawet narzędzia AI mają teraz własne CVE

Naukowcy z Georgia Tech prześledzili historię 43 849 zgłoszeń bezpieczeństwa między majem 2025 a marcem 2026, cofając się aż do commita, który wprowadził błąd. Potwierdzili 74 luki (CVE) jednoznacznie stworzone przez narzędzia AI do pisania kodu. Sami szacują, że prawdziwa liczba jest 5 do 10 razy wyższa, bo większość takich przypadków nigdy nie trafia do oficjalnych rejestrów.

Ranking na 20 marca 2026 roku wyglądał tak: Claude Code, 49 luk, w tym 11 krytycznych. GitHub Copilot, 15 luk. Google Jules, Aether, Devin i Cursor, po kilka każdy.

Ta strona, którą właśnie czytasz, powstała między innymi z pomocą Claude Code. Miło to przyznać, wiedząc, że akurat to narzędzie prowadzi w rankingu, którego nikt nie chce prowadzić.

Tempo rośnie z miesiąca na miesiąc. Styczeń 2026: 6 luk. Luty: 15. Marzec: 35. Nie trzeba umieć czytać wykresów, żeby zauważyć kierunek.

Narzędzie, które miało pisać kod szybciej niż człowiek, pisze też błędy szybciej, niż człowiek zdąży je znaleźć.

Jak sprawdzić kod AI, zanim trafi na produkcję

Dan Nelson / Pexels

Dobra wiadomość: nic z tego nie wymaga zatrudniania działu bezpieczeństwa złożonego z dwudziestu osób. Wymaga pięciu nawyków, które da się wdrożyć w tydzień (tak, wiem, brzmi to jak dodatkowa praca, bo nią jest).

Pierwszy: włącz automatyczne skanowanie kodu na każdym pull requeście, nie tylko przed wielkim wdrożeniem. Luka znaleziona w piątek po publikacji kosztuje więcej niż ta sama luka znaleziona we wtorek przed commitem.

Drugi: sprawdzaj w pierwszej kolejności dokładnie te kategorie, w których AI wypada najgorzej, czyli cross-site scripting i log injection. Tam model zawodzi w 85 do 88 procentach przypadków, nie w kilku.

Trzeci: każde miejsce, które przyjmuje dane od użytkownika, formularz, adres URL, nagłówek, plik, sprawdzaj ręcznie. AI świetnie pisze logikę biznesową. Traktowanie danych z zewnątrz jako czegoś potencjalnie wrogiego to wciąż ludzka kompetencja.

Czwarty: nigdy nie wdrażaj wprost z platformy do vibe codingu na produkcję bez niezależnego przeglądu. Platforma, która buduje Ci aplikację w 20 minut, nie ma powodu, żeby przy okazji budować Ci firewall.

Piąty: traktuj kod od AI jak pierwszy pull request nowego stażysty. Zakładasz kompetencję. Sprawdzasz mimo to. Stażysta się nie obrazi, model też nie, bo żadne z nich tego nie przeczyta.

Konkretną listę rzeczy do sprawdzenia znajdziesz w OWASP Top 10, czyli w branżowym rankingu najczęstszych błędów bezpieczeństwa aplikacji webowych, aktualizowanym od lat przez całą społeczność, a nie przez jeden model, który akurat miał dobry dzień.

Luka niewidoczna na pierwszy rzut oka potrafi czekać w kodzie miesiącami, cicho, jak alarm w mieszkaniu, o którego istnieniu dawno zapomniałeś.

Kto odpowiada, gdy AI zostawi otwarte drzwi

Odpowiedzialność prawna nie przenosi się na dostawcę modelu, nawet jeśli to jego kod zawierał lukę. Pisałem już o tym szerzej przy okazji tekstu o tym, kto odpowiada, gdy automatyzacja AI się pomyli: to firma korzystająca z narzędzia bierze na siebie skutki, łącznie z ewentualną karą od UODO za wyciek danych osobowych.

Model nie stawi się na rozprawie. Nie ma nawet adresu do doręczeń.

To nie jest argument przeciwko używaniu AI do pisania kodu. To argument za tym, żeby ostatnie spojrzenie na kod zawsze należało do człowieka, który wie, co się stanie, jeśli coś pójdzie nie tak. AI tego nie wie. AI nawet nie wie, że coś poszło nie tak, dopóki nie napiszesz mu o tym w kolejnym promptcie.

Fachowiec od drzwi zostawia Ci gwarancję i numer telefonu, gdyby zamek się zaciął. Model językowy zostawia Ci kod i historię czatu, którą i tak zaraz wyczyścisz.