Всем привет!

Меня зовут Михаил Поливаха, я технический лидер проекта Axelix. Недавно мы перешагнули отметку 10 000 загрузок в месяц. Мы сами разрабатываем инструмент для работы со Spring-приложениями, поэтому вопросы релизных циклов, поддержки версий и обновления зависимостей для меня не абстрактная теория. С ними приходится сталкиваться и в роли пользователя Spring, и в роли разработчика Open Source-проекта.

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

Ну ладно, бывает. Сейчас поднимем patch-версию, заберём исправление и поедем дальше. Для того patch-релизы и существуют, верно?

Открываете Maven Central, смотрите на свою линию Spring Boot, а следующего номера там нет. И, что гораздо хуже, уже не будет.

Допустим, у Вас Spring Boot 3.5.16. Это последний открытый релиз линии 3.5, он вышел 25 июня 2026 года. Следующий номер, 3.5.17, в календаре Spring есть, но помечен как enterprise. То есть патч существует. Проблема в том, что Ваш пайплайн смотрит на Maven Central, а туда этот патч не попадёт.

В этот момент почти обязательно находится коллега, который говорит: «Так 3.5 же LTS! Как это патча не будет?»

И вот тут, друзья, начинается самое интересное. Потому что коллега одновременно и прав, и нет. Чтобы понять, почему так получилось, нам придётся разобраться сразу с тремя вещами: как работает Release Train, сколько на самом деле живёт Spring Boot в OSS и что в Spring вообще понимают под LTS. А уже после этого посмотрим, при чём здесь AI и почему в 2026 году даже сам релизный поезд Spring пришлось задержать из-за уязвимостей.

Начнём с мат. части, как я люблю это делать.

Release Train. Почему Вы обновляете не один Spring

Release Train это не какая-то особая версия продукта. Это договорённость о том, что набор проектов выходит совместно, по общему расписанию. Вы получаете не случайную коллекцию библиотек, а состав, вагоны которого подобраны друг под друга.

В случае Spring Boot это особенно важно. Когда Вы пишете приложение, Вы не собираете вручную Spring Framework, Spring Security, Spring Data и остальные проекты по одному. Обычно Вы подключаете Spring Boot, а он уже управляет согласованными версиями всего этого портфеля.

Поэтому, если SCA нашёл уязвимость, например, в Spring Framework, вопрос звучит не просто как «а есть ли новый Framework?». Намного важнее понять, в какой линии Spring Boot это исправление приедет Вам в приложение. Политика поддержки Spring устроена так же: сроки поддержки проекта привязаны к соответствующей линии Boot.

Новый major или minor Spring Boot обычно выходит дважды в год, в мае и ноябре. В описании поддерживаемых версий команда называет ориентир: четверг после третьего понедельника. Между этими поездами по необходимости выходят patch-релизы. Отдельного жёсткого правила «новый патч строго каждый первый вторник» тут нет.

Например, Spring Boot 4.0 в ноябре 2025 года привёз Spring Framework 7.0 и Spring Security 7.0. Следующий поезд, Boot 4.1 в июне 2026 года, привёз уже Security 7.1, а Framework остался на линии 7.0. И это нормально. У каждого проекта свой размер изменений, поэтому не обязательно каждый minor Boot означает новый minor каждого проекта внутри него.

Здесь заодно зафиксируем разницу, которая очень пригодится, когда сборка уже красная.

Переход с 4.1.1 на 4.1.2 это patch-обновление. По идее оно обратно совместимо, и именно такой апдейт Вы рассчитываете забрать незадолго до релиза. А вот переход с 4.0 на 4.1 это уже следующий minor, с новыми изменениями, deprecations и потенциально необратно совместимыми изменениями. Переход на следующий major тем более нельзя считать простой заменой одной цифры.

Важно! Поднимая minor, ожидайте, что что-то может отъехать и могут быть ломающие изменения - такое надо отдельно тестировать.

Теперь пару слов про поддержку и про расписание Release Train.

Год, и поезд ушёл

У релизной линий Spring Boot есть открытое окно поддержки, в течение которого исправления публикуются в OSS. И это окно составляет примерно год. Обратите внимание: не три года, не всё время жизни major-версии, а примерно год на конкретную линию.

В политике поддержки сформулировано минимум 13 месяцев OSS-поддержки для minor Spring Boot. В wiki Boot встречается более мягкая формулировка про минимум 12 месяцев. Если посмотреть на опубликованный календарь, для текущих линий картина ближе к тринадцати: майская линия получает открытые патчи примерно до конца июня следующего года, ноябрьская примерно до конца декабря.

