Spring Boot 3.5: окончание Open Source поддержки

Нужна экспресс-оценка вашей Spring инфраструктуры?

Обратитесь к экспертам Axiom JDK: быстро определим версии Spring в эксплуатации, уровень риска, варианты действий и поможем запустить тестирование Axiom Spring на одном из сервисов.

Получить консультацию

Что изменится после 30 июня 2026

30 июня 2026 года заканчивается OSS-поддержка (open-source поддержка, публичные бесплатные обновления) Spring Boot 3.5. Эта версия Spring Boot перестанет получать бесплатные публичные обновления, включая исправления безопасности.

Важно: даты прекращения OSS-поддержки разные для каждой версии. Например, у Spring Boot 3.4 open-source поддержка закончилась 31 декабря 2025, у версии 3.3 - 30 июня 2025.

Если вы не знаете, какие версии Spring Boot используются в каждом из ваших сервисов, это уже риск. А если еще и не знаете кого спросить, то у вас риск - в квадрате.

Раньше можно было оставаться на версии и получать публичные обновления. Теперь без подписки обновления означают миграцию на следующую версию.

Что изменилось в релизном цикле Spring Boot - Spring перешёл на более короткий релизный цикл*:

• Новая минорная или мажорная версия выходит раз в 6 месяцев, чаще всего в мае и ноябре
• Минорная версия получает open-source поддержку в течение 12 месяцев: публичные обновления и исправления безопасности доступны ограниченное время.
• После окончания open-source поддержки публичные бесплатные исправления не выпускаются, расширенная поддержка становится коммерческой.
• Официальная коммерческая поддержка Spring (Spring Enterprise Subscription от Tanzu by Tanzu, Broadcom - ex VMware) для компаний в России недоступна из-за санкционных ограничений.

Итого: новые версии выходят регулярно, а open-source поддержка каждой версии ограничена по времени. После её окончания исправления уходят в коммерческий контур.

Для многих компаний в России это означает простую развилку: либо регулярно мигрировать на новую версию, либо искать альтернативный продукт или сервис.стал регулярным. 

*Дополнительный материал

Что именно изменилось в релизах Spring Framework и Spring Boot и почему это стало проблемой для российских компаний.

Читать разбор нового релизного цикла Spring

Какие риски появятся, если не подготовиться

1) Уязвимости без патчей

Новые CVE будут появляться, а ваша версия после окончания open-source поддержки уже не получит публичных исправлений. Это прямое увеличение вероятности взлома/проникновения/инцидента.

Почему риск высокий:

• Популярные библиотеки всегда под пристальным вниманием хакеров
  Spring массово используется, поэтому способы атаки быстро становятся “типовыми”: их автоматизируют и распространяют,  ими пользуются даже скрипт-кидди — атакующие, которые берут готовые инструкции и инструменты и запускают атаки “по шаблону”.
• Spring-сервисы часто доступны из интернета
  Многие приложения на Spring публикуют API и веб-интерфейсы наружу. Если появляется уязвимость, её можно пытаться эксплуатировать удалённо,находя доступные сервисы и проверяя их на известные слабые места.

2) Рост вероятности инцидентов в эксплуатации

С ростом техдолга увеличивается риск цепочки “обновили одну зависимость и сломали сервис”. Без поддержки вы чаще остаетесь один на один с проблемой. 

3) Непредсказуемая стоимость миграции

Чем позже вы начнёте, тем больше несовместимостей накопится. Стоимость может включать в себя цену простоя сервиса из-за успешной атаки. Миграция превращается из плановой работы в аварийный проект.

4) Риски для критичных систем

Для систем с повышенными требованиями к безопасности (КИИ*, ЗОКИИ, ИСПДн*) отсутствие обновлений быстро становится организационной и регуляторной проблемой.

*КИИ — критическая информационная инфраструктура: системы и сети, сбой или атака на которые может повлиять на безопасность, экономику и устойчивость государства и отраслей.

**ЗОКИИ — значимые объекты критической информационной инфраструктуры: те объекты КИИ, которым присвоена категория значимости, и для них действуют более жёсткие требования по защите.

***ИСПДн — информационная система персональных данных: любая система, где обрабатываются персональные данные и которая должна соответствовать требованиям по их защите.

5) Срыв планов релизов продукта

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

Чек-лист готовности за 5 минут

Отметьте каждый пункт и поставьте баллы: 0 баллов — нет, 1 балл — частично, 2 балла — да.
Максимум — 20 баллов.

1. Мы точно знаем версии Spring Boot в  промышленной эксплуатации по всем сервисам.
2. У нас есть список сервисов на Spring и ответственный за каждый из них.
3. Мы проводим установку обновлений безопасности в считанные дни.
4. Сборка воспроизводима: версии зависимостей зафиксированы и управляются осознанно (без “случайных” обновлений).

