Ještě před několika lety vypadal obraz schopného útočníka skoro romanticky. Seděl dlouhé noci u terminálu, četl dokumentaci, ručně procházel HTTP požadavky, zkoušel vstupy ve formulářích, sledoval chybové hlášky a hledal okamžik, kdy se aplikace zachová jinak, než její autoři zamýšleli.

Musel rozumět programování, sítím, databázím, webovým frameworkům, autentizaci, operačním systémům i psychologii lidí, kteří software používají. Musel vědět, kde hledat. Musel umět rozpoznat, kdy je chyba jen drobná nepřesnost a kdy z ní může vzniknout skutečný průlom do systému. A pokud zranitelnost našel, stále bylo potřeba vytvořit exploit, tedy konkrétní způsob, jak danou chybu prakticky zneužít.

Tohle řemeslo nezmizelo. Dobří bezpečnostní experti jsou stále extrémně cenní. Změnilo se ale něco podstatného: část práce, která dříve vyžadovala mnoho času, zkušeností a trpělivosti, dnes dokáže zrychlit či částečně zastoupit umělá inteligence.

Kyberbezpečnost se tím nedostává do úplně nového světa, ale dramaticky se mění tempo hry. Útočník může využít AI model, který mu pomůže číst kód, navrhovat hypotézy, hledat zranitelnosti. Modely zároveň “zapůjčenou” inteligencí zaplňují mezery ve znalostech, které útočníkovi chybí. A to vše snižuje bariéru útoku.

Pro firmy z toho plyne jednoduchý, ale nepohodlný závěr: pokud se zrychluje útok, musí se zrychlit i obrana.

Obsah článku

Jak AI mění ekonomiku útoku

Abychom si rozuměli, pojďme si nejprve vysvětlit tři pojmy, které se v bezpečnosti často používají:

Klíčové pojmy

Zranitelnost je chyba v systému, která umožňuje chování, které autor systému nezamýšlel. Může jít například o situaci, kdy se běžný uživatel dostane k datům, která má vidět jen administrátor. Nebo kdy aplikace přijme vstup, který útočníkovi umožní spustit vlastní příkaz.

Exploit je konkrétní postup, jak takovou chybu využít. Nestačí tedy říct „tady možná něco je“. Exploit znamená, že někdo dokáže ukázat, jak se chyba dá prakticky zneužít.

Zero-day zranitelnost je chyba, o které obránce ještě neví nebo pro ni zatím nemá opravu. Je nebezpečná právě proto, že firma proti ní nemá připravenou záplatu, detekci ani proces.

Dříve bylo hledání zranitelností náročné. Vyžadovalo zkušené lidi, čas a často i specializované nástroje. To chránilo obrovskou spoustu aplikací a třeba open source knihoven, protože útočníci měli omezené kapacity. Jenže moderní AI agenti, tedy jazykové modely napojené na nástroje, soubory, terminál nebo prohlížeč, začínají zvládat části této práce samostatně. Ne dokonale, ne bez dozoru, ale dostatečně dobře na to, aby se změnila rovnováha mezi útočníkem a obráncem.

Výzkum „Teams of LLM Agents can Exploit Zero-Day Vulnerabilities“ ukazuje, že týmy agentů dokážou autonomně zneužívat reálné webové zero-day zranitelnosti v kontrolovaném benchmarku. Autoři vytvořili architekturu HPTSA, kde jeden agent plánuje, další řídí tým a specializovaní agenti se zaměřují na konkrétní typy chyb, například SQL injection, XSS, CSRF nebo server-side template injection.

Jeden obecný agent se snadno ztratí. Zkusí jednu cestu, zpracuje příliš mnoho informací, zaplní si kontext a už se nevrátí k lepší hypotéze.

Context rot (česky kontextová hniloba) označuje postupné zhoršování kvality, spolehlivosti a přesnosti odpovědí LLM modelů s tím, jak roste délka zadání (vstupního kontextu) nebo délka probíhající konverzace.