Смотрите, как это выглядит на практике:

  • Spring Boot 3.5 вышел в конце мая 2025 года, а OSS-поддержка закончилась 30 июня 2026 года.

  • Spring Boot 4.0, то есть новый major, вышел в конце ноября 2025 года, а его OSS-окно заканчивается 31 декабря 2026 года.

  • Spring Boot 4.1 вышел в июне 2026 года и открыт до 31 июля 2027 года.

Давайте сразу зафиксируем - 4.0 не получает никакого особенного открытого окна только потому, что в версии сменилась “первая цифра”. Для release train это такая же отдельная линия со своим ограниченным сроком жизни.

Постойте, но в политике же написано, что major поддерживается до трёх лет!

Написано. Только читается эта фраза иначе. Три года поддержки поколения не означают три года открытых патчей именно на 4.0. Чтобы оставаться внутри поддерживаемого поколения, Вам нужно вовремя пересаживаться на следующие minor-релизы: с 4.0 на 4.1, потом на следующий и так далее.

Окна соседних линий перекрываются примерно на полгода. Поэтому обычно одновременно OSS поддержку имеют сразу две линии, и у Вас есть время спокойно спланировать переход. Пропустили один поезд, то ещё можете успеть на следующий. Пропустили несколько, и бесплатного патча для Вашей линии уже нет.

Теперь возвращаемся к нашему 3.5.16. Никакой аномалии здесь нет. Линия 3.5 прожила своё открытое окно, и 3.5.16 стал последним OSS-релизом на Maven Central. Ожидать, что 3.5.17 появится там чуть позже, бессмысленно. Политика такого не обещает.

У обычной линии после завершения OSS есть ещё коммерческое окно, примерно до 25 месяцев с начала релиза. Например, у 4.0 оно продлится до 31 декабря 2027 года. Но эти сборки публикуются уже не на Maven Central, а в закрытом enterprise-репозитории. Для пайплайна, который умеет работать только с Central, этого коммерческого хвоста фактически не существует.

И вот здесь самое время вернуться к реплике коллеги про LTS.

Но у нас же LTS!

Строго говоря, последний minor release в рамках major-а называют LTS, например 3.5 или 2.7 - это “LTS” в терминлогии Spring. Проблема в том, что многие автоматически вкладывают в это слово смысл, который знаком им по Java. А это две разные истории.

У JDK feature релизы тоже выходят каждые шесть месяцев (в сентябре и в марте). Но среди них есть LTS-версии, например Java 21 и Java 25. Выбираете такую версию и годами получаете на неё патчи от своего вендора бесплатно, не переходя на каждый следующий feature-релиз.

Для понимания, Java 25 до сих пор имеет OSS поддержку, а Java 26 - уже нет. Поэтому в мире Java понятие LTS важно для всех. Non-LTS Java версии поддерживаются до следующей feature версии Java (22 поддерживается, пока не выйдет 23), а LTS гораздо дольше (даже без подержки вендора, с вендорами там своя история). Некому будет такие вот баги вам закрывать.

И вот именно эту модель люди часто переносят на Spring: «Мы сели на стабильную линию, её будут чинить, а мы спокойно забираем исправления».

Так вот в Spring OSS такого нет.

То, что в разговорах называют “Spring LTS”, это последний minor внутри большого поколения. Длинная поддержка у него действительно есть, но почти вся она приходится не на открытое OSS-окно, а на коммерческий хвост. В рамках РФ, насколько мне известно, кроме Axiom никто такую поддержку не предоставляет. Поправьте, если я не прав.

В феврале 2025 года Майкл Минелла отдельно описал это правило. До этого команда иногда продлевала поддержку последнего minor вручную, без общей гарантии. Именно поэтому Spring Framework 5.3 многие запомнили как классический LTS: линия появилась 31 октября 2020 года, а открытые релизы выходили до 31 августа 2024 года. Почти четыре года! Но Минелла прямо подчёркивает, что это было решение по конкретной линии, а не обещание на будущее.

К сожалению, многие люди из-за этого прецедента с Spring Boot 2.7 и Spring Framework 5.3 начали вкладывать в LTS смысл, которого никогда понятие “LTS” вообще не имело - я сам с этим встречаюсь регулярно.

Теперь гарантия выглядит иначе. Последний minor поколения получает пять дополнительных лет enterprise-поддержки. Вместе со стандартными окнами это даёт примерно семь лет жизни, но подавляющая часть этого срока коммерческая.

Сегодня под такое правило попадают, например, две линии Spring Boot:

  • 2.7: OSS закончился ещё 30 июня 2023 года, коммерческая поддержка продолжается до 30 июня 2029 года.

  • 3.5: OSS закончился 30 июня 2026 года, коммерческая поддержка продолжается до 30 июня 2032 года.

А вот 3.4 в этот клуб не входит. Его коммерческое окно заканчивается 31 декабря 2026 года. И 4.0 тоже не входит, несмотря на то, что это major. Пять дополнительных лет получит тот minor, который когда-нибудь станет последним в четвёртом поколении. На данный момент это ни 4.0, ни 4.1.

