Bezpečnostní audit aplikace obvykle začíná seznamem podezřelých míst v kódu a končí tím, že někdo musí ověřit, zda z nich lze skutečně ublížit uživateli. GitHub Security Lab popisuje pokus zkrátit první část: pomocí otevřených AI taskflow prověřoval Android aplikace a podle svého blogu už nahlásil 24 zranitelností. Číslo je zajímavé, ale ještě zajímavější jsou příklady, které za ním stojí — a přiznání, kolik lidské práce se skrývá za slovem „nalezeno“.
Výzkumník GitHubu Kevin Stubbings zveřejnil 28. září postup zaměřený na chyby v mobilních aplikacích. Zprávu jsme stručně zachytili také v rychlé zprávě o 24 zranitelnostech v Android aplikacích. Je důležité dodat, že nejde o 24 chyb samotného Androidu: GitHub mluví o zranitelnostech v jednotlivých aplikacích a o vlastním výzkumném auditu, nikoli o nezávislém srovnávacím testu AI nástrojů.
Nešlo o jeden prompt a zázračné tlačítko
GitHub Security Lab postavil audit jako řetězec menších úloh. Jeden taskflow nejprve třídí vstupní body aplikace, tedy místa, kam může přicházet data zvenčí; další pomáhá zařadit aplikaci a kontrolovat konkrétní třídy chyb v kontextu těchto vstupů. Tím se model neptá jen „najdi bezpečnostní problém“, ale dostává užší otázky a mapu toho, co má prozkoumat.
Autoři kombinovali přísnější kontrolní seznam s opakovanými běhy a širšími zadáními, která nechávají model hledat méně zjevné souvislosti. To je podstatný rozdíl oproti představě, že univerzální chatbot dostane archiv zdrojového kódu a sám vydá spolehlivý verdikt. Podobný rámec se objevil už v dřívější zprávě o AI workflow pro fuzzing, tehdy ale šlo o automatizaci testovacího procesu, nikoli o tuto konkrétní sérii Android nálezů.
V jednom z popsaných případů se chyba týkala navigační aplikace OsmAnd. GitHub uvádí, že nesprávně zpřístupněná část aplikace mohla umožnit jiné aplikaci měnit nastavení tak, aby se informace o poloze dostávaly na server útočníka. Nejde o chybu mapového podkladu ani Androidu jako operačního systému; problém vznikl v tom, jak konkrétní aplikace přijímala a zpracovávala požadavky z jiných aplikací.
Druhý příklad se týká aplikace Wikipedie pro Android. Podle popisu GitHubu kombinace chyb při zpracování odkazů a práce s cookies mohla vést až k převzetí účtu. Záměrně není třeba převádět tento případ na návod k útoku: jeho důležitý bezpečnostní závěr je, že chyba může vzniknout na hranici mezi aplikacemi, webovým obsahem a přihlášenou relací. Dokumentace Androidu k Intentům ukazuje, proč jsou tyto hranice důležité: Intent je způsob, jímž komponenty aplikací žádají o akci nebo předávají data.
Nález není totéž co potvrzená závažnost
V reportu je nejcennější možná právě ta část, kterou marketingový titulek snadno přeskočí. GitHub píše, že modely někdy vytvářely falešné poplachy, přehlížely důležité okolnosti a špatně odhadovaly závažnost. Chyba může vypadat hrozivě, dokud člověk nezjistí, že data jsou přepsána bezpečnější kopií nebo že k jejímu využití by bylo potřeba téměř nemožného stavu aplikace.
Proto GitHub požaduje, aby každý nález posoudil bezpečnostní výzkumník se znalostí mobilních aplikací. U podezření na vážnou chybu nestačí, že model přesvědčivě popsal problém: je potřeba ověřit kód, podmínky zneužití, skutečný dopad a případná zmírňující opatření. Právě v tomto kroku se rozhoduje, zda vývojář dostane použitelný bezpečnostní report, nebo další položku do fronty, kterou musí nejdřív rozplést.
Čtyřiadvacet je navíc číslo uvedené samotným GitHub Security Labem v jeho blogu, nikoli výsledek nezávislého auditu tohoto auditu. Článek přináší konkrétní už zveřejněné příklady a odkazuje na stránku bezpečnostních upozornění GitHub Security Lab, ale neposkytuje nezávislé porovnání s ručním auditem ani úplnou statistiku toho, kolik návrhů modelu skončilo jako falešný poplach. Je rozumné brát číslo jako výsledek konkrétního výzkumného týmu, ne jako záruku, že stejný postup najde stejný počet chyb v každé aplikaci.
Levný začátek, nikoli bezplatný audit
GitHub zveřejnil taskflow jako open source a popsal i jeho spuštění na vlastním projektu. Háček je provozní: postup vyžaduje licenci GitHub Copilot, používá prémiové modelové požadavky a může vyvolat mnoho volání, tedy i značnou spotřebu tokenů. GitHub odhaduje, že kontrola středně velkého repozitáře může běžet hodinu nebo dvě. Otevřený zdrojový kód workflow tedy neznamená, že bezpečnostní kontrola nic nestojí.
Tento kompromis může dávat smysl týmům, které chtějí pravidelně prosévat větší množství kódu nebo hledat chyby v aplikacích, na které se ruční audit dosud nedostal. AI dokáže rychle projít mnoho souborů a navrhnout neobvyklé kombinace komponent; člověk ale stále musí oddělit reálný dopad od teoretického scénáře, ověřit reprodukovatelnost a správně určit závažnost. Kdyby firma vypustila všechny modelové nálezy rovnou do vývojového backlogu, přesunula by práci, nikoli ji odstranila.
Pro vývojový tým proto není hlavní otázka, zda AI umí najít chybu, ale zda má proces, který nález bezpečně dotáhne do konce. Před spuštěním je potřeba vědět, jaký kód a data nástroj dostane, kdo ověřuje jeho závěry a kdo rozhodne o opravě. Praktický základ může vypadat jednoduše:
- Spouštět audit jen nad repozitáři a daty, k nimž má tým oprávnění.
- Vyžadovat od člověka ověření každého nálezu, nejen automaticky přiřazenou závažnost.
- Zaznamenat verzi workflow a modelu, vstupní rozsah, výsledek ověření i důvod, proč byl nález zamítnut.
- U potvrzené chyby navázat běžným procesem odpovědného zveřejnění a opravy.
Bezpečnostní tým nezmizí — může se dostat dál
GitHubův příklad ukazuje užitečnější roli AI než autonomního lovce chyb: rozšířit záběr auditu a předložit člověku konkrétní místa, která stojí za prověření. Odborník pak může věnovat více času ověřování složitých nálezů místo rutinního hledání každého vstupního bodu. To je ale změna rozdělení práce, ne předání odpovědnosti modelu.
Úspěch bezpečnostního nástroje se proto neměří jen počtem nahlášených zranitelností. Záleží také na tom, kolik nálezů je skutečně potvrzených, jak rychle se opraví a zda se při kontrole neztratí důvěrnost kódu nebo kontrola nad citlivými oprávněními. Dokud tyto věci nejsou součástí výsledku, „AI našla 24 chyb“ je působivá zpráva o začátku auditu — nikoli důkaz, že audit lze svěřit stroji.
