Bezpečnostní oprava má zvláštní druh zpoždění. Chyba je zveřejněná, patch existuje, ale miliony starších instalací stále běží na větvi, do které ho někdo musí ručně přenést, upravit a otestovat. Čerstvá zpráva o Codexu a bezpečnostních backportech ukazuje, že právě tady začíná AI být prakticky užitečná.
Trail of Bits uvádí, že s Codexem zkrátil proces, který dříve zabíral dny, na hodiny. Do 29. října podle firmy pomohl připravit opravy 149 různých zranitelností pro stabilní vydání linuxového jádra a další opravy pro Fedoře a Ubuntu. Neznamená to, že vznikl nový automatický správce bezpečnosti. Znamená to, že lidé dostali nástroj, který zvládne větší kus nudné práce, než se obvykle připouští.
Původní popis Trail of Bits je v tomto ohledu zajímavější než další demo, v němž agent napíše pár řádků kódu. Tady musí pracovat se starým kódem, hledat správný bod zásahu, zachovat chování systému a přesvědčit testy, že oprava nerozbila něco jiného. To je práce, která se špatně prodává na konferenčním pódiu, ale rozhoduje o tom, jestli se oprava skutečně dostane k uživatelům.
Nejpomalejší část opravy není hledání chyby
Backport není prosté Ctrl+C a Ctrl+V z nové větve do staré. Moderní oprava často předpokládá změny v API, datových strukturách nebo okolním kódu, které ve starší verzi vůbec nejsou. Někdo proto musí pochopit původní chybu, najít její ekvivalent ve starém stromu a upravit patch tak, aby řešil stejný problém bez přenesení celé nové architektury.
Podle Trail of Bits agenti vyhledávají chybějící opravy, upravují patche pro starší kód, připravují důkazy a spouštějí testy. Člověk ale stále kontroluje výsledek, řeší regresní testování a posílá opravu správcům projektu. To je důležitá hranice: Codex může zrychlit přípravu změny, ale nemá pravomoc prohlásit, že bezpečnostní oprava je připravená pro všechny podporované systémy.
Právě tady se ukazuje rozdíl mezi běžným generováním kódu a tím, čemu se dá říkat AI generování záplat. Výstup není hotový jen proto, že se syntakticky přeloží nebo projde jedním testem. Musí být dohledatelný, opakovatelný a dostatečně srozumitelný pro maintainera, který za něj nakonec ponese odpovědnost.
Na Radyzu jsme už psali o pluginech Trail of Bits pro opravy chyb a hledání regresí. Jejich smysl nebyl v tom, aby agent dostal volnou ruku. Šlo o reprodukci problému, návrh změny, testování a doložení výsledku. Nové použití Codexu tento přístup posouvá z jednotlivých oprav k většímu provoznímu objemu.
149 oprav je důležité číslo, ale není to audit
Číslo 149 zní přesvědčivě, jenže je potřeba ho číst přesně. Jde o údaj, který zveřejnil Trail of Bits o vlastní práci a k datu 29. října; není to nezávislý audit všech bezpečnostních backportů v linuxovém ekosystému. Firma tím dokládá rozsah svého procesu, nikoli univerzální míru úspěšnosti Codexu v každém projektu.
Stejně opatrně je potřeba zacházet s odhadem lidské práce. Trail of Bits uvádí přibližně 30 minut pro jednoduchý backport a zhruba tři hodiny pro složitější případ. To je užitečná provozní orientace, ne slib, že každá oprava bude hotová za stejnou dobu. Rozhoduje stav staré větve, kvalita testů, počet podporovaných konfigurací i to, zda se chyba dotýká více vrstev systému.
Přesto je ten posun podstatný. Starší větve jsou bezpečnostní dluh, který nikdo nevidí v produktové prezentaci, dokud se neobjeví zranitelnost a někdo musí opravu dostat do desítek kombinací distribucí, jader a balíčků. Když agent zkrátí první technickou práci z několika dnů na hodiny, může tým věnovat více času kontrole a méně času ručnímu přepisování změn.
To ale platí jen tehdy, když se ušetřený čas neztratí v jiné části procesu. Pokud vznikne více patchů, ale stejný počet lidí je musí kontrolovat stejně pomalu, část zisku se přelije do fronty na review. Bez měření regresí, návratů k opravě a času do vydání bychom pouze zaměnili jeden hezký marketingový údaj za jiný.
Bezpečnost má vlastní mezeru mezi opravou a aktualizací
Uživatelé často slyší o zranitelnosti až ve chvíli, kdy je oprava hotová. Mezitím ale vzniká mezera mezi opravou a aktualizací: období, kdy je řešení veřejné nebo dostupné správci projektu, ale ještě není v systému, který skutečně používá zákazník. Čím déle trvá backport a testování, tím déle tato mezera zůstává otevřená.
Nedávný případ s modelem GLM 5.3 a Firefoxem připomněl opačnou stranu závodu: zveřejněný patch může útočníkovi napovědět, kde hledat slabé místo dříve, než se oprava dostane ke všem uživatelům. Obránci proto nepotřebují jen lepší detekci chyb. Potřebují také rychlejší a spolehlivější cestu od nalezené opravy k vydané aktualizaci.
Podobně výzkum Anthropic o hledání zranitelností ukazuje, že AI může pomáhat na straně objevování chyb. To vytváří nepříjemnou asymetrii. Útočníkovi stačí najít jednu použitelnou cestu, zatímco obránce musí opravu přizpůsobit mnoha verzím, ověřit ji a distribuovat bez nové škody.
Právě proto dává smysl automatizovat i tu méně atraktivní polovinu bezpečnostní práce. Není rozumné nechat AI samostatně rozhodovat o vydání opravy do kritické infrastruktury. Je ale stejně nerozumné trvat na tom, aby lidé ručně přepisovali každý patch mezi větvemi jen proto, že finální podpis musí zůstat lidský.
Codex není nový maintainer
Maintainer nečte pouze diff. Musí vědět, proč chyba vznikla, jaké chování se má zachovat, které konfigurace jsou citlivé a jestli test skutečně pokrývá problém, kvůli němuž oprava vznikla. Agent může připravit velmi dobrou změnu a přesto přehlédnout důsledek, který se projeví až na jiné platformě nebo v kombinaci s dalším modulem.
V bezpečnostním procesu je proto důležitější dohledatelná práce než sebejisté tvrzení o dokončení. Který patch agent vybral? Co v původní větvi změnil? Jaké testy spustil? Co zůstalo mimo jeho rozsah? Pokud na tyto otázky neumí tým odpovědět, nemá automatizaci pod kontrolou, i kdyby výsledný commit vypadal čistě.
OpenAI popisuje Codex jako nástroj pro bezpečnostní výzkum, ne jako náhradu za celý proces odpovědnosti. To je rozumnější rámování než představa digitálního zaměstnance, který sám pozná, kdy je oprava dostatečně bezpečná. V praxi bude hodnota systému záviset na kvalitě testů, přístupu k historii projektu a pravidlech, která určují, kdy se práce zastaví a předá člověku.
Co se má měřit místo počtu vytvořených patchů
Firmy a správci projektů by neměli sledovat jen počet změn, které agent připravil. Užitečnější je měřit čas od zveřejnění problému k prvnímu ověřenému backportu, podíl oprav vrácených kvůli regresi, dobu lidského review a počet podporovaných větví, které se podařilo skutečně aktualizovat.
Důležitá je také kvalita důkazů. Oprava, která prošla testem v jedné konfiguraci, není totéž jako oprava ověřená proti různým architekturám, distribucím a scénářům, jichž se problém týká. AI může zmenšit objem mechanické práce, ale nemůže za tým rozhodnout, jaké riziko je ještě přijatelné a kdo smí aktualizaci vydat.
Tohle je méně efektní příběh než tvrzení, že agent opravil 149 zranitelností. Ve skutečnosti je ale mnohem důležitější. Bezpečnostní tým nepotřebuje dalšího autora kódu, který bude vyrábět změny rychleji než dřív. Potřebuje zkrátit cestu k opravě, aniž by ztratil přehled o tom, co se změnilo a proč.
AI tedy starý Linux opravdu opravovat umí. Nejtěžší část práce ale stále není napsat patch. Nejtěžší je rozhodnout, že oprava řeší správný problém, nerozbije okolní systém a může bezpečně opustit testovací prostředí. Dokud toto rozhodnutí zůstává na lidech, není to slabina automatizace. Je to její jediná rozumná pojistka.