Tým agentů funguje jinak. Jeden mapuje terén, jiný vybírá specialistu a další se soustředí jen na konkrétní typ útoku. Podobně jako v reálném bezpečnostním týmu.

GPT-4 varianta v benchmarku dosáhla 42 % úspěšnosti při pěti pokusech a 18 % při jednom pokusu. Neznamená to, že AI sama prolomí každou aplikaci. Znamená to, že AI začíná být prakticky použitelná pro hledání a ověřování slabin, které byly ještě nedávno doménou zkušených lidí.

Rychlost útoků nabírá na síle

V kyberbezpečnosti se často mluví o tom, že AI „demokratizuje“ schopnosti. V praxi to znamená jediné: dramaticky snižuje laťku odbornosti. Nástroje a techniky, které dříve vyžadovaly roky studia a hluboké technické znalosti, jsou dnes dostupné komukoliv, kdo umí napsat správný prompt. Pro zaměstnance firmy to zní pozitivně, ale v bezpečnosti to má temnou stránku.

AI pomáhá vývojářům psát kód, nebo i méně zkušeným lidem vytvářet software. Když pomáhá analytikům číst logy, zrychluje práci bezpečnostních týmů. Jenže když pomáhá hledat zranitelnosti, pomáhá každému, kdo ji použije – včetně útočníků.

Google a Mandiant ve svém textu o obraně firem ve světě, kde AI modely nacházejí zranitelnosti rychleji než dřív, upozorňují na kritické okno rizika. Na jedné straně bude AI postupně integrovaná do vývoje a pomůže vytvářet bezpečnější software. Na druhé straně ale útočníci využijí stejné schopnosti k rychlejšímu hledání a zneužívání nových chyb.

To je přesně ten přechodný moment, ve kterém se dnes nacházíme.

Firmy mají historicky nastavené procesy pro svět lidské rychlosti. Bezpečnostní test jednou za rok. Skenování v nějakém intervalu. Patch management podle priorit. Ruční vyhodnocení nálezů. Schvalovací okna. Interní tabulky. Zdlouhavá komunikace mezi bezpečností, IT a vývojem.

Jenže útočník s AI nástroji může pracovat jinak. Může zkoušet více hypotéz paralelně. Může rychleji analyzovat veřejně dostupný kód. Může kombinovat menší chyby do řetězce, který má nakonec výrazně vyšší dopad. Může personalizovat phishing. Může hledat slabiny v knihovnách, pluginech, konfiguracích i dodavatelském řetězci.

A právě dodavatelský řetězec se stává jedním z nejdůležitějších bojišť.

Útok na dodavatelský řetězec

Když se řekne dodavatelský řetězec, většina lidí si představí logistiku, sklady nebo komponenty ve výrobě. V softwaru znamená dodavatelský řetězec (supply chain) něco jiného: knihovny, balíčky, open-source projekty, pluginy, vývojářské nástroje, CI/CD pipeline, cloudové identity, repozitáře a služby třetích stran, ze kterých se software skládá.

Moderní aplikace málokdy vzniká od nuly. Vývojáři používají frameworky, npm a PyPI balíčky, rozšíření do editorů, build nástroje, kontejnery, GitHub Actions, cloudové služby a desítky dalších součástí. Každá z nich je potenciální cesta dovnitř.

To je pro útočníka atraktivní, protože nemusí cílit přímo na finální aplikaci. Stačí kompromitovat jen její malou část, které vývojáři důvěřují.

Příklady z poslední doby ukazují, jak nebezpečná je kompromitace vývojářských nástrojů. Jeden z nedávných případů je trojanizované rozšíření pro Visual Studio Code, které mělo sbírat citlivé údaje z vývojářských zařízení: GitHub tokeny, AWS klíče, npm přístupy, SSH klíče, přístupy do vaultů i konfigurace AI nástrojů. A tento scénář v květnu 2026 zasáhl samotný GitHub, když útočníci ze skupiny TeamPCP zneužili škodlivou verzi legitimního rozšíření na zařízení jednoho ze zaměstnanců. Získané přihlašovací údaje jim následně umožnily zkopírovat a vynést přibližně 3 800 interních softwarových repozitářů společnosti.

