Generatywna AI w kodzie: 3 ukryte zagrożenia dla bezpieczeństwa aplikacji

Kiedy w zeszłym roku zespół JurskiTech przeprowadzał audyt bezpieczeństwa dla średniej wielkości platformy e-commerce, znaleźliśmy coś niepokojącego. Fragment kodu odpowiedzialny za walidację tokenów JWT wyglądał idealnie – był czysty, elegancki i… całkowicie podatny na atak typu timing attack. Deweloper przyznał, że wygenerował go ChatGPT. Nie pierwszy raz. I to jest właśnie moment, w którym generatywna AI przestaje być błogosławieństwem, a staje się cichym zagrożeniem.

Oczywiście, copiloci i asystenci AI to potężne narzędzia. Przyspieszają pisanie kodu, pomagają w boilerplate’ach, a nawet sugerują optymalizacje. Ale mają też ciemną stronę – szczególnie gdy chodzi o bezpieczeństwo. W tym artykule przyjrzę się trzem konkretnym zagrożeniom, które widzę w projektach naszych klientów. To nie jest kolejny straszak na AI – to realne przypadki z życia wzięte.

1. Podatności wstrzykiwane przez trening: gdy model powiela błędy z przeszłości

Modele językowe, takie jak GPT-4 czy CodeLlama, są trenowane na ogromnych zbiorach kodu źródłowego pochodzącego z publicznych repozytoriów. Problem polega na tym, że wiele z tych repozytoriów zawiera błędy bezpieczeństwa. Badania pokazują, że nawet 25% kodu wygenerowanego przez AI może zawierać podatności. To nie są wyimaginowane scenariusze.

Kilka miesięcy temu zespół JurskiTech pracował nad aplikacją SaaS dla startupu z branży fintech. Deweloper użył GitHub Copilot do napisania funkcji parsującej pliki CSV. Model zaproponował kod, który był zwięzły i działał, ale zawierał klasyczną podatność na wstrzykiwanie poleceń – nie dezynfekował danych wejściowych przed użyciem w wywołaniu systemowym. A to akurat w aplikacji finansowej… powiedzmy, że audytor nie był zachwycony.

Dlaczego to się dzieje? Bo model uczy się na kodzie, który widział w sieci. A w sieci jest pełno niepoprawnych wzorców, szybkich fixów, które pomijają walidację, i przykładów z tutoriali pisanych bez myślenia o bezpieczeństwie. Kiedy deweloper akceptuje sugestie AI bez krytycznej analizy, te błędy trafiają do produkcyjnego kodu.

Jak się bronić? Przede wszystkim – nigdy nie ufaj wygenerowanemu kodowi bez weryfikacji. Traktuj go jak pierwszą wersję roboczą, która wymaga przeglądu kodu i testów bezpieczeństwa. W JurskiTech zawsze zalecamy stosowanie narzędzi do statycznej analizy kodu (SAST) w pipeline CI/CD – one łapią wiele typowych podatności, zanim kod trafi na produkcję.

2. Nieświadome ujawnianie sekretów przez prompt injection

To zagrożenie jest mniej oczywiste, ale równie niebezpieczne. Deweloperzy często wklejają fragmenty kodu do asystenta AI, aby poprosić o optymalizację lub debugowanie. Problem pojawia się, gdy w kodzie znajdują się zakomentowane hasła, klucze API, tokeny dostępowe czy konfiguracje. Ale to nie wszystko – model może również wyciągnąć takie dane z kontekstu, nawet jeśli nie są wprost wklejone.

Słyszeliście o atakach typu prompt injection? W kontekście bezpieczeństwa kodu, może to wyglądać tak: deweloper prosi ChatGPT o wyjaśnienie dziwnego zachowania funkcji, a model odpowiada, sugerując, że problem może leżeć w nieprawidłowym kluczu API – który przypadkowo wyciekł z treningu albo z poprzedniej odpowiedzi. To rzadkie, ale zdarza się.

Bardziej realny scenariusz to sytuacja, gdy model jest używany w środowisku korporacyjnym z włączoną historią czatów. Jeśli deweloper zapomni wyczyścić sesji, poufne dane mogą zostać przechowane na serwerach zewnętrznego dostawcy. W przypadku OpenAI czy Microsoftu, dane są podobno chronione, ale ryzyko naruszenia polityki bezpieczeństwa firmy jest realne.

