Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Rosnąca popularność narzędzi do generowania kodu z użyciem sztucznej inteligencji istotnie zmienia sposób tworzenia oprogramowania. Asystenci programistyczni i modele językowe pomagają zespołom szybciej dostarczać nowe funkcje, lecz jednocześnie zwiększają ryzyko przenikania błędów bezpieczeństwa do środowisk produkcyjnych. Problem nie ogranicza się do pojedynczych fragmentów kodu, ale obejmuje cały łańcuch wytwarzania aplikacji — od projektowania logiki biznesowej, przez integracje API, po testy i procesy DevSecOps.
Najważniejsze wyzwanie polega na tym, że kod wygenerowany przez AI często sprawia wrażenie poprawnego, czytelnego i gotowego do wdrożenia. Funkcjonalność nie jest jednak równoznaczna z bezpieczeństwem, a pozornie niewielkie błędy mogą prowadzić do poważnych incydentów.
W skrócie
Organizacje coraz częściej wykorzystują kod generowany przez AI na dużą skalę, a część z nich nadal wdraża oprogramowanie zawierające znane podatności. Równolegle analizy bezpieczeństwa wskazują, że popularne modele LLM potrafią domyślnie tworzyć kod obarczony typowymi błędami, takimi jak command injection, path traversal, XSS czy niebezpieczna obsługa uploadu plików.
- AI przyspiesza development, ale nie gwarantuje bezpiecznej implementacji.
- Wiele podatności pojawia się w obszarach związanych z walidacją danych, operacjami na plikach i wywołaniami systemowymi.
- Bez dojrzałych kontroli AppSec wzrost produktywności może oznaczać również wzrost powierzchni ataku.
Kontekst / historia
Upowszechnienie generatorów kodu sprawiło, że narzędzia oparte na LLM są używane nie tylko do tworzenia boilerplate’u, lecz także do implementacji kluczowej logiki aplikacyjnej, integracji z bazami danych, obsługi danych wejściowych i budowy interfejsów API. To właśnie w tych obszarach najczęściej pojawiają się podatności o wysokim znaczeniu biznesowym.
Według analiz branżowych wykorzystanie AI w procesie developmentu stało się praktyką masową. Problem polega jednak na tym, że dojrzałość mechanizmów kontroli bezpieczeństwa nie rośnie równie szybko jak skala użycia takich narzędzi. W efekcie presja na szybkie dostarczanie funkcji bywa silniejsza niż potrzeba pełnej weryfikacji bezpieczeństwa przed wdrożeniem.
Analiza techniczna
Z technicznego punktu widzenia podstawowy problem wynika z charakteru modeli generatywnych. Systemy te optymalizują odpowiedź głównie pod kątem zgodności z promptem, poprawności składniowej i użyteczności dla programisty. Bezpieczeństwo kodu nie jest domyślnie najważniejszym kryterium, dlatego wygenerowane rozwiązanie może działać poprawnie, a jednocześnie zawierać podatność możliwą do wykorzystania.
Najczęściej obserwowane problemy obejmują niewystarczającą walidację danych wejściowych, użycie niebezpiecznych wywołań systemowych, niekontrolowaną obsługę ścieżek plików, podatności XSS oraz błędy w mechanizmach przesyłania plików. Do tego dochodzą nadmierne uprawnienia, słabe konfiguracje bezpieczeństwa oraz sugestie wykorzystania niezweryfikowanych bibliotek lub wzorców integracyjnych.
- brak właściwej walidacji i sanityzacji danych wejściowych,
- command injection wynikający z niebezpiecznych wywołań systemowych,
- path traversal związany z obsługą plików i ścieżek,
- podatności XSS po stronie frontendowej i backendowej,
- niebezpieczny upload plików,
- błędne konfiguracje i nadmierne uprawnienia.
Dodatkowym zagrożeniem jest erozja własności kodu. Im większy udział AI w implementacji, tym większe ryzyko, że zespół nie rozumie w pełni, dlaczego określone rozwiązanie zostało zaproponowane i jakie ma ograniczenia. Utrudnia to code review, modelowanie zagrożeń i skuteczną remediację. W środowiskach mikroserwisowych oraz w rozbudowanych pipeline’ach CI/CD pojedyncza wada może łatwo propagować się na kolejne komponenty.
Konsekwencje / ryzyko
Wdrożenie podatnego kodu do produkcji może prowadzić do przejęcia kont, wycieku danych, nadużyć w API, zdalnego wykonania poleceń oraz naruszeń zgodności regulacyjnej. W organizacjach o wysokim tempie developmentu problem jest szczególnie dotkliwy, ponieważ błędy są wprowadzane szybciej, niż zespoły bezpieczeństwa są w stanie je wykrywać i usuwać.
Istotnym skutkiem ubocznym jest również narastający dług techniczny i bezpieczeństwa. Jeżeli AI przyspiesza tworzenie aplikacji, ale jednocześnie zwiększa liczbę błędów wymagających późniejszej korekty, organizacja jedynie przesuwa koszt bezpieczeństwa na kolejny etap cyklu życia oprogramowania. To zwykle oznacza wyższe koszty testów, dłuższy czas remediacji i większe obciążenie zespołów operacyjnych.
- ryzyko aplikacyjne związane z klasycznymi podatnościami w kodzie,
- ryzyko procesowe wynikające z braku polityk użycia AI,
- ryzyko operacyjne związane z ograniczoną widocznością wkładu AI w kod,
- ryzyko supply chain wynikające z sugestii dotyczących bibliotek i integracji.
Rekomendacje
Organizacje korzystające z AI w procesie wytwarzania oprogramowania powinny traktować taki kod jak niezweryfikowany komponent zewnętrzny. Oznacza to konieczność obowiązkowego przeglądu bezpieczeństwa, zarówno manualnego, jak i zautomatyzowanego. W praktyce niezbędne są testy SAST, DAST, SCA, skanowanie IaC oraz wykrywanie sekretów.
Równie ważne jest wdrożenie formalnej polityki użycia narzędzi AI w SDLC. Taka polityka powinna określać, kiedy można korzystać z asystentów AI, które klasy kodu wymagają dodatkowej weryfikacji, jakich danych nie wolno przekazywać do modeli oraz w jaki sposób oznaczać fragmenty wygenerowane automatycznie.
Zespoły powinny również rozwijać podejście secure-by-design i secure-by-default. Prompty mogą zawierać wymagania bezpieczeństwa, ale nie mogą zastępować niezależnej walidacji. Samo polecenie wygenerowania bezpiecznego kodu nie jest skuteczną kontrolą ochronną.
- wprowadzenie obowiązkowego code review dla kodu wygenerowanego przez AI,
- automatyzacja testów bezpieczeństwa w pipeline’ach CI/CD,
- mapowanie błędów do OWASP Top 10 i CWE,
- śledzenie pochodzenia fragmentów kodu wygenerowanych przez AI,
- regularne szkolenia programistów z bezpiecznego użycia narzędzi generatywnych.
Podsumowanie
Kod generowany przez AI staje się integralną częścią nowoczesnego developmentu, ale jego wykorzystanie bez dojrzałych mechanizmów AppSec zwiększa powierzchnię ataku. Najważniejszy wniosek jest prosty: AI może przyspieszyć tworzenie aplikacji, lecz nie gwarantuje bezpieczeństwa implementacji.
Firmy, które łączą automatyzację programowania z rygorystycznym testowaniem, jasnym governance i pełną obserwowalnością procesu wytwórczego, mają większą szansę ograniczyć ryzyko. W przeciwnym razie wzrost produktywności może zostać zniwelowany przez coraz większą liczbę podatności trafiających do środowisk produkcyjnych.
Źródła
- https://www.infosecurity-magazine.com/news/majority-of-orgs-ship-vulnerable/
- https://checkmarx.com/press-releases/checkmarx-launches-enhanced-mobile-application-security-allowing-developers-deliver-secure-mobile-apps/
- https://www.infosecurity-magazine.com/news/llms-vulnerable-code-default/
- https://www.backslash.security/press-releases/popular-llms-found-to-produce-vulnerable-code-by-default
- https://www.veracode.com/blog/securing-ai-driven-development/