Agentní AI a patch cyklus Javy: proč čtvrtletní záplatování nestačí
Podle Azul útočníci stále častěji používají AI agenty k hledání, řetězení a zneužívání zranitelností a i zranitelnost s nízkým hodnocením lze během hodin spojit s dalšími do funkčního útoku. Google ve zprávě M-Trends 2026 zatím rok 2025 nepovažuje za rok, kdy by průniky byly přímým důsledkem AI. Směr je ale jasný: času na reakci ubývá a AI ho může ubírat dál.
Java v tom není výjimkou. A většina podnikových Java prostředí je pořád nastavená na svět, ve kterém bylo několik týdnů na záplatování v pořádku.
Tři čísla, která to shrnují
- −7 dní: průměrnou dobu do zneužití odhaduje M-Trends 2026 na −7 dní. Zneužití tedy běžně začíná dřív, než vyjde oprava. Údaj se týká zranitelností obecně, ne přímo Javy.
- 43 dní: medián doby do úplné nápravy zranitelností z katalogu CISA KEV (od detekce, medián za organizaci), podle Verizon DBIR 2026. O rok dříve to bylo 32 dní.
- +20 %: složený čtvrtletní růst počtu zranitelností v OpenJDK za poslední dva roky, podle analýzy Azul nad čtvrtletními vydáními od října 2024 do října 2026.
Útočníci zrychlují, záplatování se zpomaluje a zranitelností přibývá. Tenhle rozdíl se nedá dohnat tím, že se bude pracovat víc. Je potřeba změnit, co a jak se nasazuje.
Proč Java záplaty tak často čekají
Podle Azul většina firem, ať už za podporu platí, nebo ne, dostává čtvrtletní kumulativní aktualizace OpenJDK. Ty obsahují bezpečnostní opravy spolu se stovkami dalších změn. Podle záznamů Azul od roku 2020 víc než 20 % těchto aktualizací obsahovalo regrese, které bránily jejich včasnému nasazení.
Provozní tým pak stojí před nepříjemnou volbou:
- Nasadit čtvrtletní aktualizaci a riskovat funkční nebo výkonnostní dopad na aplikace.
- Vrátit ji zpět a zůstat vystavený možnému útoku.
Měsíční Critical Security Patch Updates (CSPU) to samy o sobě neřeší, pokud jsou postavené na stejné čtvrtletní aktualizaci, která regresi obsahuje. Podle Azul pak firma nemůže takovou záplatu nasadit, dokud se regrese neopraví, a to v době, kdy AI podle Azul snižuje čas i dovednosti potřebné ke zneužití nově zveřejněné zranitelnosti.
CPU, PSU a CSPU: v čem je rozdíl
| Typ aktualizace | Co obsahuje | Riziko regrese |
|---|---|---|
| PSU (plná čtvrtletní) | Bezpečnostní opravy a stovky dalších změn | Vyšší |
| CPU (security-only čtvrtletní) | Jen bezpečnostní opravy, postavené na vydání z předchozího čtvrtletí | Minimální |
| CSPU (měsíční) | Bezpečnostní opravy nad aktuálním CPU | Minimální |
| Mimo plán | Opravy kritických zranitelností mezi plánovanými vydáními | Podle obsahu |
Základní myšlenka je jednoduchá: oddělit bezpečnostní opravy od všeho ostatního. Když aktualizace obsahuje jen bezpečnostní opravy, je změn k ověření mnohem méně a lze ji nasadit rychleji. Ostatní změny se mohou testovat bez časového tlaku.
Postup ve čtyřech krocích
Takhle to podle Azul vypadá s aktualizacemi Security-only, Stability-first™:
- Zmapujte, co máte. Nelze záplatovat to, o čem nevíte. Azul JVM Inventory ukazuje z živých dat dodavatele, verzi, úroveň záplat i aplikaci, kterou každé JVM obsluhuje, včetně krátce žijících kontejnerů, které periodické skeny často minou.
- Záplatujte produkci hned. Security-only CPU a CSPU nasadíte hned po vydání. Azul je vydává typicky do hodiny od zveřejnění.
- Testujte svým tempem. Plné čtvrtletní aktualizace si můžete tři měsíce ověřovat v předprodukci, než se nebezpečnostní změny dostanou do produkce.
- Pokryjte zero-day. Na kritické zranitelnosti zveřejněné mimo plán jsou aktualizace mimo cyklus a podpora 24×7 se SLA.
Přechod z Oracle JDK nebo jiné distribuce přitom nemusí být velký projekt. Azul Core i Azul Prime jsou ověřené TCK a postavené na OpenJDK, takže jde obvykle o výměnu binárek, ne o změnu kódu. Security-only aktualizace jsou k dispozici pro všechny aktuální LTS verze (8, 11, 17, 21 a 25) a backportované bezpečnostní opravy i pro Javu 6 a 7.
Konkrétní příklad najdete v článku o případu eMudhra z října 2026.
Audity a regulace
PCI DSS i DORA výslovně požadují řízení zranitelností a záplat a v Evropě to samé téma pokrývá NIS2. Audity podle SOC 2 a kontroly IT v rámci SOX se k tomu často dostávají nepřímo. Prakticky to znamená umět doložit tři věci:
- přehled o nasazených verzích softwaru,
- včasnou nápravu známých zranitelností Javy v termínech, které si stanovíte,
- zdokumentovanou historii záplat a data o používání pro audit.
Spoléhat na to, že systém za firewallem audit obstojí, je stále riskantnější, protože útočník se často dostane dovnitř jinudy a pak hledá přesně takto opomíjené systémy.
Kde začít
Než začnete cokoli měnit, potřebujete vědět, kde stojíte. Proto s Azul nabízíme bezplatný Java Security Assessment: už za několik dnů můžete vidět, které verze mají expozici KEV, které jsou pod aktuální úrovní CPU a kde běží verze po konci podpory. Podrobně ho popisujeme v tomto článku.
Vyžádejte si bezplatný assessment. Je zdarma, nezávazný a vše vyřídíte s námi.
Je vaše Java připravená na útoky v éře AI?
Zařídíme vám bezplatný Java Security Assessment. Už za několik dnů můžete vidět, které verze Javy jsou nejrizikovější, kde chybí záplaty a co řešit jako první.
- Zdarma a bez závazků
- Výsledek už za několik dnů
- Stačí přehled verzí a počtů, anonymně
