Zpráva Azul za rok 2026 odhaluje, že firmy nestíhají opravovat zranitelnosti a zaostávají za hrozbami AI

Zpráva o rozdílu mezi hrozbami AI a schopností opravovat zranitelnosti za rok 2026 od společnosti Azul odhaluje nesoulad mezi rychlostí, kterou bezpečnostní lídři připisují útočníkům využívajícím AI, a dobou, kterou jejich organizace potřebují k nasazení oprav. V průzkumu mezi 300 bezpečnostními lídry v USA uvedlo 69 %, že útočníci dokážou vytvořit funkční exploit do tří dnů, zatímco 44 % uvedlo, že jejich organizace potřebují k opravě kritické zranitelnosti v celém produkčním prostředí čtyři dny nebo déle.

Nejvýraznějším zjištěním zprávy je zkušenost, kterou respondenti s těmito prodlevami spojují: 85 % uvedlo incident, podezření na incident nebo situaci, kdy k incidentu málem došlo, a to v důsledku pomalého nasazování oprav. Tento údaj zachycuje zkušenosti respondentů, nikoli nezávisle ověřenou míru úspěšných útoků, a nedokládá, že tyto události způsobila AI.

Výzkum si objednala společnost Azul a provedla jej společnost Censuswide. Zaměřuje se na organizace, které ve značné míře využívají Javu. Jeho hlavní sdělení se týká provozní praxe: odhalením zranitelnosti práce teprve začíná. Oprava musí projít testováním, dostat se do dotčených systémů a odstranit riziko v celém prostředí, které týmy nemusejí mít plně zmapované.

Dvoje hodiny, které nejdou sladit

Průzkum odděluje očekávání lídrů ohledně útočníků od schopnosti jejich vlastních organizací nasazovat opravy:

• 69 % se domnívá, že útočníci využívající AI dokážou vytvořit exploit za tři dny nebo méně; 22 % z nich odhaduje, že jim to zabere méně než 24 hodin.
• 56 % uvádí, že dokáže nasadit kritickou opravu v celém produkčním prostředí do tří dnů: 13 % za méně než 24 hodin a 43 % za jeden až tři dny.
• 44 % potřebuje více času: 32 % uvádí čtyři až šest dnů a 12 % ještě déle.

Jde o rozložení odpovědí v průzkumu, nikoli o měření toho, jak útočníci závodí s konkrétními organizacemi v případě stejných zranitelností. Tento rozdíl vzbuzuje obavy ohledně připravenosti, neměl by se však vykládat jako přesně třídenní doba vystavení riziku pro každou firmu.

Stejný nepoměr se projevuje i při hranici jednoho dne: 22 % očekává, že útočníci budou postupovat tak rychle, zatímco jen 13 % uvádí, že jejich organizace dokáže v této lhůtě nasadit opravu. Zároveň 59 % přiznává, že nástroje pro útoky využívající AI zvyšují jejich vystavení riziku, ale bezpečnostní přístup tomu dosud nepřizpůsobily.

Testování významně prodlužuje dobu nasazení oprav

Testování aktualizací běhového prostředí Java prodlužuje cyklus nasazení oprav o čtyři a více dnů u 58 % organizací zapojených do průzkumu. Do této skupiny patří 36 %, které uvádějí čtyři až šest dnů, a 22 %, které uvádějí týden nebo déle. Dalších 33 % uvádí jeden až tři dny a 9 % méně než 24 hodin. Žádný respondent neuvedl, že by se testování vynechávalo.

Změny běhového prostředí mohou ovlivnit řadu aplikací, takže testování má praktický důvod: aktualizace zabezpečení, která naruší fungování kritické služby, vytváří další provozní problém. Zpráva tvrdí, že k této zátěži přispívá i rozsah aktualizací, protože úplná čtvrtletní vydání OpenJDK mohou vedle oprav zranitelností obsahovat také změny, které se zabezpečením nesouvisejí.

Azul samostatně vyhodnotil 26 čtvrtletních aktualizací OpenJDK vydaných v průběhu více než šesti let a šest z nich označil za příčinu závažné regrese. Údaj 23 % představuje hodnocení vydání dodavatelem, nikoli odhad z průzkumu, jak často může dojít k narušení aplikace konkrétního zákazníka.

Mezi nejvýznamnějšími překážkami rychlejšího nasazování oprav uvádí 44 % rozsáhlé testování, 40 % složitost nebo stáří dotčených systémů a 36 % omezený přehled o známých zranitelnostech. Prodlevy při vydávání oprav ze strany dodavatelů uvedlo 25 %. Z těchto výsledků vyplývá, že značná část problémů s nápravou vzniká přímo v procesu nasazování v podniku.

