Spring Bootを使った業務アプリケーションを運用していると、避けて通れないのがサポート期限とEOS (End of Support / サポート終了) の問題です。
Spring BootやSpring Frameworkは、エンタープライズJavaアプリケーションで広く利用されています。一方で、サポート期限を過ぎたバージョンを使い続けると、脆弱性対応やセキュリティーパッチの入手が難しくなり、運用上のリスクが高まります。
この記事では、Spring Bootのサポート期限・EOSの考え方、サポート終了後のリスク、すぐに移行できない場合の対策について整理します。
この記事でわかること
- Spring Bootのサポート期限とは何か
- EOS後にどのようなリスクがあるのか
- Spring Frameworkや周辺ライブラリーも確認すべき理由
- 影響度の高いCVEの例
- Spring Bootのバージョンアップが難しい理由
- EOS対策の進め方
- すぐにバージョンアップできない場合の選択肢
- IBM Library Support for Open-Sourceによる対策
Spring Bootのサポート期限とは
Spring Bootには、バージョンごとにサポート期間があります。
Spring Bootのサポート状況は、Spring公式サイトで確認できます。
https://spring.io/projects/spring-boot#support
Spring Bootのサポート期限を考える際には、以下もあわせて確認する必要があります。
- Spring Bootのバージョン
- Spring Frameworkのバージョン
- Javaのバージョン
- Spring Security / Spring Cloud
- Tomcat、Jackson、Netty、Hibernateなどの依存ライブラリー
- 商用サポートや延長サポートの有無
Spring Bootは単体のライブラリーではなく、多数の依存関係を含むアプリケーション基盤です。そのため、Spring Boot本体だけでなく、周辺ライブラリーの脆弱性対応も含めて考える必要があります。
Spring BootがEOSになると何が問題か
Spring BootがEOSになると、主に以下のような問題があります。
1. セキュリティー修正を受けられなくなる
最も大きな問題は、脆弱性が見つかった場合に修正を受けられなくなることです。
Spring Boot本体だけでなく、以下のような依存ライブラリーにも脆弱性が見つかる可能性があります。
- Spring Framework
- Spring Security
- Spring Cloud
- Apache Tomcat
- Jackson
- Netty
- Hibernate
- Logback
Spring Bootのバージョンが古いままだと、これらの依存関係も古い状態に固定されやすくなります。
2. 脆弱性対応が難しくなる
脆弱性情報がCVEとして公開された場合、サポート中のバージョンであれば修正リリースが提供される可能性があります。
しかし、EOSを迎えたバージョンでは、公式の修正が提供されない場合があります。
その結果、以下のような対応が必要になります。
- 依存ライブラリーだけを個別に上げる
- アプリケーション全体をバージョンアップする
- WAF、IDS/IPS/IDPS、ネットワーク制限、該当機能の無効化などにより、一時的にリスクを低減する
- 自社で影響調査や検証を行う
- 商用サポートを検討する
特に業務システムでは、ライブラリーのバージョンを1つ上げるだけでも動作検証や回帰テストが必要になります。
3. 監査・コンプライアンス上の指摘を受けやすくなる
サポート終了済みのOSSを本番環境で使い続けている場合、セキュリティー監査やコンプライアンス確認で指摘されることがあります。
例えば、以下のような観点です。
- サポート終了済みOSSを利用していないか
- 深刻度の高い脆弱性が未対応のまま残っていないか
- パッチ提供元が明確か
- 脆弱性対応の証跡を残せるか
- 移行計画があるか
「今動いているから大丈夫」ではなく、リスクを説明できる状態にしておくことが重要です。
影響度の高いCVEの例
Java / Spring 周辺エコシステムでは、過去に影響度の高いCVEが複数公開されています。
| CVE | 対象 | 影響例 | 深刻度 |
|---|---|---|---|
| CVE-2022-22965 | Spring Framework | Spring4Shellとして知られるRCE脆弱性。特定条件下でリモートコード実行につながる可能性 | CVSS 9.8 Critical |
| CVE-2022-22947 | Spring Cloud Gateway | Gateway Actuatorエンドポイントが有効・公開・未保護の場合に任意コード実行につながる可能性 | CVSS 10.0 Critical |
| CVE-2024-38821 | Spring Security（WebFluxアプリケーション） | WebFluxで静的リソースに認可ルールを適用している場合、特定条件下で認可バイパスが発生する可能性 | CVSS 9.1 Critical |
| CVE-2024-22259 | Spring Framework |
UriComponentsBuilderによるURL解析とホスト検証の条件次第でOpen RedirectやSSRFの可能性 |
CVSS 8.1 High |
| CVE-2024-53677 | Apache Struts | ファイルアップロード処理の不備によりパストラバーサルやRCEにつながる可能性 | CVSS 9.8 Critical |
| CVE-2020-25638 | Hibernate ORM | JPA Criteria APIとSQLコメント利用条件によりSQLインジェクションの可能性 | CVSS 7.4 High |
これらの例から分かるように、Spring Bootアプリケーションのリスクは、Spring Boot本体だけで決まるわけではありません。
Spring Framework、Spring Security、Spring Cloud、Tomcat、Hibernateなどの依存ライブラリーも確認する必要があります。また、同じJavaアプリケーション資産の中でStrutsなどを併用している場合は、それらのサポート状況やCVE対応もあわせて確認する必要があります。
Spring Bootのバージョンアップが難しい理由
EOS対策として最も自然なのは、サポート中のバージョンへアップグレードすることです。
しかし、業務アプリケーションでは簡単ではありません。
特にSpring Boot 2.xから3.xへの移行では、以下の変更が大きな影響を与えます。
-
javax.*からjakarta.*への変更 - Spring Framework 6系への移行
- Java 17以上への対応
- Spring Security設定の見直し
- HibernateやJPA周辺の変更
- 依存ライブラリーの互換性確認
- テストコードの修正
Spring Boot 3.0 Migration Guideでは、Spring Boot 3.0がJava 17以上を必須とし、Spring Framework 6.0を利用すること、依存関係のレビューやSpring Security 6への移行が必要になることが説明されています。
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide
そのため、Spring Boot 2.xから3.xへの移行は、単純にバージョン番号を書き換えるだけでは済まないケースがあります。
EOS対策の進め方：現状把握から移行計画まで
Spring BootのEOS対策では、まず現在の利用状況を把握し、そのうえで短期的なリスク低減策と中長期的な移行計画を分けて考えることが重要です。
Step 1：利用中のバージョンを棚卸しする
まず、アプリケーションで利用しているSpring Bootや関連ライブラリーのバージョンを確認します。
Mavenの場合：
mvn dependency:tree | grep spring
Gradleの場合：
./gradlew dependencies | grep spring
確認対象は、Spring Bootだけではありません。以下のような周辺ライブラリーや実行環境もあわせて確認します。
- Spring Boot
- Spring Framework
- Spring Security
- Spring Cloud
- Hibernate
- Tomcat
- Jackson
- Netty
- Logback
- Strutsなど、同一システム内で利用しているJava OSS
- Javaのバージョン
- アプリケーションサーバー
- ビルドツールやCI/CD環境
Spring BootはBOMによって多くの依存ライブラリーのバージョンを管理しています。そのため、単にSpring Boot本体のバージョンだけを見るのではなく、アプリケーション全体の依存関係として確認することが重要です。
Step 2：サポート状況と既知の脆弱性を確認する
次に、利用しているライブラリーが現在もサポート対象か、既知の脆弱性が存在するかを確認します。
確認観点の例は以下です。
- OSSとしてのサポートが継続しているか
- EOS日はいつか
- 商用サポートや延長サポートがあるか
- 公開済みの脆弱性情報（CVE）があるか
- 修正バージョンが提供されているか
- 自社環境が影響条件に該当するか
脆弱性の確認には、以下のようなツールを利用できます。
- OWASP Dependency-Check
- GitHub Dependabot
- Snyk
- Trivy
- SBOM生成ツール
ただし、脆弱性が検知されたからといって、該当ライブラリーだけを単純に上げればよいとは限りません。
Spring BootのBOMで管理されているバージョンとの整合性や、アプリケーション全体の動作確認が必要です。また、CVEによっては、ライブラリーを利用しているだけでは影響を受けず、特定の設定や利用方法が条件になる場合もあります。
Step 3：影響度を評価する
検出された脆弱性情報（CVE）やEOS対象のライブラリーについて、実際にどの程度のリスクがあるかを整理します。
影響度の評価には、CVSS（Common Vulnerability Scoring System） のスコアを参考にできます。
CVSSは脆弱性の深刻度を数値化する指標で、0から10の範囲で示されます。
ただし、CVSSスコアが高いからといって、必ずしも自社環境で直ちに重大な影響があるとは限りません。実際のリスクは、アプリケーションの構成や公開範囲、利用している機能によって変わります。
例えば、以下のような観点で評価します。
- CVSSスコアはどの程度か
- インターネットから到達可能なシステムか
- 該当する機能やエンドポイントを利用しているか
- 認証なしで攻撃可能か
- 回避策や設定変更でリスクを下げられるか
- 業務影響が大きいシステムか
- 監査やコンプライアンス上の指摘対象になるか
CVSSによる客観的な深刻度と、自社環境における実際の影響条件をあわせて確認することで、「すぐに対応すべきもの」と「計画的に対応すべきもの」を分けやすくなります。
Step 4：短期対策と中長期対策を分ける
EOS対策では、短期的なリスク低減策と中長期的な移行計画を分けて考えることが重要です。
短期対策の例：
- 重要CVEの影響有無を確認する
- WAFやネットワーク制限を適用する
- 該当機能やエンドポイントを無効化する
- 商用サポートや延長サポートを検討する
- SBOMを整備する
- セキュリティー部門や監査向けの説明資料を準備する
中長期対策の例：
- Spring Bootをサポート対象バージョンへ移行する
- Javaをサポート対象バージョンへ移行する
- Spring Security設定を見直す
-
javax.*からjakarta.*への移行を進める - テスト自動化を整備する
- CI/CDを見直す
- アプリケーション全体のモダナイゼーション計画を立てる
短期対策はあくまで暫定対応です。最終的には、サポート対象バージョンへの移行を計画的に進めることが重要です。
Step 5：移行完了までのリスク低減策を検討する
業務アプリケーションでは、Spring BootやJavaのバージョンアップに数か月以上かかることもあります。
特に、Spring Boot 2.xから3.xへの移行では、Java 17以上、Spring Framework 6、Jakarta EEへの対応が必要になるため、単純なライブラリー更新では済まないケースがあります。
そのため、現実的には以下の2つを並行して進める必要があります。
- 中長期的には、サポート対象バージョンへの移行を進める
- 短期的には、移行完了までのセキュリティーリスクを下げる
この「移行までの期間をどう守るか」という観点で、商用サポートや延長サポートは有効な選択肢になり得ます。
サポートが終了している場合の選択肢
Spring BootやSpring Frameworkがサポート終了した場合、主な選択肢は以下です。
選択肢1：サポート対象バージョンへ移行する
メリット：
- 公式の修正を受けられる
- 新しいJavaやライブラリーに対応できる
- 長期的な保守性が高まる
- 将来の脆弱性対応がしやすくなる
デメリット：
- 移行工数が大きい
- テスト範囲が広い
- 互換性問題が発生する可能性がある
- Javaやアプリケーションサーバーの更新も必要になる場合がある
サポート対象バージョンへの移行は、セキュリティーと保守性の観点では最も望ましい対策です。
一方で、業務アプリケーションでは、Spring BootやJavaのバージョンアップがアプリケーション全体、ビルド環境、テスト、運用手順、関連システムに影響することがあります。
そのため、計画としては正しくても、すぐに実行できないケースがあります。
選択肢2：一時的な緩和策を取る
すぐにバージョンアップできない場合は、WAFや侵入検知・防御システム（IDS/IPS/IDPS）、ネットワーク制限、該当機能の無効化、管理エンドポイントの非公開化、アクセス制限などにより、一時的にリスクを下げる方法があります。
メリット：
- 短期的に実施しやすい
- 緊急対応として有効な場合がある
- システム停止を避けながらリスクを下げられる可能性がある
デメリット：
- 根本対策ではない
- すべての脆弱性に対応できるわけではない
- 継続的な監視が必要になる
例えば、特定のCVEが「特定のエンドポイントが公開されている場合に影響する」ものであれば、エンドポイントの無効化やアクセス制限が短期的な緩和策になることがあります。
ただし、これはあくまで暫定対応です。ライブラリー自体がサポート終了している場合、今後新たな脆弱性が見つかっても、継続的に修正を受けられるとは限りません。
選択肢3：商用サポート・延長サポートを利用する
もう1つの選択肢が、商用サポートや延長サポートを利用する方法です。
業務システムでは、サポート終了が近い、またはすでにサポート終了したOSSを使っていることが分かっても、すぐに移行できるとは限りません。
例えば、以下のような状況です。
- Spring Boot 2.xから3.xへの移行に時間がかかる
- Java 8からJava 17以上への移行が必要になる
-
javax.*からjakarta.*への変更影響が大きい - 外部システム連携が多く、回帰テストに時間がかかる
- StrutsやHibernateなど、他のJava OSSも同時に古いまま残っている
このような場合、単に「すぐに最新化する」と決めるだけでは不十分です。
現実的には、次の2つを並行して進める必要があります。
- 中長期的には、サポート対象バージョンへの移行を進める
- 短期的には、移行完了までのセキュリティーリスクを下げる
商用サポートや延長サポートは、バージョンアップの代替ではありません。
あくまで、移行までの時間を確保しながら、CVE対応や監査上の説明をしやすくするためのリスク管理手段として考えるのが適切です。
このような背景で検討できる選択肢の1つが、IBM Library Support for Open-Sourceです。
IBM Library Support for Open-Sourceとは
IBM Library Support for Open-Sourceは、コミュニティーサポートが終了したOSSライブラリーを利用し続けるお客様に対し、IBMがセキュリティー維持を支援するサポートサービスです。
以下のJava OSSライブラリーを対象に、CVE対応を中心としたセキュリティー修正を提供します。
- Spring
- Struts
- Hibernate
この修正は、以下のような主要なエンタープライズJava環境で稼働するアプリケーションに適用することが可能です。
- WebSphere Application Server
- WebSphere Liberty
- JBoss EAP
- Tomcat
- WebLogicなど
特に、Java 8環境や古いJava OSSライブラリーを利用している業務アプリケーションでは、最新化に時間がかかることがあります。
IBM Library Support for Open-Sourceは、そのような環境に対して、移行完了までの期間にセキュリティーリスクを下げるための選択肢として位置づけられます。
対象バージョンやサポート範囲などの詳細は以下のドキュメントを参照してください。
IBM Library Support for Spring
https://www.ibm.com/docs/ja/ils-spring?topic=overview
IBM Library Support for Struts
https://www.ibm.com/docs/ja/ils-struts?topic=overview
IBM Library Support for Hibernate
https://www.ibm.com/docs/ja/ils-hibernate?topic=overview
まとめ
Spring Bootのサポート期限・EOSは、単なるバージョン管理の問題ではありません。
サポート終了後のSpring Bootを使い続ける場合、以下のようなリスクがあります。
- セキュリティー修正を受けられない
- 脆弱性対応が難しくなる
- 監査・コンプライアンスで指摘される
- 将来の移行コストが増える
- 古いJava環境に依存し続ける
また、Spring BootアプリケーションのリスクはSpring Boot本体だけで決まるものではありません。
Spring Framework、Spring Security、Spring Cloud、Tomcat、Hibernateなど、周辺コンポーネントも含めて確認する必要があります。さらに、同一システム内でStrutsなどの古いJava OSSを併用している場合は、それらのサポート状況やCVE対応もあわせて確認する必要があります。
理想的には、サポート対象バージョンへ計画的に移行することが望ましいです。
しかし、業務アプリケーションでは、すぐにSpring BootやJavaのバージョンアップができないケースもあります。その場合は、移行までの期間をどう安全に運用するかが重要です。
商用サポートや延長サポートは、バージョンアップそのものの代替ではありません。しかし、移行完了までの期間にセキュリティーリスクを下げ、CVE対応や監査上の説明をしやすくするための手段になり得ます。
IBM Library Support for Open-Sourceは、Spring Boot、Spring Framework、Struts、Hibernateなど、対象となるJava OSSライブラリーに対して、セキュリティー更新やCVE対応を支援する選択肢です。
「今すぐ移行できないが、サポート終了後のセキュリティーリスクは下げたい」という場合は、Spring Bootのバージョンアップ計画とあわせて、延長サポートや商用サポートの活用も検討してみてください。
参考リンク
-
Spring Support Policy
https://spring.io/support-policy/ -
Spring Boot Supported Versions
https://github.com/spring-projects/spring-boot/wiki/Supported-Versions -
Spring Boot Support
https://spring.io/projects/spring-boot#support -
Spring Boot 3.0 Migration Guide
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide -
IBM Library Support for Open-Source
https://www.ibm.com/jp-ja/products/library-support-for-open-source -
IBM Library Support for Spring
https://www.ibm.com/docs/ja/ils-spring?topic=overview-licensing -
IBM Library Support for Struts
https://www.ibm.com/docs/ja/ils-struts?topic=overview -
IBM Library Support for Hibernate
https://www.ibm.com/docs/ja/ils-hibernate?topic=overview