Bezpečnost už není jen otázkou toho, zda máte dobře nastavený firewall, antivirus a pravidelné aktualizace serverů. Je to i otázka toho, jak chráníte zdrojový kód, vývojáře, repozitáře, build procesy, tajné klíče a nástroje, kterým vývojový tým každý den důvěřuje.

Pokud se útočník dostane do dodavatelského řetězce, může obejít mnoho tradičních kontrol. Škodlivý kód může přijít jako aktualizace, přičemž spousta nástrojů má aktualizace nastavené automaticky. Přístup může vypadat jako legitimní token. Kompromitace se může rozšířit přes nástroj, který nikdo nevnímal jako kritický.

A AI tento problém dále zrychluje. Pomáhá útočníkům mapovat závislosti, hledat slabá místa, psát přesvědčivější podvody a automatizovat průzkum.

Bezpečnostní modely minulosti

Ještě nejsme v situaci, kdy tradiční bezpečnost přestává dávat smysl. Penetrační testy, skenování zranitelností, patch management, segmentace sítě, správa identit, monitoring a incident response jsou pořád důležité.

Problém je, že samy o sobě už nemusí stačit.

Představme si firmu, která má standardní přístup: jednou ročně provede penetrační test od specialistů, pravidelné automatické skeny, získá seznam zranitelností a spustí proces oprav. Na papíře to vypadá dobře. Jenže pokud se útočníkova schopnost hledat chyby zrychlí několikanásobně, obrana postavená na tomto pomalém cyklu začne zaostávat.

Riziko není jen v tom, že má firma zranitelnosti, protože ty má každá firma. Riziko je v tom, že někdo jiný je dokáže najít, pochopit a zneužít rychleji, než je firma dokáže objevit a opravit. A s tím, jak umělá inteligence postupně snižuje časové a znalostní bariéry pro prolomení obrany, je nutné přemýšlet o změnách přístupu.

Bezpečnost musí být základem každého vývoje aplikace. Nestačí kontrolovat hotovou aplikaci až ve chvíli, kdy je nasazená. Je potřeba průběžně testovat zdrojový kód, změny, konfigurace, závislosti i cesty, kterými se software dostává do produkce.

Nad umělou inteligencí je potřeba přemýšlet jako nad rizikem, ale zároveň i jako obranným nástrojem.

Když útočníci používají agenty, obránci je musí používat také

Nejhorší reakcí na umělou inteligenci v kyberbezpečnosti je pasivita. Doufat, že se schopnosti útočníků nebudou zlepšovat, nebo že sofistikované nástroje zůstanou jen v rukou výzkumníků a velkých laboratoří, je v podstatě bláhové.

Schopnosti se budou šířit. Modely budou levnější, chytřejší, dostupnější. Jejich integrace s terminálem, repozitáři a vývojářskými nástroji se stanou normální součástí práce. To, co je dnes pro některé týmy experiment, bude zítra standardní workflow.

Otázka tedy nezní, jestli bude AI v bezpečnosti hrát roli. Otázka zní, jestli ji firmy začnou používat správně a včas.

Obrana potřebuje stejný typ zrychlení jako útok, ale zasazený do kontrolovaného procesu. Jednoduchý průchod jednoho agenta nestačí. Je třeba strukturovaný postup, který říká: nejdřív mapuj, potom vytvoř konkrétní scénáře a ty nech ověřit specializovanými agenty. Následně proveď nezávislé vyhodnocení a až potom vytvoř finální nález.

Právě v tomto principu funguje nedávno uvolněný Hadrian OpenHack.

Co je Hadrian OpenHack

Hadrian OpenHack je open-source nástroj pro revizi zdrojového kódu pomocí umělé inteligence. Jednoduše řečeno: je to pracovní prostředí a metodika pro agentní kontrolu zdrojového kódu z bezpečnostního pohledu.

