Skener tu chybu našel. Jen v sousedním souboru téhož pull requestu

Do veřejného repozitáře Snowflaku se v červnu dostal pull request, který otevřel komukoli na internetu možnost spustit příkazy na jejich build serveru. Za pět dní tudy odtekl přístupový token do firemní Jiry. Titulky z toho udělaly „AI napsala chybu, kterou AI review přehlédl". Zkontroloval jsem to přímo v repozitáři a je to jinak — a hůř. Automatický skener tu chybu našel. Jen ji nahlásil u vedlejšího souboru v tomtéž pull requestu a nikoho nenapadlo se podívat o řádek dál.

Co se stalo

• Kdo a kdy: bezpečnostní firma Wiz zveřejnila 17. srpna 2026 rozbor Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot. Jejich autonomní útočný agent našel a sám zneužil chybu v knihovně snowflakedb/snowflake-connector-net. Převzal to The Register.
• Kudy vedla díra: workflow jira_issue.yml, které z každého nově založeného GitHub issue zakládá ticket v Jiře. Titulek issue se vkládal rovnou do shellového příkazu. Kdokoli bez přihlášení mohl založit issue s upraveným titulkem a spustit si tím vlastní příkaz na běžícím GitHub Actions runneru.
• Co odteklo: podle Wizu se z runneru podařilo poslat ven JIRA_API_TOKEN, e-mail a adresu instance. Token se autentizoval jako qa@snowflake.net proti snowflakecomputing.atlassian.net a měl čtecí přístup do projektů inženýrství, bezpečnostní compliance a evidence bug bounty.
• Časová osa: PR #1218 byl sloučen 18. června 2026 v 10:18 UTC. Wiz chybu našel 23. června, téhož dne ji nahlásil a Snowflake ji týž den odpoledne opravil. Token rotovali 24. června. Okno bylo pět dní.
• Zneužil to někdo další? Podle vyjádření Snowflaku pro The Register audit neukázal žádný neoprávněný přístup a jediným, kdo se v tom okně na endpoint dostal, byl Wiz. To je dobrá zpráva a zároveň jediný důvod, proč se o tom dnes píše jako o výzkumu a ne jako o úniku.

Co v titulcích nebylo

Commit i pull request jsou veřejné, tak jsem si je otevřel. Tři věci, které v převzatých článcích nejsou.

• Skener tu chybu našel — u souboru vedle. V tom pull requestu jsou přesně dva automatické review komentáře a oba míří na jira_close.yml, ne na zranitelný jira_issue.yml. První z nich má rovnou titulek „Code injection" a upozorňuje na vkládání hodnoty, kterou „může ovládat externí uživatel". Tedy: nástroj rozpoznal správnou třídu chyby, ohlásil ji na jednom ze dvou téměř totožných souborů, ten se opravil — a identický vzorec v sousedním souboru téhož PR zůstal. U zranitelného souboru není ani jeden komentář.
• „AI napsala ten kód" není doloženo. Titulky tvrdí, že chybu zavedla AI. Ve skutečnosti je autorem pull requestu jmenovitě uvedený inženýr Snowflaku a Copilot Autofix je pouze jedním ze tří spoluautorů výsledného commitu. Sám Wiz svůj text 18. srpna upravil s tím, že doložený příspěvek Copilotu mířil na ten druhý soubor a jestli byl zranitelný kód psaný s pomocí AI, není jasné. Berte to prosím takto — je to rozdíl mezi „AI selhala" a „proces selhal".
• Mezi schválením a sloučením uběhlo deset sekund. Pull request byl otevřený od srpna 2025, tedy víc než deset měsíců. Ráno 18. června v 7:19 UTC k němu přibylo automatické hlášení o oprávněních, v 10:17:59 ho člověk schválil a v 10:18:09 byl sloučen. Nic z toho není samo o sobě pochybení. Dohromady to je ale přesně ten obrázek, který v podobných případech vidím u klientů: dlouho ležící změna infrastruktury, kterou nakonec někdo odbaví jedním kliknutím, protože „to je jenom workflow".

Proč se to týká i vás

