Zdjęcie: © Jefferson Santos / Unsplash
Źródło: unsplash.com/photos/9SoCnyQmkzI
Vibe coding, czyli tworzenie aplikacji przez rozmowę z modelem AI, stało się popularnym sposobem szybkiego budowania prototypów i usług. Termin spopularyzował się po opisie Andreja Karpathy’ego, współzałożyciela OpenAI, który pisał o generowaniu kodu przez wydawanie modelowi poleceń, uruchamianie rezultatów i kopiowanie działających fragmentów bez szczegółowego analizowania samego kodu. Taki sposób pracy może pozwolić osiągnąć więcej przy mniejszych zasobach, ale niesie też ryzyko. Kod, którego twórca nie rozumie lub nie sprawdził, może zawierać luki zagrażające aplikacji, urządzeniom i jej użytkownikom.
Firma Apiiro zajmująca się cyberbezpieczeństwem aplikacji AI podała, że w analizowanych przedsiębiorstwach z grupy Fortune 50 vibe coding zwiększał produktywność inżynierów czterokrotnie, ale wiązał się też z dziesięciokrotnie większą liczbą problemów bezpieczeństwa. Niezależnie od dokładnej skali, wniosek dla początkujących twórców jest prosty: model AI nie powinien być traktowany jak automatyczny audytor. Lepiej postrzegać go jak wykonawcę, który może wybrać skrót, pominąć zabezpieczenie albo wygenerować rozwiązanie wyglądające poprawnie tylko na pierwszy rzut oka.
Słownik artykułu
Krótkie objaśnienia terminów występujących w tekście. Każde hasło prowadzi do szerszej definicji i przykładów użycia.
Tworzenie lub modyfikowanie oprogramowania za pomocą poleceń formułowanych w języku naturalnym, często z pomocą narzędzi AI. Użytkownik opisuje oczekiwany efekt zamiast samodzielnie pisać cały kod.
Wartość przechowywana przez system lub aplikację poza głównym kodem programu. Często zawiera ustawienia, dane dostępowe albo klucze usług.
Wstrzyknięcie SQL to wykorzystanie błędu w obsłudze zapytań do bazy danych w celu wykonania niepożądanych operacji. W opisywanym przypadku podatność dotyczyła bazy używanej przez aplikację Metabase.
Ograniczanie liczby operacji, które użytkownik, konto lub adres IP może wykonać w określonym czasie.
Najważniejsza zasada dotyczy kluczy API, haseł i innych poufnych informacji. Nie należy wpisywać ich bezpośrednio w polecenia dla modelu ani umieszczać w kodzie. Jeśli taki kod trafi później do publicznego repozytorium, na przykład w serwisie GitHub, dane mogą stać się dostępne dla innych osób. Bezpieczniejszym rozwiązaniem jest przechowywanie sekretów w menedżerze haseł oraz używanie funkcji zmiennych środowiskowych, nazywanych także environmental variables, albo zakładek secrets w narzędziach do budowania aplikacji. Gdy platforma nie oferuje takiej funkcji, można wykorzystać plik .env po stronie zaplecza. Trzeba wtedy dopilnować, aby plik nie był publikowany, został dodany do .gitignore i nigdy nie był dostępny w interfejsie aplikacji. Narzędzie TruffleHog może pomóc sprawdzić, czy sekrety nie wyciekły przypadkowo do kodu.
Aplikacje pracujące na większych zbiorach danych często korzystają z SQL. W tym obszarze model powinien zostać poproszony o parametryzowanie zapytań i oczyszczanie danych wejściowych, ponieważ błędy mogą otworzyć drogę do SQL injection attacks. W przypadku krytycznych operacji warto używać Server Actions, włączyć row-level security, czyli RLS, oraz przygotować odpowiednie reguły RLS, jeśli dana platforma je obsługuje. Zabezpieczenia powinny obejmować także zależności. Trzeba sprawdzać, czy model wykorzystuje aktualne biblioteki, ponieważ może wskazać pakiet, który nie istnieje, albo przypadkowo użyć pakietu złośliwego. Przydatne jest również rate-limiting. Ograniczenie liczby prób logowania utrudnia ataki brute force i credential stuffing, a limit żądań może zmniejszyć koszty działania aplikacji, na przykład chatbota. Jeśli to możliwe, limit warto najpierw wiązać z identyfikatorem konta, a dopiero potem z adresem IP. Uzupełnieniem mogą być uwierzytelnianie przez e-mail lub telefon oraz CAPTCHA.
Najlepszym rozwiązaniem pozostaje przegląd wykonany przez doświadczonego programistę. Jeśli nie jest to możliwe, można poprosić model o ponowną ocenę własnego kodu, w tym o sprawdzenie go pod kątem ryzyk z listy OWASP Top 10, nawet jeśli lista była już wcześniej używana jako wskazówka. Dodatkową kontrolę mogą przeprowadzić inne modele albo wyspecjalizowane narzędzia, takie jak Claude Code Security, Codex Security, Wingman firmy StackHawk, CheckVibe, SafeToShip i Vibe App Scanner. Nie należy jednak traktować automatycznego skanowania jako końca pracy. Po wdrożeniu aplikację lub stronę trzeba nadal obserwować, reagować na błędy i sprawdzać, czy wprowadzone zmiany nie osłabiły istniejących zabezpieczeń. AI może przyspieszyć budowanie produktu, ale odpowiedzialność za jego konfigurację, dane i dalsze utrzymanie nadal pozostaje po stronie twórcy.
Brak komentarzy. Bądź pierwszy!