Monitorování AI-generovaného kódu — proč jednorázový sken nestačí
Kód, který nikdo nedržel celý v hlavě
Aplikace poskládaná s výraznou pomocí AI asistenta má jednu vlastnost, kterou ručně psaný projekt nemá ve stejné míře: nikdo — ani člověk, ani model — nedrží v hlavě všechna rozhodnutí, která do ní vstoupila. Model navrhne závislost ve verzi, kterou znal z tréninkových dat, ne tu nejnovější. Vygeneruje konfigurační soubor podle běžného vzoru, který se nezkontroluje řádek po řádku, protože „funguje“. Vytvoří testovací endpoint, který měl zmizet před nasazením a nezmizel. Nejde o nedbalost jednotlivce — je to důsledek toho, že tempo generování kódu je vyšší než tempo, kterým ho kdokoli stihne skutečně přečíst a posoudit.
Proč se to chová jinak než ručně psaný projekt
Několik mechanismů, které se opakují napříč AI-asistovaným vývojem:
- Závislosti přišpendlené k tomu, co model navrhl — verze knihoven odpovídají tréninkovým datům modelu, ne aktuálnímu stavu bezpečnostních záplat. Bez explicitní kontroly zůstávají takové verze v projektu měsíce.
- Vygenerovaná konfigurace okopírovaná bez revize — CORS pravidla, bezpečnostní hlavičky, ukázkové
.envsoubory. Fungují, tak se dál neřeší. - Preview a staging nasazení, která zůstanou běžet — rychlá iterace znamená víc nasazení, víc subdomén, víc věcí, na které se po pár týdnech zapomene.
- Secrets a debug endpointy, které přežijí do produkce — vygenerovaný debug panel nebo testovací klíč, který měl být jen dočasný.
- Změny se nasazují rychleji, než je kdokoli stihne recenzovat — review cyklus, který dřív brzdil každou změnu, se s AI asistencí zkracuje nebo mizí úplně.
Žádná z těchto věcí není exotická chyba. Je to důsledek rychlosti — a rychlost je přesně to, proč se lidé k AI asistenci vůbec uchylují.
Proč jednorázový sken nestačí
Jednorázový bezpečnostní sken je výrok o stavu kódu v jednom okamžiku. U projektu, který se mění týden co týden — často víc nasazeními za den, než starší tým udělal za měsíc — je platnost takového výroku krátká. Otázka, na kterou chcete znát odpověď, není „je to bezpečné teď?“ Je to „až to bezpečné být přestane, za jak dlouho se to dozvím?“
Jednorázový sken na tuhle otázku odpovědět nedokáže — nemá se s čím srovnávat. Řešení není „skenovat důkladněji“, ale skenovat opakovaně a srovnávat výsledek s tím, co bylo včera.
Co denní hlídání mění
Watch při prvním skenu uloží stav domény jako výchozí linii — jaké hlavičky server posílá, jestli běží HTTPS, jaké soubory jsou dostupné, jak vypadají DNS a e-mailové autentizační záznamy. Pak ho každý den znovu proběhne a výsledek porovná s tím předchozím. Když se něco změní způsobem, který stojí za pozornost, přijde upozornění hned — ne až při dalším ručním skenu, který možná nikdo nespustí. Jednou měsíčně navíc přijde souhrnný přehled bez ohledu na to, jestli se během měsíce něco stalo.
Rozdíl proti jednorázovému skenu není v tom, že by Watch viděl víc věcí. Je v tom, že vidí totéž opakovaně a umí říct, kdy se to změnilo.
Co to konkrétně zachytí
Několik reálných příkladů toho, co denní srovnávání aktuálně umí odhalit:
- Nově vystavený soubor. Vygenerovaný
.env, zapomenutá záloha konfigurace nebo otevřený directory listing, který se objeví po nasazení a včera tam nebyl. - Uniklý API klíč AI poskytovatele v klientském kódu. Klíč k OpenAI, Anthropic nebo Google API vložený rovnou do frontendu — typický artefakt rychlého prototypování, kdy se klíč „dočasně“ nastaví na klientovi a zůstane tam.
- Certifikát, který začíná vypršovat nebo vypršel. Časté u preview a staging domén, na které se po skončení iterace přestane sahat.
- Oslabení e-mailové autentizace. Změna DNS záznamů (i vedlejší, při úpravě jiné infrastruktury) může vypnout nebo oslabit SPF/DMARC — Watch to zachytí jako regresi oproti předchozímu stavu.
- Vložený škodlivý skript. Když se do webu dostane cizí kód, další denní kontrola to uvidí jako nový nález, ne až za měsíc.
- Skok v celkové závažnosti nálezů, i když ho nejde přesně přiřadit jedné konkrétní kontrole.
Co Watch nedělá
Watch je pasivní, externí a černá skříňka — čte jen to, co server sám zveřejňuje běžnému návštěvníkovi: HTTP hlavičky, TLS handshake, veřejně dostupné soubory, DNS a e-mailové záznamy. Nepřihlašuje se, neprochází zdrojový kód, není to statická analýza (SAST) ani code review. Nevidí dovnitř aplikace — nezkontroluje logiku, kterou model napsal, ani závislosti, které zvenčí vidět nejsou.
To má konkrétní důsledek: dnešní denní sada kontrol nepokrývá všechno, co u AI-asistovaného vývoje bolí nejvíc. Zastaralé JavaScriptové knihovny na frontendu, přihlašovací formulář odeslaný přes nešifrované HTTP nebo visící CNAME záznam po zrušeném preview nasazení (subdomain takeover) jsou přesně ten typ rizika, který má continuous monitoring smysl hlídat — a v tuto chvíli nejsou součástí denní kontroly Watch. Kontrolní sadu postupně rozšiřujeme; dokud to tak není, radši to řekneme rovnou, než abychom nechali dojem, že Watch hlídá víc, než ve skutečnosti hlídá.
Shrnutí
Hodnota continuous monitoringu u AI-generovaného kódu není v tom, že by nahradil code review nebo pokryl každou třídu rizika. Je v tom, že mění otevřenou úzkost „nevím, co všechno tam je“ na ohraničenou otázku: za jak dlouho se dozvím, že se něco z toho, co Watch vidí, změnilo k horšímu.