Myślę, że wszyscy już o tym słyszeli, a większość z nas już nawet tego próbowała. Co więcej, po rozmowach z różnymi ludźmi wiele osób zaczęło tak po prostu pracować na co dzień i świetnie im to pomaga.

Co to jest?

Asystenci kodowania. Dziś połączymy to z Vibe Codingiem i przyjrzymy się bezpieczeństwu takiego podejścia do kodu.

Pisanie kodu wraz z asystentami AI staje się coraz to przyjemniejsze. Począwszy od generowania prostych elementów kodu na podstawie komentarzy, aż po generowanie całych funkcjonalności. Powoli zaczynamy przechodzić z myślenia o pisaniu kodu do myślenia bardziej całościowego o tworzeniu funkcji i systemów.

To bardzo pozytywna zmiana. Teraz trzeba bardziej skupiać się na myśleniu wysokopoziomowym i architektonicznym niż na żmudnym pisaniu kolejnych linijek klas i właściwości.

Dzisiaj z obecnymi narzędziami, mamy naprawdę ogromne możliwości. Zarówno możliwości wyboru spośród wielu różnych narzędzi takich jak GitHub Copilot, Cursor, Windsurf. Każde z nich ma też różne możliwości wspierania tworzenia systemów np. Background Agents w Cursor.

Jednak przede wszystkim Asystenci AI dają nam możliwość szybkich modyfikacji kodu, a także szybkiego tworzenia całych aplikacji. Nie zawsze jest to trafne, ale świetnie nadaje się do prototypowania różnego rodzaju aplikacji, które potem można dalej rozwijać Samemu lub z pomocą asystentów AI.

Tak wygląda podstawowy model architektury korzystania z Asystentów AI.

Mamy:

• codebase — kod naszej aplikacji
• reguły asystenta — plik wspólnych reguł wykorzystywanych podczas każdego generowania
• prompt — zapytania do modelu
• serwery MCP i zewnętrzne zasoby — które mogą przetwarzać dane lub wykonać akcje poza modele AI

Czy to oznacza, że od teraz każdy może stworzyć aplikację?

Tak

Ale czy każdy może stworzyć dowolną aplikację?

Już nie do końca.

A czy takie aplikacje są gotowe do używania ich przez użytkowników?

Zdecydowanie nie.

Zagrożenia Asystentów AI

Generowanie błędnego kodu

Dużą wadą Asystentów AI jest ich dosłowność. Gdy nie doprecyzowujemy w instrukcji dokładnie tego, co ma zostać napisane, model może wymyślić coś własnego. Coś, co nie do końca będzie nam pasowało. Na przykład zrobi błąd w stylu CSS, który będzie powodował dziwny wygląd strony. Nie brzmi to szczególnie niebezpiecznie. Prędzej czy później to wykryjemy.

Jednak może się okazać, że Asystent AI wygeneruje również błąd w logice aplikacji. To też można wykryć podczas testów.

A co jeżeli wygeneruje on błąd w logice logowania do systemu albo użyje niebezpiecznych algorytmów w kodzie. W końcu uczył się na kodach z GitHuba, nie zawsze najlepszej jakości i najnowszych.

---

W poniższym badaniu (z lutego 2025) różnych modeli widać jaki procent kodu wygenerowanego przez dany model był bezpieczny, a jaki zawierał niebezpieczne wstawki.

Ważna adnotacja

The models are only prompted to complete the coding task. The prompt contains no security-specific instructions, reflecting a realistic interaction with a developer that does not make explicit security considerations.

Sam model AI może wygenerować też zupełnie przypadkowo bardzo problematyczny kod. Dobrym przykładem jest generowanie przez LLMy nieistniejących bibliotek. Jest to tak zwany slopsquatting

Gdy AI wygeneruje referencję do biblioteki, która nie istnieje, to atakujący może ją stworzyć, duplikując oryginalna i tak przejąc dostęp do kodu aplikacji, wykonując w nim, co tylko chce.

Generowanie złośliwego kodu

Nagłówek brzmi podobnie, jednak jest to dość znacząca różnica. W poprzednim przypadku to model AI popełniał błąd, w drugim to ktoś go do niego zmusza. Nadal oba typy błędów mogą być równie poważne, jednak w tym przypadku chodzi o celowy atak na system.

Jak to się może odbywać?

Na przykład za pomocą złośliwych instrukcji zaszytych w plikach MDC (wspólnej konfiguracji dla asystentów AI).

Bardziej wyrafinowanym sposobem jest wstrzyknięcie Prompt Injection do modelu poprzez serwery MCP. Przez to w dość niezauważony sposób ktoś może wpłynąć na sposób generowania kodu.

Wyciek danych

Kolejnym poważnym zagrożeniem jest to, że pracując z kodem i wysyłając go do modelu AI, jest możliwość wycieku naszego kodu źródłowego. Samo to może być dla nas problematyczne, ale może się to okazać dużo bardziej niebezpieczne, jeżeli w naszym kodzie znajdują się dane wrażliwe lub sekrety używane w systemie. Wtedy problem robi się dużo poważniejszy. Takie wycieki mogą odbywać się bezpośrednio poprzez model AI lub przez różne serwery MCP.

Jak sobie z tym poradzić?

Bezpieczny kod w repozytorium

Podstawą bezpiecznego generowania kodu jest odpowiednie formułowanie promptów. Jednak powiedzmy sobie szczerze. Developerzy nie zawsze o tym pamiętają i trudno jest dodawać takie adnotacje do każdego nawet drobnego prompta. Dlatego też powstały uwspólnione pliki konfiguracji promptów MDC. Pozwalają one stworzyć element prompta, który jest używany w każdym zapytaniu. Możemy tam umieścić instrukcje zapewnienia odpowiedniego poziomu bezpieczeństwa. Bo tak jak mówiliśmy — AI jest dosłowny — jak mu o czymś nie powiemy, to tego nie zrobi. Jak inspirację polecam przykłady plików MDC w różnych projektach.

Kolejną metodą na zapewnienie, że wygenerowany kod jest bezpieczny jest szczelna polityka Pull Requestów. Musimy się upewnić, że nie da się zmergować kodu do brancha, z którego aplikacja jest budowana na produkcję bez odpowiedniego zweryfikowania przez człowieka.

W ogólności kod wygenerowany przez Asystenta AI powinien spełniać co najmniej tak rygorystyczne zasady bezpieczeństwa co kod stworzony przez człowieka. Oba źródła mogą popełniać błędy.

Bezpieczeństwo kodu

W przypadku zapewnienie bezpieczeństwa naszego kodu jako istotnych dla nasz danych warto zacząć od podstaw. Korzystajmy tylko z zaufanych Asystentów AI, przez zaufane pluginy, tak, żeby zminimalizować szanse wycieku.

Niektórzy dostawcy modeli w chmurze umożliwiają również zadeklarowanie żądania nieużywania naszych danych do trenowania modeli. Warto o tym pamiętać, bo już nie raz zdarzały się sytuacje, gdy w ogólnym modelu można było dostać się do danych pochodzących ze zbiór treningowego (patrz przypadek Samsunga).

Mam nadzieję, że to krótkie podsumowanie zagrożeń i sposobów ochrony przed nimi pomoże Ci tworzyć bezpieczny kod w najbardziej efektywny sposób.

Bo szkoda tracić czas na pisanie setny raz tego samego, można to zrobić szybciej, ale nie za cenę bezpieczeństwa.

Źródła:

https://threats.backslash.security/

https://cloudsecurityalliance.org/blog/2025/04/09/secure-vibe-coding-guide#