AI opravy bezpečnostních chyb potřebují kontext. Snyk ukázal rozdíl 10,8 bodu

AI umí napsat opravu, ale umí ji také obhájit?

Generativní AI dnes bez potíží doplní funkci, přepíše dotaz do databáze nebo navrhne validaci vstupu. Bezpečnostní oprava je ale přísnější disciplína. Kód může vypadat čistě, projít běžným testem a přesto dál umožňovat SQL injection. Anebo zranitelnost skutečně odstraní, ale zároveň rozbije chování, na kterém závisí zbytek aplikace. Je to podobné jako oprava brzd, po které auto sice bezpečně zastaví, ale už nezatáčí.

Právě tento rozdíl měřil benchmark Golden Tests od Snyku, zveřejněný 18. srpna 2026. Snyk v něm porovnal šest konfigurací: Gemini 3.1 Pro, Claude Sonnet 4.6, Claude Opus 4.6, starší interní model StarCoder a dvě varianty Claude se zapojenou technologií Snyk Intelligence.

Dvě podmínky, jeden pokus

Testovací sada obsahovala přibližně 150 reálných zranitelných ukázek. Přesné rozdělení bylo 50 vzorků v Pythonu, 54 v JavaScriptu a 39 v Javě. Každý soubor obsahoval jednu ověřenou zranitelnost a dvě skryté jednotkové zkoušky.

První test ověřoval, že útok už neprojde. U SQL injection například poslal škodlivý vstup a kontroloval, zda databáze nevrátí všechny záznamy. Druhý test ověřoval, že legitimní požadavek stále funguje. Model testy neviděl a oprava se počítala pouze při prvním pokusu, pokud prošla oběma. Nešlo tedy o soutěž v psaní kódu, který se tváří přesvědčivě, ale o kombinaci bezpečnostního a regresního testu.

Modely se srovnaly do těsného balíku

Výsledky základních konfigurací byly překvapivě podobné:

• StarCoder, předchozí model Agent Fix: 72,4 %;
• Claude Sonnet 4.6 bez dodatečného kontextu: 72,4 %;
• Gemini 3.1 Pro: 74,2 %;
• Claude Opus 4.6 bez dodatečného kontextu: 74,6 %;
• Claude Sonnet 4.6 se Snyk Intelligence: 82,5 %;
• Claude Opus 4.6 se Snyk Intelligence: 85,4 %.

Rozdíl mezi třemi samostatně použitými frontier modely činil jen 2,2 procentního bodu. To je důležitý signál: v tomto konkrétním úkolu nepřinesl novější nebo obecně schopnější model automaticky zásadní skok. Srovnání samozřejmě neříká, že jsou Gemini a Claude stejně dobré ve všech programátorských úlohách. Říká jen, že při opravách známých zranitelností byl jejich výsledek bez specializovaných informací podobný.

Patnáct oprav navíc z jedné databáze

Snyk Intelligence funguje jako dynamický few-shot prompting. Česky řečeno: při zadání opravy systému nepřidá jen obecnou instrukci „oprav chybu“, ale vybere relevantní příklady odborně napsaných oprav z databáze Snyku čítající více než 35 000 zranitelností. Model tak dostane mapu terénu, nikoli pouze lepší tužku.

Opus 4.6 se tím posunul o 10,8 procentního bodu. Snyk tento rozdíl vyjadřuje také jako relativní nárůst o 14,48 procenta, protože 10,8 děleno původními 74,6 je přibližně 0,1448. Při přesném počtu 143 testovacích vzorků to odpovídá zhruba 15 dalším případům, které by prošly oběma kontrolami. To není kosmetika, zvlášť když neopravená chyba může zůstat v produkci nebo vytvořit další práci pro bezpečnostní tým.

Největší zlepšení se objevilo v Pythonu. Samotný Opus tam zvládl 64 % vzorků, se Snyk Intelligence 88 %. V JavaScriptu a Javě byl základní výsledek vyšší a zlepšení menší, přibližně o pět až šest bodů. Specializovaný kontext tedy nezvedl jen průměr, ale hlavně nejslabší část výsledku.

Co benchmark neříká

Výsledek je zajímavý, ale není to univerzální certifikát bezpečného AI programátora. Testoval jednotlivé soubory s jednou zranitelností, nikoliv celý vícevrstvý projekt, kde se chyba může přelévat mezi moduly, konfigurací a závislostmi. Pokryté jsou pouze tři jazyky. Snyk také uvádí, že výsledek Opusu se Snyk Intelligence vznikl jako průměr dvou běhů: 86,0 a 84,6 %. Rozdíly menší než dva body proto není rozumné vydávat za přesné pořadí.

Navíc jde o výzkum výrobce vlastního nástroje. Snyk popisuje výběr vzorků i metodiku, ale nezávislé zopakování by mělo větší vypovídací hodnotu. Pozitivní je, že testy byly skryté a oprava musela splnit dvě protichůdné podmínky. To je realističtější než benchmark, v němž model pouze porovnává svůj výstup s referenčním textem.

Praktický dopad pro české vývojáře

Snyk Agent Fix není běžný chatbot pro jednotlivce a česká lokalizace rozhraní ani samostatný český tarif z uvedených oficiálních materiálů nevyplývá. Služba je dostupná jako součást platformy Snyk pro vývojové a bezpečnostní týmy, takže jazykem pracovního prostředí bude typicky angličtina. Snyk na své oficiální stránce s cenami uvádí bezplatný plán, Team od 25 dolarů měsíčně za přispívajícího vývojáře, Ignite od 1 260 dolarů ročně a Enterprise s cenou na vyžádání. Z veřejné tabulky nelze vyčíst, zda je Agent Fix v každém plánu samostatně zahrnutý, proto jej nelze poctivě vydávat za funkci za 25 dolarů.

Pro českou firmu je podstatnější workflow než samotný model: nástroj může navrhnout opravu, ale pull request by měl stále projít automatickými testy, SAST kontrolou a lidským review. V evropském prostředí se navíc vyplatí vědět, kam odcházejí zdrojové kódy a kde jsou data hostována. Snyk uvádí regionální hosting včetně evropské varianty, konkrétní podmínky je ale nutné ověřit ve smlouvě.

To zapadá i do aktuálního evropského rámce. Evropská komise uvádí, že pravidla AI Actu pro obecně použitelné modely platí od srpna 2025 a od 2. srpna 2026 se uplatňuje širší rámec včetně dohledu a transparentnosti, s výjimkami pro některé kategorie. AI nástroj na opravu kódu tím automaticky není „vyhovující AI“. Firmy ale musí řešit řízení přístupu, dohledatelnost změn a bezpečnostní procesy podle toho, k čemu systém používají.

Verdikt: kontext porazil honbu za větším modelem

Nejzajímavější závěr benchmarku není, že Snyk získal vysoké číslo. Je jím rozdíl mezi 74,6 a 85,4 procenta u stejného modelu. Specializované příklady dokázaly zlepšit výsledek více než prosté přepínání mezi několika špičkovými modely. Pro firmy to znamená, že při nasazování AI do bezpečnosti má smysl investovat nejen do modelu, ale také do kvalitních dat, testů a kontrolních mechanismů.

AI tedy může být velmi užitečný první opravář. Neměla by ale být posledním člověkem u zamčených dveří. U bezpečnostních chyb zůstává správná kombinace: model s relevantním kontextem, skryté testy, reprodukovatelný proces a někdo, kdo se pod změnu podepíše.