Monitorowanie kodu generowanego przez AI — dlaczego jednorazowy skan nie wystarczy
Kod, którego nikt nie miał w całości w głowie
Aplikacja złożona przy dużym udziale AI ma cechę, której projekt pisany ręcznie nie ma w takim samym stopniu: nikt — ani człowiek, ani model — nie trzyma w głowie wszystkich decyzji, które się w niej znalazły. Model podpowiada zależność w wersji, którą zna z danych treningowych, a nie najnowszą. Generuje plik konfiguracyjny według popularnego wzorca, który nigdy nie jest czytany linijka po linijce, bo „działa“. Tworzy testowy endpoint, który miał zniknąć przed wdrożeniem i nie zniknął. Nic z tego nie jest niedbalstwem konkretnej osoby — to konsekwencja tego, że kod powstaje szybciej, niż ktokolwiek zdąży go realnie przeczytać i ocenić.
Dlaczego zachowuje się inaczej niż projekt pisany ręcznie
Kilka mechanizmów, które powtarzają się w rozwoju wspomaganym przez AI:
- Zależności przypięte do tego, co zaproponował model — wersje bibliotek odzwierciedlają dane treningowe modelu, a nie aktualny stan łatek bezpieczeństwa. Bez wyraźnej kontroli takie wersje zostają w projekcie miesiącami.
- Wygenerowana konfiguracja skopiowana bez przeglądu — reguły CORS, nagłówki bezpieczeństwa, przykładowe pliki
.env. Działają, więc nikt już do nich nie wraca. - Wdrożenia preview i staging, które zostają uruchomione — szybsza iteracja to więcej wdrożeń, więcej subdomen, więcej rzeczy zapomnianych po kilku tygodniach.
- Sekrety i endpointy debugowe, które przetrwają do produkcji — wygenerowany panel debugowania albo testowy klucz, który miał być tylko tymczasowy.
- Zmiany wdrażane szybciej, niż ktokolwiek zdąży je zweryfikować — cykl review, który wcześniej spowalniał każdą zmianę, przy wsparciu AI skraca się albo znika całkowicie.
Żadna z tych rzeczy nie jest egzotycznym błędem. To konsekwencja szybkości — a szybkość jest właśnie tym, po co ludzie w ogóle sięgają po wsparcie AI.
Dlaczego jednorazowy skan nie wystarczy
Jednorazowy skan bezpieczeństwa to stwierdzenie o stanie kodu w jednym momencie. Przy projekcie, który zmienia się co tydzień — często z większą liczbą wdrożeń w ciągu dnia niż starszy zespół wykonywał w miesiąc — ważność takiego stwierdzenia jest krótka. Pytanie, na które warto znać odpowiedź, to nie „czy jest bezpieczne teraz?“. To „kiedy przestanie być bezpieczne, jak szybko się o tym dowiem?“
Jednorazowy skan nie może odpowiedzieć na to pytanie — nie ma z czym porównać. Rozwiązaniem nie jest „skanować dokładniej“, tylko skanować powtarzalnie i porównywać wynik z tym sprzed dnia.
Co zmienia codzienne obserwowanie
Przy pierwszym skanie Watch zapisuje stan domeny jako punkt odniesienia — jakie nagłówki wysyła serwer, czy działa HTTPS, jakie pliki są dostępne, jak wyglądają rekordy DNS i uwierzytelniania e-mail. Potem uruchamia tę samą kontrolę każdego dnia i porównuje wynik z poprzednim. Gdy coś zmieni się w sposób wart uwagi, powiadomienie idzie od razu — nie dopiero przy kolejnym ręcznym skanie, którego może nikt nie uruchomi. Raz w miesiącu przychodzi dodatkowo zbiorcze podsumowanie, niezależnie od tego, czy w danym miesiącu coś się wydarzyło.
Różnica względem jednorazowego skanu nie polega na tym, że Watch widzi więcej rzeczy. Polega na tym, że widzi to samo wielokrotnie i potrafi powiedzieć, kiedy się to zmieniło.
Co to konkretnie wyłapuje
Kilka realistycznych przykładów tego, co codzienne porównywanie potrafi dziś wykryć:
- Nowo ujawniony plik. Wygenerowany
.env, zapomniana kopia zapasowa konfiguracji albo otwarte listowanie katalogu, które pojawia się po wdrożeniu, a wczoraj go nie było. - Wyciekły klucz API dostawcy AI w kodzie klienckim. Klucz OpenAI, Anthropic albo Google API wklejony wprost do frontendu — typowy artefakt szybkiego prototypowania, gdy klucz jest ustawiany po stronie klienta „tymczasowo“ i tam zostaje.
- Certyfikat, który zaczyna wygasać albo już wygasł. Częste w przypadku domen preview i staging, których po zakończeniu iteracji nikt już nie dotyka.
- Osłabione uwierzytelnianie e-mail. Zmiana rekordów DNS (nawet przy okazji, przy modyfikacji innej infrastruktury) może wyłączyć lub osłabić SPF/DMARC — Watch wychwytuje to jako regresję względem poprzedniego stanu.
- Wstrzyknięty złośliwy skrypt. Gdy na stronie pojawi się obcy kod, kolejna codzienna kontrola zobaczy to jako nowe zgłoszenie, a nie dopiero za miesiąc.
- Skok ogólnej wagi znalezisk, nawet jeśli nie da się go przypisać jednej konkretnej kontroli.
Czego Watch nie robi
Watch to pasywna, zewnętrzna obserwacja typu black-box — czyta tylko to, co serwer sam udostępnia zwykłemu odwiedzającemu: nagłówki HTTP, uzgadnianie TLS, publicznie dostępne pliki, rekordy DNS i e-mail. Nie loguje się, nie przegląda kodu źródłowego, to nie jest statyczna analiza (SAST) ani code review. Nie widzi wnętrza aplikacji — nie sprawdzi logiki napisanej przez model ani zależności niewidocznych z zewnątrz.
Ma to konkretną konsekwencję: dzisiejszy zestaw codziennych kontroli nie obejmuje wszystkiego, co najbardziej boli w rozwoju wspomaganym przez AI. Przestarzałe biblioteki JavaScript na froncie, formularz logowania wysyłany przez nieszyfrowane HTTP albo wiszący rekord CNAME po wyłączonym wdrożeniu preview (przejęcie subdomeny) to dokładnie ten typ ryzyka, do którego śledzenia służy ciągłe monitorowanie — a obecnie nie są częścią codziennych kontroli Watch. Stopniowo rozszerzamy zestaw kontroli; dopóki tak nie jest, wolimy powiedzieć to wprost, niż sprawiać wrażenie, że Watch obserwuje więcej, niż faktycznie obserwuje.
W skrócie
Wartość ciągłego monitorowania kodu generowanego przez AI nie polega na tym, że zastępuje code review albo pokrywa każdą klasę ryzyka. Polega na tym, że zamienia otwarty niepokój „nie wiem, co tam wszystko jest“ w ograniczone pytanie: jak szybko dowiem się, że coś, co widzi Watch, właśnie się pogorszyło.