Tohle není chyba v AI modelu ani v produktu Snowflaku. Je to chyba v souboru, který má u sebe skoro každá firma, co používá GitHub — a skoro nikdo ho nepovažuje za kód.

• Automatizace kolem repozitáře je stejně citlivá jako produkce. Workflow, které zakládá tickety, posílá zprávy na Slack nebo nasazuje na testovací prostředí, má přístup k firemním tajemstvím. Přitom prochází review tak, jak by u produkčního kódu nikdo netoleroval.
• Vstup od cizího člověka je i titulek issue. Firmy si hlídají formuláře a API, ale titulek GitHub issue, předmět e-mailu nebo jméno souboru z uploadu berou jako neškodný text. V okamžiku, kdy se takový text vloží do příkazu, je to vstupní brána.
• Automatický skener vám dá bod, ne mapu. Tohle je z celého případu ta nejdůležitější věta. Nástroj nahlásí konkrétní řádek v konkrétním souboru. Že tentýž vzorec máte ještě na pěti dalších místech, vám neřekne — a člověk, který nález odbaví, obvykle opraví přesně to, co bylo v hlášení, a dál se nedívá. Zelený stav skeneru tedy neznamená „je to čisté", znamená „to, co jsem hledal na místech, kam jsem se podíval, je opravené".
• AI asistent v review tenhle problém neřeší, jenom ho zrychluje. Když nástroj ohlásí „vše v pořádku", vzniká pocit, že už se tam někdo díval. Ve skutečnosti se díval jinam.

Co s tím

Čtyři kroky, které zvládne vlastní vývojář za jedno odpoledne. Nic z toho není produkt.

• 1. Projděte si workflow soubory na tenhle jeden vzorec. Hledáte místa, kde se hodnota od uživatele vkládá přímo do shellu — v GitHub Actions typicky ${{ github.event.issue.title }}, ...comment.body nebo ...pull_request.title uvnitř bloku run:. Ve všech repozitářích, ne jen v tom hlavním.
• 2. Opravuje se to předáním přes proměnnou. Přesně tak to udělal Snowflake: hodnoty se předají v bloku env: a v samotném skriptu se pracuje jen s "$ISSUE_TITLE", JSON se skládá přes jq. Pozor na falešné řešení — v původní verzi bylo escapování přes sed i s komentářem, že ošetřuje speciální znaky. Nefungovalo, protože se text do skriptu dosadí dřív, než se skript vůbec začne vykonávat. Vypadalo to ošetřeně, a právě proto to prošlo.
• 3. Když skener něco najde, opravte i sousedy. Zaveďte si pravidlo, že nález se nezavírá opravou jednoho řádku, ale otázkou „kde jinde tohle máme". V tomhle případě stačilo otevřít druhý soubor v tomtéž pull requestu.
• 4. Omezte, co může runner ztratit. Krátkodobé tokeny místo trvalých, oprávnění jen na to, co daný krok potřebuje, a explicitní permissions: u každého workflow. Pak i úspěšný útok vynese míň.

A teď proti vlastnímu byznysu: pokud jste firma, která AI nevyvíjí a jen používá hotové nástroje, tenhle případ pro vás není důvod řešit AI governance. Je to čistě otázka hygieny vašeho CI. Nekupujte si kvůli němu audit AI systémů — dejte to vývojáři jako úkol na příští sprint. Do agendy AI governance to spadne až ve chvíli, kdy vám do repozitářů začne zapisovat agent, protože tehdy přestane platit, že za každou změnou stojí dohledatelný člověk.

Kde to řeším s klienty

U firem, které už mají v CI napojené AI asistenty nebo agenty, procházím v rámci AI Agent Governance Checkupu právě tuhle vrstvu — kdo a co smí do repozitáře zapsat, jaká tajemství jsou dosažitelná z běhového prostředí a jestli je z logů zpětně poznat, kdo změnu schválil. Jestli si nejste jistí, kolik automatizace u vás na kód reálně sahá, začněte AI Risk Scanem zdarma. Tématu se to dotýká z druhé strany než dřívější text o tom, jak se přes zablokovaný požadavek dá unést AI agent — tam šlo o vstup do agenta za běhu, tady o vstup do prostředí, ve kterém se váš software sestavuje.