Российские компании рискуют остаться без обновлений Spring Boot

Российские компании столкнулись с проблемой: международная поддержка 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-среде.