Отчет 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%. Эти данные показывают, что значительная часть трудностей с устранением уязвимостей связана с внутренними процессами установки обновлений в самих компаниях.

Данные об инцидентах и пробелах в инвентаризации требуют раздельного рассмотрения

О подтвержденном инциденте, вызванном медленной установкой исправлений, сообщили 55% респондентов, а о ситуации, когда последствия удалось предотвратить в последний момент, — 53%. Респонденты могли выбирать несколько вариантов ответа, поэтому эти показатели частично пересекаются, и складывать их нельзя. Более широкий показатель в 85%, вынесенный в заголовок, также включает предполагаемые инциденты.

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

Еще одна проблема — инвентаризация. Лишь 19% респондентов сообщили, что не менее 90% используемых в производственной среде сред выполнения Java обновлены до последнего уровня исправлений безопасности. Это означает, что у 81% доля обновленных сред ниже указанного порога, но не то, что у 81% вообще нет актуальных сред выполнения. Около одного респондента из пяти сообщили, что обновлена половина их сред или меньше.

Кроме того, 51% признают, что имеют лишь частичное или ограниченное представление о критически важных средах выполнения Java, в том числе встроенных, устаревших и неуправляемых экземплярах. Обнаружить уязвимую среду выполнения внутри упакованного приложения или контейнера может быть сложнее, чем выявить централизованно управляемую установку. Исправление не устранит уязвимость в системе, до которой процесс установки обновлений не доходит.

Как технологии Azul дополняют эту дискуссию

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

Это более узкое техническое вмешательство, чем отказ от необходимости управлять изменениями. Сокращение объема изменений в коде может уменьшить масштаб проверки, однако проверки с учетом особенностей конкретного приложения, ответственность за развертывание и подготовка к откату по-прежнему важны. Azul выступает спонсором отчета и продает продукты, предназначенные для решения проблем, которые в нем оцениваются.

Инструменты Azul для учета Java-сред и выявления уязвимостей охватывают другую сторону рабочего процесса: они помогают определить среды выполнения, версии и степень подверженности угрозам, чтобы сопоставить новую информацию об уязвимости с затронутыми системами. В отчете нет контролируемого сравнения, которое показывало бы, насколько улучшились бы результаты опрошенных организаций после внедрения этих продуктов.

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

Как превратить намерение устанавливать исправления в измеримый процесс

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

Исследование указывает на необходимость отслеживать весь путь от раскрытия информации об уязвимости до ее устранения: какие системы затронуты, кто за них отвечает, какие испытания необходимы и действительно ли исправление попало в промышленную среду. Срок полезен только в том случае, если команды могут проверить выполнение задачи во всем соответствующем парке систем.

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

В полном отчете о разрыве в сфере уязвимостей ИИ за 2026 год подробно изложены результаты и методология. Из него ясно следует, что необходимо одновременно ускорять установку исправлений и повышать видимость сред выполнения: быстрое исправление мало поможет, если организация не может выявить каждое затронутое развертывание или подтвердить, что обновление до него дошло.