Звіт Azul за 2026 рік про розрив у готовності до вразливостей ШІ показує, що підприємства відстають від загроз ШІ з усуненням вразливостей

У Звіті про розрив у готовності до вразливостей ШІ за 2026 рік компанії Azul виявлено невідповідність між швидкістю, з якою, на думку керівників служб безпеки, зловмисники, озброєні ШІ, можуть діяти, і часом, потрібним їхнім організаціям для розгортання виправлень. В опитуванні 300 керівників служб безпеки зі США 69% відповіли, що зловмисники можуть створити працездатний експлойт упродовж трьох днів, тоді як 44% зазначили, що їхнім організаціям потрібно чотири дні або більше, аби усунути критичну вразливість у всіх виробничих системах.

Найразючіший висновок звіту стосується досвіду, про який респонденти повідомили у зв’язку з такими затримками: 85% заявили про інцидент, імовірний інцидент або ситуацію, коли наслідків ледь вдалося уникнути через повільне встановлення виправлень. Цей показник відображає досвід, про який повідомили респонденти, а не незалежно підтверджений рівень витоків даних, — і він не доводить, що причиною цих подій був ШІ.

Дослідження, замовлене Azul і проведене Censuswide, охоплює організації зі значним використанням Java. Його ширший висновок стосується операційної діяльності: виявлення вразливості — це лише початок. Виправлення має пройти тестування, потрапити до вразливих систем і усунути ризик у всьому середовищі, яке команди можуть бачити не повністю.

Два годинники, які не синхронізовані

В опитуванні окремо розглянуто очікування керівників щодо зловмисників і спроможність їхніх організацій розгортати виправлення:

• 69% вважають, що зловмисники, озброєні ШІ, можуть створити експлойт за три дні або швидше; зокрема, 22% вважають, що на це потрібно менш як 24 години.
• 56% зазначають, що можуть розгорнути критичне виправлення в усіх виробничих системах упродовж трьох днів: 13% — менш ніж за 24 години, а 43% — за один-три дні.
• 44% потрібно більше часу: 32% — від чотирьох до шести днів, а 12% — ще довше.

Це розподіл відповідей в опитуванні, а не вимірювання того, як зловмисники змагаються з конкретними організаціями на шляху до експлуатації тих самих вразливостей. Ця різниця дає підстави непокоїтися щодо готовності, але її не слід сприймати як точний триденний період уразливості для кожного підприємства.

Такий самий дисбаланс помітний і на одноденному порозі: 22% очікують, що зловмисники діятимуть так швидко, тоді як лише 13% кажуть, що їхня організація може розгорнути виправлення в цей проміжок часу. Водночас 59% визнають, що інструменти атак на основі ШІ підвищують ризик, але не змінили свого підходу до безпеки.

Тестування — вагома причина затримок

У 58% опитаних організацій тестування оновлень середовища виконання Java додає до циклу встановлення виправлень чотири дні або більше. Серед них 36% повідомляють про чотири-шість днів, а 22% — про тиждень або довше. Ще 33% повідомляють про один-три дні, а 9% — про менш ніж 24 години. Жоден респондент не сказав, що тестування пропускали.

Зміни середовища виконання можуть вплинути на багато застосунків, тож тестування має практичну мету: оновлення безпеки, яке порушує роботу критично важливої служби, створює ще одну операційну проблему. У звіті стверджується, що обсяг оновлень посилює це навантаження, оскільки повні квартальні випуски OpenJDK можуть містити не пов’язані з безпекою зміни разом із виправленнями вразливостей.

Окремо Azul проаналізувала 26 квартальних оновлень OpenJDK за понад шість років і класифікувала шість із них як такі, що спричинили серйозну регресію. Цей показник у 23% — оцінка випусків самим постачальником, а не результат опитування про те, як часто може перестати працювати застосунок окремого клієнта.

Серед найчастіше згадуваних перешкод для швидшого встановлення виправлень 44% називають масштабне тестування, 40% — складність або застарілість уражених систем, а 36% — обмежену видимість відомих вразливостей. Затримки з випуском виправлень постачальниками згадали 25%. Така картина свідчить, що значна частина труднощів з усуненням проблем пов’язана з внутрішнім процесом розгортання в самому підприємстві.

Повідомлення про інциденти та прогалини в інвентаризації слід тлумачити по-різному