Короче, вывод: В Spring-е понятие LTS имеет смысл только в рамках Enterprise поддержки. Для обычных людей Spring LTS абсолютной такой же, как и non-LTS.

Коммерческие сборки сейчас распространяются как TrueSource Spring Enterprise. До этого использовалось название “Tanzu Spring”. Но суть не в вывеске. Суть в том, где лежит артефакт и на каких условиях Вы его получаете. Если открытое окно линии закончилось, исправление приходит в enterprise-репозиторий, а не на Central. С июня 2026 года подписчикам также доступны CVE-only сборки в день ноль, ещё до публичного advisory: в такой сборке есть исправление уязвимости без остального содержимого большого patch-релиза.

То есть коллега прав в том, что патчи на 3.5 будут выходить ещё долго. Но если под «будут» он имел в виду «мы бесплатно скачаем их с Maven Central», то уже неправ. Для OSS линия 3.5 закончилась 30 июня 2026 года. Длинный срок до 2032 года относится к коммерческой поддержке.

Казалось бы, теперь картина понятная. Следите за линией, вовремя переходите на следующий поезд, а если бизнес требует остаться, подключаете коммерческую поддержку. Но в 2026 году добавилась ещё одна проблема.

Теперь уже сам поезд не пришёл по расписанию… Что случилось?

Май 2026 года. Поезд задержали из-за CVE

Я уже писал, что Spring Boot release train должен был выходить раз в пол года - в мае и в ноябре.

И вот 1 июня Майкл Минелла написал, что майский Release Train сдвинули и сжали в окно с 8 по 14 июня. Причина была не в том, что кто-то не успел дописать новую фичу. Команде нужно было выпустить большой набор security-исправлений, и он не помещался в исходную дату.

В итоге Spring Boot 4.1.0 вышел 10 июня. Команда предпочла задержать поезд, а не копить уже подтверждённые CVE до следующего крупного окна в ноябре.

Чтобы понять масштаб происходящего, достаточно сравнить несколько цифр. Исторически команда получала около 6,5 новых security-отчётов в месяц. За весь 2024 год, по подсчёту SecurityWeek, было закрыто 22 уязвимости. За 2025 год ещё меньше, 16.

А потом начался 2026 год.

Только в марте сообщество прислало 55 CVE репорта! Из этой волны в апреле объявили 26 CVE. В том же апреле команда подключила собственное сканирование, и за месяц получила уже 482 отчёта по 65 проектам: 370 нашли внутренним сканированием и ещё 112 прислало сообщество. При этом 37% внутренних находок оказались дубликатами или не уязвимостями. В мае сообщество принесло ещё 72 отчёта.

Конечно, надо понимать, что 482 репорта это не 482 подтверждённые дыры и уж точно не 482 уязвимости в Вашем production. Отчёт ещё нужно разобрать, воспроизвести, обсудить с репортёром и только потом превратить в исправление и advisory. Но для команды поддержки нагрузка появляется уже на этапе очереди. Каждый такой отчёт требует времени человека, даже если в конце выяснится, что это дубликат.

Дальше была волна, которую заметили уже практически все пользователи сканеров. 20 августа 2026 года вышла большая пачка исправлений, в которой Sonatype насчитала 91 CVE. SecurityWeek писал, что к 24 августа за 2026 год в Spring закрыли больше 200 уязвимостей. Для сравнения, напомню: за весь 2025 год было 16.

Broadcom назвал июньский набор крупнейшей пачкой security-обновлений за 23 года истории Spring. А к концу августа сообщил, что за пять месяцев на поиск уязвимостей с помощью frontier-моделей ушло больше 12 миллиардов токенов.

Так в итоге, что с этим делает команда Spring?

AI помогает искать. Патчи по-прежнему пишут люди

Команда Spring не стала просто ждать, пока поток отчётов спадёт сам. Она подключила собственное сканирование, чтобы находить проблемы раньше внешних репортёров, и стала выпускать исправления большими скоординированными пачками. Если такая пачка не помещается в дату, двигается весь поезд. Именно это произошло в мае 2026 года.

При этом разбор отчётов и подготовка исправлений остаются на людях и Broadcom отдельно подчёркивает, что выпускаемый патч написан и проверен человеком. В качестве аргумента компания ссылается на исследование 1Password: из 6000 патчей, сгенерированных моделью, только 26% действительно устраняли уязвимость и при этом не ломали приложение.

На мой взгляд, разделение здесь вполне здравое. Отказываться от моделей при поиске потенциальных уязвимостей уже странно: они реально позволяют покрыть больший объём кода. Но автоматически выпускать сгенерированный diff в проект, который стоит в огромном количестве приложений, это совсем другой риск. Нашёл кандидата AI, отлично. Ответственность за исправление всё равно должен взять человек.