Není to klasický skener, který zvenku pošle pár požadavků na aplikaci a vyhodnotí odpovědi. OpenHack pracuje s kódem. Dívá se na strukturu aplikace, hledá zajímavé bezpečnostní plochy a vytváří z nich konkrétní scénáře, které pak řeší specializovaní agenti.

Hadrian OpenHack je navržený tak, aby běžel v běžných vývojových prostředích, jako jsou Claude Code, Codex nebo Cursor. Tato prostředí poskytují LLM agentovi přístup k modelu, terminálu, souborům a repozitáři. OpenHack k tomu přidává pracovní postupy, šablony, agentní role, artefakty a kontrolní body.

Jádro myšlenky je jednoduché: nedávat modelu neurčitý úkol typu „najdi v tomto repozitáři zranitelnosti“. Takový přístup často vede ke směsi použitelných postřehů, falešných poplachů, halucinací a nálezů, které zní přesvědčivě, ale při ověření neobstojí.

OpenHack se místo toho snaží práci rozdělit.

Jak funguje OpenHack (zjednodušeně)

1. Průzkum

2. Logické celky

3. Scénáře

4. Agenti

5. Vyhodnocení

Nejdřív proběhne průzkum kódu. Nástroj hledá aplikační cesty, vstupy, analyzátory dat, autentizační hranice, cílové datové body, funkce pro nahrávání souborů, rizika v závislostech a další místa, kde mohou vznikat bezpečnostní problémy.

OpenHack není postavený na důvěře v jednu odpověď modelu. Je postavený na komplexním procesu a orchestraci agentů.

Proč je důležitá auditní stopa

V prostředí firmy nestačí, aby umělá inteligence „něco našla“. Manažer bezpečnosti, technický ředitel i vývojový tým potřebují vědět, proč byl nález vytvořen, z čeho vychází a jak byl ověřen.

OpenHack proto pracuje se soubory a ukládá artefakty běhu. Každé spuštění má svůj adresář. Uvnitř je čerstvě stažená kopie zdrojového kódu, výstupy z průzkumné fáze, zásobník scénářů, výsledky agentů, kandidáti na nález, rozhodnutí o prioritách, konečná zjištění a systémové záznamy.

Zní to technicky, ale manažersky je to velmi důležité. Když bezpečnostní nález doputuje k vývojáři, neměl by znít jako neurčité „umělá inteligence si myslí, že tady je problém“. Měl by být dohledatelný. Která část kódu se kontrolovala? Jaká byla bezpečnostní otázka? Jaký agent ji řešil? Jaké důkazy našel? Kdo nebo co rozhodlo, že nález je platný?

Auditní stopa je rozdíl mezi experimentem a použitelným bezpečnostním procesem.

OpenHack není náhradou za bezpečnostní experty

Je důležité říct jednu věc jasně: OpenHack není kouzelný AI penetrační tester, který nahradí bezpečnostní odborníky.

Je to experimentální nástroj a pracovní postup, který může pomoci automatizovat části bezpečnostní revize metodou takzvané bílé skříňky (white box). Tento přístup znamená, že se testuje se znalostí vnitřku systému — typicky se zdrojovým kódem. To je rozdíl oproti testování metodou černé skříňky (black box), kde tester vidí aplikaci jen jako externí útočník z internetu.

OpenHack může zrychlit průzkum, pomoci vytvořit scénáře, vést agenty k systematické práci a dodat auditovatelný výstup. Ale pořád potřebuje lidský dohled a expertízu. Bezpečnostní odborník musí rozumět kontextu aplikace, prioritám firmy, dopadu nálezů a tomu, co je skutečné riziko a co jen technická zajímavost.

Umělá inteligence může navrhnout hypotézu. Může najít důkaz. Může pomoci s roztříděním a určením priorit. Ale odpovědnost za rozhodnutí zůstává na lidech.

Firmy nepotřebují umělou inteligenci, která bude sebevědomě produkovat nálezy bez kontroly. Potřebují systém, který bezpečnostním týmům zrychlí práci, vývojářům dá lepší zpětnou vazbu a vedení poskytne lepší přehled o riziku.