П’ятдесят п’ять відсотків повідомляють про підтверджений інцидент, пов’язаний із повільним встановленням виправлень, а 53% — про ситуацію, коли наслідків ледь вдалося уникнути. Респонденти могли вибирати кілька відповідей, тому ці показники перетинаються, і їх не слід додавати. Ширший показник у 85%, винесений у заголовок, також охоплює ймовірні інциденти.

Опитування не доводить, що всі ці події стосувалися вразливостей Java. Учасники працюють в організаціях, де широко використовують Java, однак дослідження містить запитання як про встановлення виправлень у програмному забезпеченні загалом, так і про середовища виконання Java зокрема.

Ще одна проблема — інвентаризація. Лише 19% зазначають, що щонайменше 90% середовищ виконання Java у їхніх виробничих системах мають найновіший рівень виправлень безпеки. Це означає, що 81% не досягають цього порога; це не означає, що в 81% узагалі немає актуальних середовищ виконання. Близько одного з п’яти респондентів кажуть, що актуальними є не більш як половина їхніх середовищ.

Окремо 51% визнають, що мають лише часткове або обмежене уявлення про критично важливі середовища виконання Java, зокрема вбудовані, застарілі та некеровані екземпляри. Виявити вразливе середовище виконання всередині упакованого застосунку або контейнера може бути складніше, ніж знайти інсталяцію з централізованим керуванням. Виправлення не усуне ризик у системі, якої процес розгортання взагалі не охоплює.

Що технологія Azul додає до цієї дискусії

Пропозиція Azul щодо оновлень безпеки обмежує окремі випуски виправленнями безпеки на попередньо стабілізованій базі OpenJDK. Компанія надає щоквартальні, цільові щомісячні та позапланові оновлення, прагнучи зменшити обсяг супутніх змін, які підприємствам потрібно оцінювати під час розгортання термінового виправлення.

Це вужче технічне втручання, ніж усунення потреби в контролі змін. Обмеження змін у коді може звузити обсяг перевірки, однак перевірки, специфічні для застосунків, відповідальність за розгортання та підготовка до відкату залишаються важливими. Azul є спонсором звіту й продає продукти, спрямовані на розв’язання проблем, які в ньому вимірюються.

Інструменти компанії для обліку Java та виявлення вразливостей допомагають розв’язати іншу частину завдання: визначити середовища виконання, версії та рівень уразливості, щоб зіставити нове повідомлення про вразливість із системами, яких вона стосується. У звіті немає контрольованого порівняння, яке б показувало, наскільки покращилися б результати опитаних організацій після впровадження цих продуктів.

«Наше дослідження показує, що керівники з безпеки розуміють загрозу: проблема вже не в обізнаності, а у виконанні», — сказав Scott Sellers, співзасновник і генеральний директор Azul.

Перетворення наміру встановлювати виправлення на вимірюваний процес

На наступний рік 32% називають швидше й частіше встановлення виправлень своєю головною стратегією зменшення вразливості, тоді як 26% віддають перевагу кращому обліку програмного забезпечення та середовищ виконання. Ще 17% вважають пріоритетом виявлення загроз і реагування на них, а не швидше встановлення виправлень.

Дослідження свідчить про доцільність відстежувати весь шлях від повідомлення про вразливість до її усунення: які системи вона зачіпає, хто за них відповідає, яке тестування потрібне та чи справді виправлення потрапило у виробниче середовище. Кінцевий термін корисний лише тоді, коли команди можуть перевірити виконання робіт у всіх відповідних системах і середовищах.

Дані зі США отримано в ході польового дослідження, проведеного 3–7 серпня 2026 року серед керівників із безпеки в організаціях, де працює щонайменше 1 000 співробітників і Java/JVM широко використовуються у виробничому середовищі. Це самооцінки респондентів із визначеної групи, а не перепис усіх підприємств і не безпосереднє вимірювання розробки експлойтів.

У повному тексті Звіту про прогалину у сфері вразливостей ШІ за 2026 рік докладно викладено результати та методологію. Найочевидніший висновок полягає в тому, що швидкість встановлення виправлень і видимість середовищ виконання потрібно покращувати одночасно: швидке виправлення мало що дає, якщо організація не може визначити всі розгортання, яких воно стосується, або підтвердити, що оновлення було встановлено.