Да, “плавающие” версии иногда могут автоматически подтянуть исправление уязвимости, но это делает изменения неконтролируемыми и повышает риск несовместимостей и инцидентов в эксплуатации.

1. У нас регулярно происходит анализ зависимостей и артефактов на уязвимости с помощью инструментов SAST, DAST.
2. У нас есть план что делать и время, чтобы его реализовать, когда заканчивается open-source поддержка нашей версии (не “в целом 3.x”).
3. Есть тестовый контур, близкий к к боевой среде. Ключевые сценарии покрыты автотестами и ручными тест-кейсами. 
4. У нас есть всё, чтобы обновляться регулярно и безопасно: процессы, тесты и контуры для быстрых исправлений уязвимостей. Если идём “по релизному циклу” Spring Boot, то готовы мигрировать на новые минорные версии каждые ~6 месяцев, при этом обновления безопаности ставим чаще, по мере выхода фиксов.
5. Поддерживается и обновляется не только Spring, но и JDK, контейнерная база, встроенный контейнер сервлетов.
6. Мы обновляли версию Spring хотя бы на одном сервисе за последние 12 месяцев.

Интерпретация результатов

• 0–7 баллов: высокий риск. Скорее всего, вы узнаете о проблеме в момент инцидента.
• 8–14 баллов: средний риск. Процессы есть, но дедлайн и CVE все равно догонят.
• 15–20 баллов: хороший уровень. Осталось закрепить стратегию поддержки и план обновлений.

Как быстро понять, какая версия у вас в эксплуатации

• Посмотреть логи: в стартовых логах приложения или внутри артефакта, который реально развёрнут (JAR или контейнерный образ).
• Сверить с исходниками: убедиться, что pom.xml или build.gradle соответствует тому артефакту, который уехал в боевую среду (через CI/CD теги, версии, чексумму).
• Зафиксировать и поддерживать актуальность: записать версию в инвентаризацию сервисов и регулярно обновлять данные, чтобы  вопрос “какая версия” не превращалась в эпический квест.

Что делать дальше

• Если у вас 14 баллов и меньше: начните с инвентаризации и определения версий в эксплуатации.
• Дальше выберите стратегию обновлений: либо вы регулярно переходите на новые версии Spring Boot по релизному циклу, либо получаете обновления безопасности с меньшим риском поломок, например, через Axiom Spring, где закрытие CVE делается точечно и предсказуемо, без необходимости постоянно “бежать” на самую свежую версию фреймворка.
• Быстрый практичный шаг: пилот на одном сервисе, чтобы измерить реальную цену перехода и риски.

Два пути решения

Путь 1: Бегать за обновлениями

Вы регулярно мигрируете на новые версии Spring Boot по релизному циклу и  используете сервисы на поддерживаемой open-source версии.

Что для этого потребуется:

• Постоянно выделенный ресурс команды на обновления.
• Регулярные окна релизов и тестирования.
• Автоматизированные регрессионные тесты и близкий к боевой среде тестовый контур.
• Готовность быстро чинить несовместимости.

Риск этого пути: если у вас меньше 15 баллов в чек-листе, обновления часто превращаются в затяжной проект. Между релизами вы остаётесь с растущим списком уязвимостей.

Путь 2: Долгосрочная поддержка через Axiom Spring

Axiom Spring — это поддерживаемая поставка Spring с долгосрочной поддержкой и улучшениями. В реестре Российского ПО. В составе стек российских компонентов: Axiom JDK и Libercat Embedded.

Что вы получаете:

• Предсказуемые обновления безопасности без гонки за версиями.
• Может единый поставщик (java spring и контейнера) и понятный процесс получения исправлений.
• Пилот на одном сервисе, чтобы сравнить риски до и после.
• Дорожную карту перехода без остановки разработки.
  
  

Гонка за релизами: скрытая цена и риски

Если вы выбираете путь регулярных миграций, но при этом не знаете версии в эксплуатации, не фиксируете зависимости и не успеваете ставить обновления быстро, вы почти гарантированно придёте к одному из финалов:

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

Хотите пройти экспресс-оценку и получить план действий?

Напишите нам: мы проведем экспресс-аудит процесса разработки с использованием Spring, покажем, где вы уже за пределами open -source поддержки, предложим варианты снижения рисков и организуем тестирование Axiom Spring на выбранном сервисе.

Экспресс-аудит процесса разработки с использованием Spring и пилот Axiom Spring для ваших сервисов

Сделаем оценку рисков и предложим безопасную стратегию поддержки. Запустим пилот и измерим результат на вашем типовом сервисе.

Получить консультацию и пилот