Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
„Vibe coding” to nieformalne określenie sposobu tworzenia oprogramowania, w którym użytkownik opisuje wymagania w języku naturalnym, a narzędzie oparte na sztucznej inteligencji generuje znaczną część kodu, logiki biznesowej, testów lub konfiguracji. Z punktu widzenia cyberbezpieczeństwa nie chodzi o samo wykorzystanie AI, lecz o ryzyko ograniczenia realnego nadzoru inżynierskiego nad tym, co trafia do środowisk deweloperskich i produkcyjnych.
Brytyjskie NCSC zwraca uwagę, że szybsze dostarczanie aplikacji nie może odbywać się kosztem jakości, rozliczalności i bezpieczeństwa całego cyklu życia oprogramowania. Innymi słowy, AI może wspierać programistów, ale nie zwalnia organizacji z obowiązku stosowania zasad secure-by-design i bezpiecznego SSDLC.
W skrócie
NCSC zaapelowało o ostrożność wobec „vibe coding”, wskazując, że generowanie aplikacji przez modele AI bez odpowiednich zabezpieczeń może prowadzić do wzrostu liczby podatności, błędów projektowych i problemów w łańcuchu dostaw oprogramowania.
Przekaz nie oznacza odrzucenia narzędzi AI w programowaniu. Wręcz przeciwnie, chodzi o to, by ich użycie było osadzone w dojrzałych praktykach inżynierskich: obowiązkowym przeglądzie kodu, testach bezpieczeństwa, walidacji zależności, kontroli pipeline’ów CI/CD oraz jasnym przypisaniu odpowiedzialności za decyzje techniczne.
Kontekst / historia
Rosnąca popularność asystentów kodowania i agentów programistycznych sprawiła, że tworzenie aplikacji stało się łatwiejsze i bardziej dostępne. Obniżenie bariery wejścia oznacza jednak również, że osoby o mniejszym doświadczeniu technicznym mogą budować rozwiązania, które działają funkcjonalnie, ale nie spełniają podstawowych wymagań bezpieczeństwa.
Zjawisko to wpisuje się w szerszy trend automatyzacji developmentu, w którym największym wyzwaniem przestaje być samo napisanie kodu, a staje się nim zapewnienie odporności systemu na nadużycia, błędy konfiguracyjne i ataki na łańcuch dostaw. NCSC od dłuższego czasu promuje praktyki związane z Software Security Code of Practice, podkreślając znaczenie minimalnych standardów bezpieczeństwa podczas projektowania, budowy, wdrażania i utrzymania oprogramowania. Ostrzeżenie przed „vibe coding” jest więc naturalnym rozwinięciem tej linii podejścia.
Analiza techniczna
Kluczowy problem techniczny polega na tym, że modele generatywne są optymalizowane przede wszystkim pod kątem użyteczności i poprawności funkcjonalnej odpowiedzi. To nie oznacza automatycznie, że wygenerowany kod będzie bezpieczny, odporny na nadużycia lub zgodny z politykami organizacji.
W praktyce kod tworzony przez AI może wyglądać wiarygodnie i działać zgodnie z oczekiwaniami użytkownika, a mimo to zawierać klasyczne błędy AppSec. Dotyczy to zarówno logiki aplikacyjnej, jak i konfiguracji chmury, interfejsów API, kontenerów czy zależności open source.
- brak właściwej walidacji danych wejściowych i ryzyko podatności iniekcyjnych,
- błędne wdrożenie mechanizmów uwierzytelniania i autoryzacji,
- niewłaściwe zarządzanie sekretami, w tym osadzanie kluczy i tokenów w kodzie,
- użycie niezweryfikowanych bibliotek i pakietów,
- generowanie niebezpiecznych konfiguracji dla chmury, API i kontenerów,
- pomijanie obsługi błędów, przypadków brzegowych i kontroli integralności.
Istotnym problemem jest także skala. AI pozwala tworzyć kod szybciej, niż wiele organizacji potrafi go przejrzeć, przetestować i zatwierdzić. W rezultacie rośnie luka pomiędzy tempem developmentu a tempem zapewniania bezpieczeństwa. Jeżeli firma nie ma wdrożonych skutecznych bramek jakościowych, narzędzia generatywne mogą przyspieszyć nie tylko dostarczanie funkcji, lecz także produkcję długu technicznego i długu bezpieczeństwa.
Ryzyko rozszerza się również na software supply chain. Narzędzia AI mogą proponować zależności, wzorce integracyjne lub fragmenty kodu odwołujące się do zewnętrznych komponentów bez pełnego zrozumienia ich pochodzenia, historii podatności, poziomu utrzymania czy ograniczeń licencyjnych. W środowiskach CI/CD może to prowadzić do szybkiego propagowania błędów na kolejne etapy procesu wytwórczego.
Nie bez znaczenia pozostaje kwestia odpowiedzialności. Im większy udział AI w tworzeniu kodu, tym trudniej jednoznacznie ustalić, kto odpowiadał za konkretne założenia projektowe, dobór mechanizmów ochronnych i akceptację ryzyka. To utrudnia audyt, analizę incydentów oraz wykazanie zgodności z wymaganiami regulacyjnymi i kontraktowymi.
Konsekwencje / ryzyko
Dla organizacji biznesowych „vibe coding” oznacza wzrost prawdopodobieństwa wdrożenia aplikacji, które są funkcjonalne, ale nieprzygotowane na realne zagrożenia. Tego rodzaju rozwiązania mogą przejść podstawowe testy akceptacyjne, a mimo to pozostać podatne na nadużycia po wystawieniu do Internetu lub po integracji z innymi systemami.
- wyciek danych klientów i danych uwierzytelniających,
- przejęcie kont oraz eskalacja uprawnień,
- kompromitacja środowisk chmurowych i interfejsów API,
- incydenty wynikające z podatnych zależności open source,
- naruszenie wymogów regulacyjnych i zapisów umownych,
- wzrost kosztów utrzymania i bezpiecznego rozwoju systemu.
Szczególnie narażone są organizacje, które demokratyzują tworzenie aplikacji bez równoległego wzmacniania dojrzałości AppSec. Gdy presja na szybkość dostarczania rozwiązań dominuje nad formalnym przeglądem bezpieczeństwa, AI staje się mnożnikiem ryzyka. Dotyczy to zwłaszcza prostych aplikacji wewnętrznych, automatyzacji procesów, rozwiązań SaaS tworzonych pod presją czasu oraz projektów rozwijanych przez małe zespoły bez dedykowanego wsparcia bezpieczeństwa.
Rekomendacje
Organizacje wdrażające AI do developmentu powinny traktować kod generowany przez modele z ograniczonym zaufaniem. Taki kod wymaga walidacji, kontroli i pełnej ścieżki audytowej, podobnie jak artefakty pochodzące od zewnętrznego dostawcy.
- wprowadzenie obowiązkowego human-in-the-loop dla kodu tworzonego przez AI,
- egzekwowanie code review z naciskiem na logikę bezpieczeństwa, autoryzację i ochronę danych wrażliwych,
- uruchamianie SAST, SCA, secret scanning oraz testów IaC i kontenerów w pipeline CI/CD,
- stosowanie DAST oraz testów nadużyć dla aplikacji webowych i API,
- blokowanie wdrożeń, które nie spełniają minimalnych wymagań secure-by-design,
- ograniczanie uprawnień narzędzi AI oraz dostępu do repozytoriów, sekretów i środowisk produkcyjnych,
- utrzymywanie listy dozwolonych modeli, wtyczek i źródeł zależności,
- dokumentowanie pochodzenia wygenerowanych artefaktów i decyzji akceptacyjnych,
- szkolenie zespołów z bezpiecznego używania asystentów kodowania,
- mapowanie procesu do uznanych ram, takich jak SSDLC, secure-by-default i praktyki software supply chain security.
W praktyce warto przyjąć, że AI może przyspieszać implementację i generować szkice rozwiązań, ale kluczowe decyzje architektoniczne, zarządzanie sekretami, projektowanie kontroli dostępu i akceptacja ryzyka muszą pozostawać po stronie ludzi. Dobrą praktyką jest także przygotowanie wewnętrznych szablonów promptów i wzorców implementacyjnych, które już na etapie generowania kodu promują bezpieczne mechanizmy.
Podsumowanie
Ostrzeżenie NCSC nie jest krytyką samego użycia AI w programowaniu, lecz przypomnieniem, że automatyzacja nie zastępuje odpowiedzialności inżynierskiej. „Vibe coding” może zwiększyć produktywność zespołów, ale bez odpowiednich kontroli równie skutecznie zwiększa powierzchnię ataku i skalę błędów.
Dla zespołów bezpieczeństwa i liderów technologicznych kluczowe staje się dziś nie pytanie, czy programiści korzystają z AI, ale czy organizacja ma procesy, narzędzia i nadzór pozwalające bezpiecznie zarządzać kodem generowanym przez modele. To właśnie dojrzałość SSDLC będzie decydować o tym, czy AI stanie się akceleratorem innowacji, czy źródłem nowych incydentów.
Źródła
- Infosecurity Magazine – NCSC urges vibe coding caution at RSAC
- NCSC – Software Code of Practice: building a secure digital future
- NCSC – Software Security Code of Practice: Assurance Principles and Claims
- NCSC – Guidelines for secure AI system development
- NCSC – Securing HTTP-based APIs: authentication and authorisation