AI mění bezpečnost Lin­uxu. Tradiční patchování už nemusí stačit

Ste­jně jako IT obor obec­ně, také AI jako její odnož, se vel­mi dynam­icky vyvíjí. Zatím­co dříve se pro­ces opíral přede­vším o ruční kon­trolu kódu, hledání známých chyb nebo využívání stat­ick­ých sken­erů, dnes AI umožňu­je rych­le­jší a kom­plexnější analýzu. ​„Dříve se zran­itel­nos­ti hledaly řekněme ​“hloupě a poma­lu”, napřík­lad ruční revizí kódu. Opro­ti tomu s AI je to ​“chytře a rych­le”. S ohrom­ným výpočet­ním výkonem v zádech dokáže hle­dat anomálie, prediko­vat zran­itel­nos­ti a snaží se výsled­ky zasa­dit do širšího kon­tex­tu,“ popisu­je Štěpán. 

Právě u Lin­uxu hra­je výz­nam­nou roli jeho otevřenost. Zdro­jový kód může ana­ly­zo­vat prak­ticky kdoko­liv, což spolu s nás­tu­pem AI vede k odhalování chyb, které v něk­terých pří­padech exis­to­valy i něko­lik let. AI tak podle Štěpá­na zrych­lu­je a zlevňu­je pro­cesy jako code review nebo bezpečnos­t­ní audi­ty, zároveň ale nenahrazu­je zkušenost člově­ka. Posouzení skutečného rizika, zasazení zran­itel­nos­ti do kon­tex­tu konkrét­ního prostředí a rozhod­nutí o dalším pos­tupu stále vyžadu­je odborný pohled člověka. 

AI zrych­lu­je celý pro­ces od objevení zran­itel­nos­ti až po vytvoření funkčního exploitu. ​„AI určitě urych­lí úsek mezi objevením zran­itel­nos­ti a proof of con­cept (PoC). Tím nepří­mo i nalezení funkčního exploitu, ale stále platí, že najít spolehlivý exploit bývá větši­nou nejtěžší část celého řetězce,“ vysvětlu­je. Zároveň upo­zorňu­je, že samot­né hod­no­cení závažnos­ti zran­itel­nos­ti musí vždy vycházet z konkrét­ního prostředí. Ste­jná chy­ba může před­stavo­vat rozdíl­né riziko podle toho, na jakém sys­té­mu se nachází, kdo k němu má příst­up a jak by ji mohl útočník reál­ně zneužít. 

Pro bližší pohled na prob­lematiku sto­jí za pozornost napřík­lad článek CVE-2025 – 37899. 

Příst­up k patchování se podle Štěpá­na musí lišit podle toho, zda jde o stan­dard­ní aktu­al­izace, nebo reak­ci na kri­t­ick­ou zran­itel­nost. Běžný patchovací cyk­lus probíhá pos­tup­ně od vývo­jových prostředí přes testování až po pro­duk­ci, aby bylo možné ověřit, že změny neovlivní fun­gování sys­témů. ​„Stan­dard­ní aktu­al­izace mají pevně nas­tavený pro­ces včet­ně testování a pos­tup­ného nasazování. U kri­t­ick­ých zran­itel­nos­tí ale musíme rozhodovat rych­le a zvažo­vat rizika z více stran. Někdy může být větším prob­lémem samot­ná zran­itel­nost, jindy nasazení opravy bez dostatečného otestování. Vždy pro­to záleží na konkrét­ní situaci a na tom, které riziko je v daný moment větší.“ “ popisu­je. Do budouc­na vidí jako jed­nu z cest pro kri­t­ické zran­itel­nos­ti takz­vaný live patch­ing, tedy možnost opravo­vat zran­itel­nost bez nut­nos­ti restar­tu oper­ačního sys­té­mu. Zároveň ale upo­zorňu­je, že v kom­plexním prostředí s řadou aplikací a závis­lostí jde o cíl, který přináší řadu tech­nick­ých výzev. 

V době, kdy AI umožňu­je rych­le­jší vznik sofistiko­vanějších útoků, je klíčové přede­vším zrych­lit schop­nost zran­itel­nos­ti co nejdříve iden­ti­fiko­vat a reago­v­at na ni. ​„Pokud nemo­hu zran­itel­nost oprav­it nebo mit­igo­v­at, musím min­imál­ně vědět, že se ji něk­do pokusil zneužít,“ říká. Právě v těch­to situ­acích hra­je důleži­tou roli mon­i­tor­ing založený napřík­lad na sle­dování konkrét­ních sys­té­mových volání. Zároveň upo­zorňu­je na prak­tické lim­i­ty, napřík­lad bezpečnos­t­ní stan­dardy typu CIS mohou vyžadovat neměn­nost audit­ních pravidel za běhu sys­té­mu, což může zna­me­nat nut­nost restar­tu i ve chvíli, kdy je potře­ba rych­le nasa­dit detekční mechanismy. 

AI by měla přinést přede­vším rych­le­jší reak­ci při iden­ti­fikaci nových hrozeb. Jeden ze součas­ných prob­lémů je, že tradiční sken­ery čas­to nedokážou nově objevené kri­t­ické zran­itel­nos­ti odhalit okamžitě, pro­tože jejich kon­trol­ní mech­a­nis­my je ještě neobsahují. 

Samot­né vyhod­no­cení rizika stále závisí přede­vším na kon­tex­tu konkrét­ního prostředí. ​„AI bych v této oblasti bral spíše jako rád­ce a posky­to­vatele inspirace, jak danou situaci neje­fek­tivněji vyřešit,“ říká. Aby dokáza­la správně určit pri­or­itu oprav, musela by mít k dis­pozi­ci detail­ní infor­ma­ce o infra­struk­tuře, což není vždy možné nebo žádoucí. Zároveň upo­zorňu­je, že orga­ni­zace budou stále častěji čelit situ­acím, kdy se objeví něko­lik kri­t­ick­ých zran­itel­nos­tí krátce po sobě, a pro­to je důležité být na podob­né scénáře připraven.

S nás­tu­pem tech­nologií jako MCP (Mod­el Con­text Pro­to­col) nebo AI agen­tů se podle Štěpá­na budou běžné admin­istrá­torské úkony, jako kon­fig­u­race nebo hledání chyb, pos­tup­ně stá­vat autom­a­ti­zo­vatel­ný­mi. V prostředí velkých a reg­ulo­vaných firem ale neb­ude hlavní výzvou jen samot­ná tech­nolo­gie, ale také otázky bezpečnos­ti, reg­u­lace a práce s daty. ​„Otáz­ka spíše bude, jestli firmy budou obec­ně chtít a moci do takové­to formy admin­is­trace a zabezpečení jít,“ říká. Budouc­nost tak podle něj ukáže, zda se AI agen­tová sprá­va infra­struk­tu­ry stane běž­nou součástí IT provozu, nebo narazí na lim­i­ty vycháze­jící z poža­davků reg­ulo­vaného prostředí či firem­ní kultury.