Российские фирмы столкнулись с трудностью: международная поддержка Spring Boot для местных клиентов недоступна, а публичные обновления имеют временные ограничения. В исследовании Axiom JDK (имеется в распоряжении IT Speaker), в котором участвовали свыше 300 Java-разработчиков, 55,8% не указали срок использования текущих версий без обновлений, 61,2% признают важность продленной поддержки, однако реально готовы ее рассматривать только 26,9%.
Большинство опрошенных представляют крупный бизнес (71,1% – компании с численностью от 1000 сотрудников) и финансовый сектор (56,1%). Эксперты отрасли рассказали IT Speaker о трудностях, с которыми сталкиваются компании при миграции, и о причинах, по которым процесс обновления часто откладывается.
Наиболее распространенной остается версия Spring Boot 3.x – у 83,7% участников, 2.x – у 21,2%, 4.x – у 26%. В июне 2026 года прекратится выпуск патчей для версии 3.5, а международная поддержка для российских компаний фактически завершена после ухода VMware и Broadcom. При этом 53,5% респондентов не знали дату окончания поддержки, а 55,8% не установили предельный срок эксплуатации. Переход на 4-ю версию уже осуществляется у 18,9% компаний, 41% планируют это сделать, 23,7% еще не приняли решение. 32,7% организаций одновременно используют несколько версий фреймворка, что усложняет контроль безопасности и миграцию. Инициаторами обновлений чаще выступают разработчики (63,5%), а не службы информационной безопасности (36,5%).
Руководитель разработки GitFlic Эдуард Тихомиров пояснил IT Speaker, что переход со Spring Boot подразумевает обновление до нового Spring Framework, смену основной версии Java, согласование множества сопутствующих библиотек, которые всегда отстают, а также внутренних стартеров и платформенных сборок.
«Для системы из сотен сервисов регрессионное тестирование – это месяцы, а не спринт. Чтобы начать такую работу, миграцию необходимо поставить выше продуктового бэклога, хотя она не приносит ни одной новой функции. Пока нет уязвимости CVE, система “работает”, и в обсуждении приоритетов обновление всегда оказывается в невыгодном положении», – отметил он.
По его словам, старая версия Spring использует устаревшую Java, старый сервлет-контейнер и устаревший рантайм, и каждый месяц задержки увеличивает разрыв, который затем придется закрыть одним резким переходом в экстренном режиме. Кроме того, уязвимости, выявленные в коммерческих ветках, могут не доходить до публичных релизов, а подписчики коммерческой поддержки зачастую получают исправления до их публичного раскрытия. «Вы узнаете об уязвимости одновременно с атакующим, но без готового решения», – предостерег он.
Согласно исследованию, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости. Лишь 26,9% опрошенных рассматривают коммерческую поддержку, хотя 61,2% видят в ней пользу. Наиболее востребованы: исправления безопасности (29,8%), помощь с миграцией (23,4%), SLA (20,5%) и консультации (20,2%). Эдуард Тихомиров отметил, что ценность коммерческой поддержки оценивает инженер, а решение о новой строке OPEX принимают службы ИБ, CIO и отдел закупок.
«Признание полезности – это инженерное суждение; готовность рассматривать – это вопрос бюджета, на который у респондента чаще всего нет полномочий», – пояснил он. Кроме того, пока для каждой системы не установлен допустимый срок эксплуатации без обновлений, обоснование покупки оказывается неясным, а альтернатива выглядит бесплатной, так как затраты на самостоятельный бэкпорт скрыты в уже выплачиваемых зарплатах. Директор по продукту Axiom JDK Илья Сазонов также подчеркнул, что для каждой промышленной системы необходимо заранее определить срок эксплуатации версии, миграционный план и источник исправлений.
Тихомиров также добавил, что интеграция процессов безопасности в разработку – это наиважнейшая задача. Все начинается с инвентаризации: SBOM должен автоматически генерироваться при каждой сборке. Далее следует политика для каждой системы: целевая версия, допустимый срок эксплуатации без публичных обновлений, дата запланированного перехода и назначенный владелец процесса с SLA на реакцию.
В GitFlic, по его словам, специально разработали систему отслеживания каждого релиза: «Перед деплоем как специалист по безопасности, так и сам разработчик видят, какие уязвимости появились, и могут устранить их вовремя, а не постфактум. Ключевое здесь – информация поступает в момент принятия решения о релизе, а не в отчете через неделю». Цель, по его словам, заключается в том, чтобы появление критической CVE стало рутинной операцией с известным временем реакции, а не кризисом.
Ранее компания Right line, занимающаяся разработкой ПО для финансового сектора, и поставщик российской платформы Java Axiom JDK завершили тестирование своих продуктов на соответствие требованиям информационной безопасности платформы цифрового рубля. Успешные испытания позволяют рекомендовать решения Right line для использования в защищенной российской Java-среде.
Удаленка навсегда: три уровня ИТ-трансформации
