Audyt i przejęcie aplikacji stworzonej z pomocą AI
Masz działający prototyp zbudowany w Lovable, Bolt, Replit, Cursorze albo z pomocą innego narzędzia AI. Formularz zapisuje dane, logowanie działa, a aplikację można pokazać na spotkaniu. Problem zaczyna się wtedy, gdy trzeba podłączyć płatności, wprowadzić prawdziwych użytkowników, usunąć kolejny błąd albo odpowiedzieć na proste pytanie: kto będzie ten system utrzymywał?
Nie zakładamy, że kod powstały z pomocą AI jest z definicji zły. Sprawdzamy coś bardziej praktycznego: czy aplikację można powtarzalnie uruchomić, bezpiecznie wdrożyć, odtworzyć po awarii i zmieniać bez psucia innych funkcji. Dopiero po takim rozpoznaniu można uczciwie zdecydować, czy projekt warto poprawić, częściowo przebudować czy potraktować jako prototyp nowej wersji.
Do pierwszej rozmowy nie musisz znać języka programowania ani architektury. Wystarczy opis, do czego służy aplikacja, co obecnie działa i w którym miejscu dalsza praca utknęła.
Kiedy warto zlecić taki audyt?
Prototyp działa, ale nie wiadomo, czy jest gotowy dla klientów
Podgląd w generatorze lub środowisku testowym nie sprawdza całej drogi produkcyjnej. Trzeba jeszcze ustalić konfigurację, dostęp do danych, obsługę błędów, kopie zapasowe, monitoring i możliwość wycofania wadliwej wersji.
Każda poprawka powoduje nowy problem
Zmiana jednego ekranu psuje logowanie, kolejne pole wymaga przerabiania kilku plików, a generator tworzy następne warianty tej samej funkcji. Przyczyną może być pojedynczy błąd, ale też brak wspólnej struktury lub testów chroniących najważniejsze procesy.
Aplikacja ma już dane, płatności lub wielu użytkowników
Wtedy nie wystarcza ocena wyglądu. Znaczenie mają role, uprawnienia, rozdzielenie danych klientów, obsługa webhooków, historia operacji oraz zachowanie po przerwanym żądaniu lub ponowieniu płatności.
Dotychczasowy twórca nie może kontynuować
Projekt może nie mieć dokumentacji, instrukcji wdrożenia ani uporządkowanych dostępów. Przed przejęciem ustalamy, co faktycznie znajduje się w repozytorium i usługach zewnętrznych oraz czy potrafimy odtworzyć środowisko.
Działający ekran nie pokazuje całego ryzyka
Wyobraźmy sobie aplikację subskrypcyjną. Użytkownik tworzy konto, wybiera plan i przechodzi do płatności. Taki przebieg wygląda na gotowy, ale nadal nie odpowiada na kilka ważnych pytań: czy użytkownik może odczytać wyłącznie własne dane, czy serwer sprawdza podpis potwierdzenia płatności, co stanie się po dwukrotnym dostarczeniu tego samego zdarzenia i czy ujawniony wcześniej sekret został unieważniony.
To przykład hipotetyczny, lecz dobrze pokazuje różnicę między demonstracją a systemem gotowym do odpowiedzialnego użycia. W audycie sprawdzamy nie tylko prawidłową ścieżkę. Szukamy też sytuacji, w których brakuje danych, zewnętrzna usługa nie odpowiada, użytkownik ma inną rolę albo operacja zostaje powtórzona.
Jak przebiega rozpoznanie aplikacji?
- Kwalifikujemy projekt. Ustalamy jego przeznaczenie, technologię, dostępne środowiska, rodzaj danych i miejsce, w którym pojawił się problem. Na tej podstawie potwierdzamy, czy projekt mieści się w zakresie naszych kompetencji.
- Uzgadniamy bezpieczny dostęp. Określamy potrzebne repozytorium, konfigurację i konta techniczne. Nie prosimy o wysyłanie haseł ani kluczy w zwykłej wiadomości. Jeśli wystarcza dostęp tylko do odczytu, nie rozszerzamy go bez powodu.
- Wykonujemy płatne rozpoznanie. Uruchamiamy projekt w kontrolowanym środowisku, przeglądamy krytyczne ścieżki i dokumentujemy problemy wraz z ich wpływem na użytkowników oraz dalszy rozwój.
- Przedstawiamy warianty decyzji. Wskazujemy, co można zachować, co wymaga pilnej zmiany, a co będzie taniej lub bezpieczniej zastąpić. Kolejny etap otrzymuje osobny zakres zamiast otwartej obietnicy „naprawienia wszystkiego”.
Co obejmuje audyt?
Obszar
Co sprawdzamy
Dlaczego ma to znaczenie
Uruchomienie i zależności
Czy projekt można odtworzyć, jakich usług i pakietów potrzebuje oraz gdzie znajduje się konfiguracja.
Pokazuje, czy inny wykonawca może pracować bez zgadywania i ręcznego odtwarzania środowiska.
Logowanie i uprawnienia
Uwierzytelnienie, role, operacje dostępne po stronie serwera i rozdzielenie danych użytkowników.
Oddziela ograniczenie widoczne tylko w interfejsie od rzeczywistej kontroli dostępu.
Dane i baza
Model danych, migracje, kopie, usuwanie, importy i miejsca przekazywania informacji do usług zewnętrznych.
Ujawnia ryzyko utraty, pomieszania lub niekontrolowanego udostępnienia danych.
Integracje i płatności
Klucze, webhooki, ponowienia, limity, błędy i zgodność stanu pomiędzy systemami.
Pokazuje, czy przerwane połączenie albo powtórzone zdarzenie nie tworzy podwójnej operacji lub błędnego statusu.
Kod i testy
Strukturę, duplikaty, zależności między modułami, obsługę błędów i testy najważniejszych scenariuszy.
Pomaga ocenić koszt bezpiecznej zmiany oraz prawdopodobne źródła kolejnych regresji.
Wdrożenie i utrzymanie
Sposób publikacji, kopię przed zmianą, monitoring, logi i możliwość powrotu do poprzedniej wersji.
Decyduje, czy aplikację można odpowiedzialnie rozwijać po przejęciu.
Zakres nie jest identyczny dla każdego projektu. Prosty panel wewnętrzny wymaga innej kontroli niż publiczny system z płatnościami i danymi wielu firm. W pierwszym kroku wybieramy elementy, które rzeczywiście wpływają na decyzję właściciela aplikacji.
Po audycie możliwe są cztery różne decyzje
Zachować
Rdzeń jest czytelny i przewidywalny. Wystarczą punktowe zmiany, testy krytycznych procesów, uporządkowanie konfiguracji lub poprawa wdrożenia.
Ustabilizować
System wykonuje swoje zadanie, ale dalsza rozbudowa zwiększałaby ryzyko. Najpierw porządkujemy zależności, dane, błędy i sposób publikacji.
Wymienić moduł
Większość projektu można zachować, lecz jeden obszar, na przykład logowanie, płatności albo dostęp do danych, wymaga osobnej implementacji.
Zbudować nową wersję
Prototyp potwierdził proces i potrzebę użytkowników, ale kod nie daje rozsądnej drogi utrzymania. Ekrany i zdobyta wiedza nadal pomagają zaprojektować właściwe rozwiązanie.
Co otrzymujesz po rozpoznaniu?
- opis aplikacji, technologii i najważniejszych zależności,
- listę problemów z priorytetem, dowodem i wpływem na działanie firmy,
- działania pilne dotyczące dostępu, danych lub ujawnionych sekretów,
- informację, które elementy można zachować,
- rekomendowany wariant dalszych prac i zakres pierwszego etapu,
- materiał ułatwiający przejęcie projektu również wtedy, gdy dalsze prace wykona inny wykonawca.
Raport ma pomagać w decyzji, a nie imponować liczbą uwag. Jeden problem o wysokim wpływie może być ważniejszy niż kilkadziesiąt kosmetycznych ostrzeżeń automatycznego skanera.
Bezpieczeństwo wymaga konkretu, nie samego skanera
Nie każdy identyfikator widoczny w przeglądarce jest tajnym kluczem. Trzeba ustalić, jakie ma uprawnienia i jakie zabezpieczenia egzekwuje serwer lub baza. Klucz administracyjny, token dający szeroki dostęp albo sekret podpisujący webhook nie powinny trafiać do publicznego kodu. Jeżeli taki sekret został ujawniony, samo usunięcie go z pliku nie wystarcza — trzeba go unieważnić i zastąpić.
Automatyczne narzędzia pomagają znaleźć znane wzorce, podatne zależności i przypadkowo zapisane sekrety. Nie rozstrzygają jednak logiki biznesowej. Dlatego łączymy ich wyniki z ręcznym sprawdzeniem przepływu danych, uprawnień i zachowania aplikacji. Takie podejście odpowiada zaleceniom OWASP dotyczącym bezpiecznego przeglądu kodu oraz ramom NIST Secure Software Development Framework.
Jeżeli podejrzewasz aktywny wyciek lub przejęcie kont, zwykły audyt rozwojowy nie powinien udawać obsługi incydentu. Najpierw trzeba ograniczyć dostęp, zmienić dane uwierzytelniające i ustalić sposób zabezpieczenia śladów. Dalszy zakres zależy od rodzaju danych i skutków zdarzenia.
Granice usługi
Standardowe rozpoznanie nie jest certyfikatem bezpieczeństwa, pełnym testem penetracyjnym ani poradą prawną. Możemy wskazać techniczne przepływy danych, uprawnienia, logi i integracje istotne dla dalszej oceny RODO, ale nie zastępuje to analizy prawnej administratora danych.
Nie przyjmujemy też z góry, że potrafimy przejąć dowolną technologię. Najpierw sprawdzamy stos i zależności. Gdy projekt wykracza poza zakres, lepsza jest jasna odmowa lub wskazanie potrzebnej specjalizacji niż eksperymentowanie na działającej aplikacji.
Czy podczas audytu używamy AI?
Narzędzia AI mogą pomagać w wyszukiwaniu zależności lub porządkowaniu materiału, ale nie zastępują osoby odpowiedzialnej za wnioski. Sposób użycia usług zewnętrznych ustalamy przed przekazaniem repozytorium. Kod, konfiguracja i dane klienta nie powinny trafić do publicznego modelu bez świadomej decyzji oraz ustalonych zasad przetwarzania.
Jeżeli projekt wymaga pracy bez zewnętrznego modelu, wskaż to na początku. Dobierzemy proces i narzędzia do tego ograniczenia albo jasno poinformujemy, jakiego środowiska brakuje do wykonania usługi.
Najczęstsze pytania
Czy audyt ma sens przed pierwszym publicznym wdrożeniem?
Tak, szczególnie gdy aplikacja ma obsługiwać płatności, dane osobowe albo konta wielu firm. Łatwiej poprawić sposób dostępu do danych i wdrażania, zanim system zacznie przechowywać informacje prawdziwych użytkowników.
Czy możecie ocenić aplikację bez repozytorium?
Możemy wstępnie obejrzeć widoczne działanie i ustalić potrzebne dostępy. Rzetelna ocena kodu, zależności i wdrożenia wymaga jednak repozytorium albo innej uzgodnionej formy dostępu do źródła.
Czy po audycie możecie przejąć rozwój?
Tak, jeśli technologia i stan projektu mieszczą się w uzgodnionym zakresie. Naprawa, stabilizacja albo nowa wersja są osobnym etapem z własną wyceną i kryteriami odbioru.
Czy audyt gwarantuje brak podatności?
Nie. Zmniejsza niepewność w uzgodnionym zakresie i wskazuje znalezione problemy, ale nie gwarantuje wykrycia każdej możliwej podatności ani przyszłego błędu.
Co przesłać w pierwszej wiadomości?
Napisz, do czego służy aplikacja, w jakim narzędziu lub technologii powstała — jeśli to wiesz — oraz co blokuje publikację albo rozwój. Dodaj informację, czy system ma już użytkowników, płatności lub dane osobowe i czy dysponujesz repozytorium.
Do formularza możesz dołączyć dokumentację, zrzuty ekranu, arkusz z zakresem albo archiwum ZIP z plikami potrzebnymi do wstępnej oceny. Formularz przyjmuje do pięciu plików: maksymalnie 5 MB na plik i 10 MB łącznie. Obsługiwane są PDF, DOCX, XLSX, PPTX, ODT, ODS, ODP, TXT, CSV, MD, JSON, XML, JPG, JPEG, PNG, WEBP i ZIP. Każdy załącznik przechodzi kontrolę typu, rozszerzenia i rozmiaru oraz skan ClamAV przed wysłaniem wiadomości.
Nie przesyłaj haseł, kluczy API, kopii produkcyjnej bazy ani danych klientów. Najpierw ocenimy, czy wystarczy wycena konkretnej poprawki, czy potrzebne jest osobne płatne rozpoznanie i uzgodniony sposób przekazania repozytorium lub dostępu.
Szerszy zakres może prowadzić do modernizacji aplikacji albo przejęcia jej dalszego rozwoju. Pomocna może być również checklista z artykułu Zmiana programisty w istniejącej aplikacji — jak zacząć?.
Źródła techniczne
Opisz projekt do wyceny
Weryfikujemy kod, dane, uprawnienia, integracje i sposób wdrożenia aplikacji powstałych z pomocą AI. Wynikiem jest plan naprawy, przejęcia albo przebudowy oparty na rzeczywistym stanie projektu.