Hlášení incidentů a mezery v inventarizaci je třeba posuzovat odděleně

Padesát pět procent respondentů uvádí potvrzený incident, který přičítají pomalému nasazování oprav, a 53 % situaci, kdy k incidentu málem došlo. Respondenti mohli vybrat více odpovědí, takže se tyto údaje překrývají a nelze je sčítat. Širší údaj 85 %, uváděný v titulku, zahrnuje také podezření na incident.

Průzkum nedokládá, že se všechny tyto události týkaly zranitelností Javy. Respondenti pracují v organizacích, které ve velké míře využívají Javu, výzkum se však vedle otázek týkajících se konkrétně běhových prostředí Java zabývá také aktualizacemi softwaru obecně.

Další obtíž představuje inventarizace. Pouze 19 % uvádí, že alespoň 90 % jejich produkčního prostředí s běhovým prostředím Java používá nejnovější úroveň bezpečnostních oprav. To znamená, že 81 % této hranice nedosahuje; neznamená to, že 81 % nemá žádná běhová prostředí aktualizovaná. Přibližně každý pátý respondent uvádí, že aktuální je nejvýše polovina jeho prostředí.

Samostatně 51 % respondentů přiznává, že má pouze částečný nebo omezený přehled o kritických běhových prostředích Java, včetně těch vestavěných, zastaralých a nespravovaných. Najít zranitelné běhové prostředí uvnitř zabalené aplikace nebo kontejneru může být obtížnější než identifikovat centrálně spravovanou instalaci. Oprava nemůže odstranit riziko v systému, do kterého proces nasazování vůbec nedosáhne.

Jak technologie Azul přispívá k této diskusi

Nabídka bezpečnostních aktualizací společnosti Azul omezuje vybraná vydání na bezpečnostní opravy založené na dříve stabilizované verzi OpenJDK. Společnost poskytuje čtvrtletní, cílené měsíční a mimořádné aktualizace s cílem omezit množství nesouvisejících změn, které musí podniky posuzovat při nasazování naléhavé opravy.

Jde o užší technický zásah než o odstranění potřeby řízení změn. Omezení změn kódu může zúžit rozsah ověřování, stále však záleží na kontrolách specifických pro danou aplikaci, odpovědnosti za nasazení a přípravě na návrat k předchozí verzi. Azul je sponzorem zprávy a prodává produkty zaměřené na problémy, které zpráva měří.

Její nástroje pro inventarizaci Javy a vyhledávání zranitelností řeší druhou stránku tohoto procesu: identifikaci běhových prostředí, verzí a míry vystavení riziku, aby bylo možné nové zveřejnění zranitelnosti přiřadit k dotčeným systémům. Zpráva neobsahuje kontrolované srovnání, které by ukazovalo, o kolik by se situace zkoumaných organizací zlepšila po zavedení těchto produktů.

„Náš výzkum ukazuje, že bezpečnostní lídři hrozbě rozumějí: problémem už není povědomí, ale realizace,“ uvedl Scott Sellers, spoluzakladatel a generální ředitel společnosti Azul.

Jak proměnit záměr aktualizovat v měřitelný proces

Pro příští rok označuje 32 % respondentů za hlavní strategii snižování míry vystavení riziku rychlejší a častější instalaci bezpečnostních oprav, zatímco 26 % dává přednost lepší inventarizaci softwaru a běhových prostředí. Dalších 17 % upřednostňuje detekci hrozeb a reakci na ně před rychlejší instalací oprav.

Výzkum doporučuje sledovat celý proces od zveřejnění zranitelnosti až po její nápravu: kterých systémů se týká, kdo za ně odpovídá, jaké testování je potřeba a zda se oprava skutečně dostala do produkčního prostředí. Termín je užitečný jen tehdy, když týmy mohou ověřit dokončení v celém příslušném prostředí.

Zjištění z USA vycházejí z terénního šetření provedeného ve dnech 3.–7. srpna 2026 mezi bezpečnostními lídry v organizacích s nejméně 1 000 zaměstnanci a významným využitím Javy/JVM v produkčním prostředí. Jde o odpovědi, které sami respondenti poskytli v rámci vymezené populace, nikoli o úplné sčítání podniků ani o přímé měření vývoje exploitů.

Celá Zpráva o nedostatcích v oblasti zranitelností AI za rok 2026 podrobně popisuje zjištění i metodiku. Její nejzřetelnější závěr je, že rychlost instalace oprav a přehled o běhových prostředích je třeba zlepšovat současně: rychlá oprava má omezený přínos, pokud organizace nedokáže identifikovat všechna dotčená nasazení nebo ověřit, že se k nim aktualizace skutečně dostala.