Vibe coding: kiedy ufność w kod od AI staje się luką bezpieczeństwa
Kod pisany bez czytania
Termin „vibe coding” spopularyzował na początku 2025 roku Andrej Karpathy, jeden ze znanych badaczy sztucznej inteligencji, opisując sposób pracy, w którym programista opisuje modelowi AI, co ma zrobić, a następnie akceptuje wygenerowany kod — bez dokładnego studiowania tego, co model faktycznie napisał. Różnica wobec klasycznego wspomagania się asystentem AI polega na stopniu kontroli: w tradycyjnym podejściu człowiek traktuje podpowiedź jako materiał do weryfikacji, w vibe codingu — jako gotowy produkt.
To podejście ma niezaprzeczalną zaletę: obniża próg wejścia. Prototyp, narzędzie wewnętrzne czy prosta strona internetowa powstają w godziny zamiast w tygodnie. Problem pojawia się wtedy, gdy kod opuszcza środowisko prototypu i zaczyna obsługiwać prawdziwych użytkowników, prawdziwe dane i prawdziwe pieniądze.
Dziury, których nikt nie sprawdził
Do typowych problemów należy przechowywanie danych uwierzytelniających bezpośrednio w kodzie klienta — kluczy do usług, haseł, tokenów, które każdy może odczytać w przeglądarce. Kolejna grupa to braki kontroli dostępu w interfejsach API: procedury zapisu i odczytu danych, które nie sprawdzają, kim jest osoba wykonująca żądanie. Osobną kategorią są mechanizmy uwierzytelniania, które można obejść po zmianie jednego parametru — na przykład flagi informującej serwer, że użytkownik już się zalogował.
Te luki mają wspólną cechę: nie psują działania aplikacji. Strona działa, formularze przyjmują dane, testy przechodzą. Usterka ujawnia się dopiero wtedy, gdy ktoś celowo zacznie szukać dziury — albo gdy wyciek danych stanie się faktem.
Ostatni z tych punktów zasługuje na osobną uwagę. Wiele modeli, generując kod, korzysta z nazw bibliotek napotkanych podczas treningu — również tych fikcyjnych, powstałych w artykułach naukowych jako przykład. Osoby atakujące zaczęły publikować pakiety o takich właśnie nazwach w publicznych rejestrach, licząc, że ktoś wklei podpowiedź modelu bez sprawdzenia, czy dana biblioteka w ogóle istnieje. Zjawisko to zostało opisane jako „slopsquatting” — przejęcie nazwy pakietu wygenerowanej przez AI.
Model jako narzędzie, nie orzecznik jakości
Warto podkreślić: modele AI same w sobie nie są wrogiem. Bezpieczeństwo zależy od procesu, nie od narzędzia. Podejście odpowiedzialne wygląda tak: kod generowany przez model traktujemy jako wersję roboczą, przed wdrożeniem przechodzi przegląd bezpieczeństwa, sekrety nigdy nie trafiają do kodu klienta, a każda zależność jest sprawdzana w rejestrze przed instalacją.
Pomocne są także proste nawyki higieny projektu: oddzielenie kluczy i konfiguracji od kodu w plikach, które nie trafiają do repozytorium, włączenie automatycznych skanerów podatności do potoku wdrażania oraz ograniczenie uprawnień usług, z których korzysta aplikacja. Żadne z tych działań nie wymaga zespołu specjalistów — a właśnie ich brak jest najczęstszą przyczyną, dla której kod z lukami opuszcza środowisko prototypu.
Zespół, który nie czyta wygenerowanego kodu, nie powinien wdrażać go do produkcji — to zdanie powtarzają wytyczne firm zajmujących się bezpieczeństwem aplikacji. Dla osób budujących projekty samodzielnie, bez zespołu, ryzyko rośnie: nie ma drugiej pary oczu, która wyłapie przeoczenie. Automatyczne narzędzia skanujące kod — choć niedoskonałe — są w takiej sytuacji jedynym filtrem przed wdrożeniem.
Oznaczenie treści AI
Ten artykuł powstał z udziałem sztucznej inteligencji: research oraz tekst przygotował i zredagował agent AI. Dane, daty i cytaty przytoczone w tekście pochodzą ze zweryfikowanych źródeł.