Cena za bezpečnost

Je třeba počítat s tím, že podobné workflow spotřebovává hodně tokenů.

Tokeny jsou v jazykových modelech AI zjednodušeně jednotky textu, které jazykový model čte a generuje. Když agent prochází repozitář, čte soubory, zapisuje výstupy, vrací se k důkazům, vytváří scénáře, předává úkoly dalším agentům a čeká na jejich odpovědi, tokeny mizí rychle. A čím více tokenů se spotřebuje, tím vyšší náklady.

Na menším Node.js projektu při 20dolarovém Pro plánu v Codexu mi dokázal jeden běh spotřebovat pětihodinový limit za pár minut, a přitom nepřinést použitelné výsledky. Neznamená to, že OpenHack selhal. Znamená to, že agentní bezpečnostní revize je výpočetně a finančně náročnější než jednoduchý dotaz na model.

Pokud chce firma podobné nástroje využívat, musí počítat buď s vyššími plány v nástrojích typu Codex, Claude Code nebo Cursor, nebo s přímými náklady na inference přes API.

Inference znamená samotné volání modelu — tedy platbu za to, že model čte vstupy a generuje odpovědi.

A to je důležitá součást reality byznysu – AI bezpečnost něco stojí. Ale vyplatí se, pokud firmě umožní testovat častěji, najít chyby dříve a sníží závislost na nákladných jednorázových kontrolách. Cokoliv, co firmu chrání před ztrátou dat, reputace či omezení produkce/služeb má obecně vysokou návratnost investice.

Ve výsledku ale budou nejvíce vydělávat poskytovatelé AI modelů. Reálné zisky firem jako OpenAI či Anthropic jsou v porovnáním s výdaji zatím zanedbatelné, ale kybernetická bezpečnost je pro ně skvělý ekonomický model. Tyto firmy totiž vytvořili a prodávají na jedné straně problém, a na straně druhé prodávají i řešení.

Je to z jeden z mála případů, kdy umělá inteligence dokáže přinášet opravdové zisky, protože předpovědi o náhradě zaměstnanců umělou inteligencí se zatím nepotvrzují a fungují jen u specifických rolí a ve specifických scénářích.

Přínosy pro CEO, COO nebo manažera vývoje

Pro vedení firmy není podstatné, jestli se nástroj jmenuje OpenHack nebo HPTSA, podstatná je změna principu.

Bezpečnost už nemůže být jen poslední kontrola před spuštěním nebo každoroční audit. Musí se stát průběžnou zpětnou vazbou ve vývoji.

  • Pro CEO to znamená nižší pravděpodobnost drahého incidentu, lepší připravenost na svět AI podporovaných útoků a menší pravděpodobnost toho, že se na problém přijde až ve chvíli, kdy je pozdě.
  • Pro COO to znamená procesní otázku: jak rychle firma dokáže reagovat, když se objeví kritická chyba? Existují jasné definované odpovědnosti? Je zřejmé, kdo co opravuje a kdo za co odpovídá? Umí firma oddělit skutečné riziko od šumu?
  • Pro manažera vývoje to znamená praktičtější zpětnou vazbu. Místo obecného seznamu zranitelností může dostat nález navázaný na konkrétní část kódu, konkrétní scénář a konkrétní důkaz.
  • Pro bezpečnostní tým to znamená možnost škálovat část práce. Ne tím, že nahradí lidi, ale tím, že nemusí dělat všechno ručně.

Největší hodnota agentních workflow není v tom, že nahradí odborníky. Je v tom, že odborníkům umožní pracovat ve větším měřítku. Ale jelikož mohou pracovat díky AI ve větším měřítku i útočníci, prakticky se jedná jen o vyrovnání sil.

Adaptovat se neznamená panikařit

Je lákavé popisovat AI v kyberbezpečnosti katastroficky. Stroje budou hledat chyby, útočníci budou rychlejší, obránci nestihnou patchovat a všechno se rozpadne. Realita je složitější.