Для нас с Вами у этой истории есть две практические стороны.

С одной стороны, security-релизы стали крупнее и могут приехать не в Ваш удобный релизный четверг. Иногда обновлять придётся не одну библиотеку, а сразу часть портфеля.

С другой стороны, исправление распространяется по тем же правилам поддержки, о которых мы говорили выше. Открытая линия получает patch на Maven Central. Линия за пределами OSS-окна получает сборку в enterprise-репозиторий, иногда ещё и раньше публичного advisory в формате CVE-only. Появление нового CVE само по себе не открывает старую линию заново.

Команда при этом не обещает, что всё быстро вернётся к тихому 2025 году. Дублей становится больше, поэтому от пика апреля темп, вероятно, спадёт. Но до прежних 6,5 отчётов в месяц, по их оценке, он уже не вернётся. Планировать процесс обновлений из расчёта, что security-релизы будут редкими и маленькими, больше не стоит.

Возвращаемся к нашему красному пайплайну

Итак, релиз всё ещё ждёт, SCA всё ещё красный. Что теперь делать?

Первое, как я уже сказал, надо понимать, а поддерживается ли ещё наша линия в OSS. На начало ноября 2026 года расклад по основным линиям такой:

  • Spring Boot 4.1 открыт до 31 июля 2027 года. Если Вы уже на этой линии, следующие patch-релизы будут приезжать на Central.

  • Spring Boot 4.0 открыт до 31 декабря 2026 года. Сам по себе major не даёт более длинного OSS-окна. После этой даты останется коммерческая поддержка до 31 декабря 2027 года.

  • Spring Boot 3.5 в OSS больше не поддерживается. Коммерческий хвост до 30 июня 2032 года означает enterprise-репозиторий, а не Maven Central.

  • Spring Boot 3.4 теряет даже коммерческую поддержку 31 декабря 2026 года. Boot 2.7 остаётся только в платном хвосте до 30 июня 2029 года, а линии 3.0, 3.1, 3.2 и 3.3 уже завершились полностью.

И ещё раз про вагоны поезда. Если Вы используете Boot 4.0, Вас не спасает тот факт, что Spring Framework 7.0 в целом открыт до июля 2027 года. Эта линия Framework ещё нужна и Boot 4.1. Ваш Boot 4.0 после 31 декабря 2026 года новые открытые patch-релизы не получит.

Таким образом, развилка довольно короткая.

Если Ваша линия ещё открыта, забираете patch и, скорее всего, действительно выкатываете релиз без большой миграции. Если линия уже закрыта, есть два рабочих варианта: пересесть на поддерживаемый поезд либо получить исправление через коммерческую поддержку. А вот варианта «подождём, пока бесплатный патч сам появится на старой линии» у этого Release Train нет.

Поэтому версиями Spring Boot нужно управлять заранее, а не в момент, когда завтра релиз, а сегодня красный SCA. Переход на следующий minor лучше планировать как обычную инженерную работу, пока у Вас есть перекрытие окон поддержки. Иначе однажды выяснится, что выбирать приходится уже между срочной миграцией, покупкой enterprise-поддержки и релизом с известной уязвимостью. Набор, прямо скажем, так себе.

Если сервис один, его состояние видно по pom.xml или build.gradle. А если сервисов сорок, картина быстро перестаёт помещаться в голове: один уже на 4.1, другой сидит на 4.0 с дедлайном в декабре, третий остался на 3.5 без открытых патчей, а у четвёртого на 3.4 скоро закончится даже коммерческое окно.

Эту картину по всем сервисам собирает Spring Portfolio в Axelix. Мы сделали этот дашборд ровно для описанной выше ситуации: вместо ручного обхода десятков репозиториев Вы видите, какие версии Spring Boot и Spring Framework реально используют приложения, сколько приложений уже находятся за пределами OSS-поддержки и как они распределены по линиям 3.5.x, 4.0.x, 4.1.x и так далее.

Отдельно там есть шкала времени по каждой используемой линии: когда она вышла, когда заканчивается OSS-поддержка и сколько приложений на ней работает. Причём приложение считается поддерживаемым только в том случае, если открытые обновления ещё получают и Boot, и Framework. Помните наш разговор про вагоны одного поезда? Вот здесь эта связь видна уже не на абстрактной схеме, а на Вашем собственном парке сервисов.

Конечно, в этом плане Axelix не заменяет SCA и не выполняет миграцию за Вас. Он отвечает на другой вопрос, который лучше задать заранее: где следующий красный пайплайн ещё лечится обычным patch-релизом, а где открытого патча уже не будет.

Всем успехов!