Jak się bronić? Ustal zasady korzystania z narzędzi AI w zespole. Zakaz wklejania wrażliwych danych – to oczywiste. Ale idź krok dalej: używaj lokalnych modeli, takich jak CodeLlama, które działają w Twojej infrastrukturze. W JurskiTech wdrożyliśmy u klientów rozwiązania oparte na self-hostowanych modelach, dzięki czemu deweloperzy mogą korzystać z pomocy AI bez ryzyka wycieku danych.

3. Fałszywe poczucie bezpieczeństwa: gdy AI tworzy pozór, a nie faktyczną ochronę

To zagrożenie jest najbardziej podstępne. Generatywna AI potrafi napisać kod, który wygląda bezpiecznie – ma komentarze, jest czysty, używa popularnych bibliotek. Ale często implementuje zabezpieczenia w sposób powierzchowny. Na przykład: deweloper prosi o funkcję uwierzytelniania z hashowaniem haseł. AI generuje kod, który używa bcrypt – dobrze. Ale zapomina o dodaniu salt? Albo używa stałego kosztu, który jest zbyt niski? Albo nie zabezpiecza przed brute force?

Kiedyś audytowałem aplikację, w której znalazłem taki kod: funkcja logowania wygenerowana przez AI sprawdzała hasło za pomocą password_verify (PHP) – poprawnie. Ale nie miała żadnego limitu prób ani opóźnienia. Atakujący mógłby próbować haseł w nieskończoność. AI po prostu nie dodało tych mechanizmów, bo nie zostały wyraźnie zażądane. A deweloper założył, że skoro kod działa i używa bcrypt, to jest bezpiecznie. To fałszywe poczucie bezpieczeństwa.

Inny przykład: generowanie kodu do walidacji danych wejściowych. AI często tworzy reguły walidacji, ale skupia się na formacie, a nie na kontekście biznesowym. Na przykład walidacja adresu email może przepuścić adres [email protected] zamiast wymagać domeny firmowej. Albo przepuścić SQL injection, jeśli walidacja nie obejmuje escape’owania znaków specjalnych.

Jak się bronić? Zawsze pisz testy bezpieczeństwa, które sprawdzają konkretne scenariusze ataków. Nie polegaj na tym, że AI zrobi wszystko za Ciebie. W JurskiTech stosujemy zasadę „bezpieczeństwo przez projektowanie” – każda funkcja musi mieć zdefiniowane wymagania bezpieczeństwa, zanim powstanie kod. AI jest asystentem, a nie architektem bezpieczeństwa.

Podsumowanie: AI w kodzie to narzędzie, nie guru

Generatywna AI zmienia sposób, w jaki piszemy kod. To fakt. Przyspiesza rozwój, redukuje boilerplate, pomaga w nauce nowych technologii. Ale nie jest magicznym rozwiązaniem, które zapewni bezpieczeństwo. W JurskiTech widzimy, że firmy, które bezkrytycznie akceptują kod z AI, często płacą później za audyty, incydenty i problemy z compliance.

Trzy zagrożenia, które opisałem – podatności z treningu, wyciek danych przez prompt injection i fałszywe poczucie bezpieczeństwa – to nie teoretyczne rozważania. To rzeczywiste problemy, które spotykamy na co dzień. Dlatego w naszej agencji zawsze łączymy korzystanie z AI z solidnym procesem przeglądu kodu, testami bezpieczeństwa i politykami ochrony danych.

Jeśli budujesz aplikację webową, SaaS, sklep e-commerce czy narzędzie AI i chcesz mieć pewność, że Twój kod jest bezpieczny – nie zostawiaj tego wyłącznie asystentowi. Zaplanuj audyt, wdróż SAST, edukuj zespół. AI to fantastyczne narzędzie, ale to Ty jesteś odpowiedzialny za bezpieczeństwo.

Potrzebujesz wsparcia w zakresie bezpieczeństwa aplikacji lub audytu kodu? Skontaktuj się z JurskiTech – pomożemy Ci zabezpieczyć Twój cyfrowy biznes.