AI skutečně zrychluje některé útočné schopnosti. Zároveň ale dává obráncům nástroje, které dříve neměli. Může pomoci číst kód, prioritizovat rizika, vysvětlovat nálezy, automatizovat vyhodnocení, generovat návrhy oprav a kontrolovat, zda opravy dávají smysl. Klíčové je nezačít s AI jako s módním doplňkem, je potřeba ho vhodně integrovat a přizpůsobit stávající procesy.

Kde máme zdrojový kód? Kdo k němu má přístup? Kde jsou tajné klíče? Jak chráníme vývojářské stroje? Jaké používáme závislosti? Umíme dohledat, odkud se do produkce dostal konkrétní balíček? Máme pravidelnou kontrolu kódu? Umíme rychle ověřit, zda je nález skutečný? Umíme ho předat vývoji tak, aby ho dokázal opravit?

AI je násobič a urychlovač. Pokud jen zrychlí existující procesní chaos, pak se chyby projeví dříve a ve větším měřítku. Pokud urychlí kvalitní procesy, pak poskytne kompetetivní výhodu a silnou kybernetickou obranu.

Útočník a obránce budoucnosti

Na začátku jsme si představili hackera minulosti. Člověka, který musel sám držet v hlavě znalosti, nástroje, hypotézy i plán. Útok byl pomalý, náročný a vyžadoval řemeslo. Díky tomu se obrovská spousta open source nástrojů vyhnula zneužití, protože lidské kapacity jsou nedostatečné a pracují v omezeném měřítku. Každá knihovna a aplikace je pravděpodobně zranitelná, ale útočníci neměli kapacitu na všechny zaměřit svou pozornost.

Útočník budoucnosti bude vypadat jinak. Nemusí ručně zkoušet každý nápad. Nemusí se soustředit jen na jeden projekt. Spustí tým agentů, nechá je mapovat aplikaci(e), číst kód, hledat slabiny, zkoušet různé cesty a vracet mu jen to, co vypadá slibně. Nemusí už být expert na kyberbezpečnost. Stačí, když umí nástroje správně použít. A právě proto se musí změnit i obránce.

Obránce budoucnosti nebude pasivně čekat na roční pentest. Bude průběžně kontrolovat vlastní kód. Bude chránit a sledovat dodavatelský řetězec. Bude hlídat vývojářské nástroje a identity. Bude používat AI nástroje k tomu, aby našli slabiny dřív než útočník. A bude trvat na tom, aby AI výstupy byly auditovatelné, ověřené a zasazené do procesu.

Nástroje jako Hadrian OpenHack nejsou odpovědí na všechny bezpečnostní problémy. Jsou ale dobrou ukázkou směru, kterým se obrana musí vydat: od jednorázových kontrol k průběžnému, agentnímu a auditovatelnému testování vlastního kódu. Nemusíme čekat na slibované dovednosti modelů jako je aktuálně veřejnosti nedostupný Claude Mythos, existující modely jsou při vhodném použití již dostatečně efektivní.

V době, kdy AI snižuje bariéru a zvyšuje rozsah a rychlost útoků, nesmí bezpečnost zůstat jen procesem v pozadí, který běží s omezením lidské kapacity. Bezpečnost musí být promyšlená, proaktivní, využívat moderní nástroje a přizpůsobovat se změnám. Musí být zavedena v procesech jako nutnost a základní stavební kámen, ne jako vedlejší prvek s minimálním rozpočtem a historickou degradací efektivity.

Potřebujete poradit?

Nejste si jistí kvalitou zabezpečení nebo stávajích procesů ve vaší firmě? Chcete zjistit, jak i vaši firmu připravit na novou éru kybernetické bezpečnosti. Rádi s vámi situaci probereme v rámci nezávazné konzultace.

Nezávazná konzultace

Zdroje

Ohodnoťte prosím příspěvek. Díky tomu budeme vědět, na jaký obsah se v budoucnu soustředit.

Chcete být informováni o nových článcích na blogu Solutia?

Sledujte aktuální novinky a trendy z IT světa na našem profilu.

Sledovat na LinkedIn