EOLとは？OSSのEOLを放置するリスクと対応すべきポイントを解説

EOLとはEnd of Lifeの略で、セキュリティの更新やバージョンアップの停止をはじめ、サポートの提供が終了することを意味します。ライフサイクルの終了とも言われます。

昨今、アプリケーション開発でよく使われるOSS（オープンソースソフトウェア）にもEOLは設定されています。EOLを迎えると、そのソフトウェアのメンテナンスが終了するため、実際に影響を受ける脆弱性が発見された場合も調査や修正パッチも提供されません。適切にEOLの管理をしていないと、セキュリティリスクの増大につながるため、EOL対策が必要です。

本記事では、EOLとは何かを知りたい方に向けて、基本からわかりやすく解説します。OSSのEOLを放置すると高まるリスクや、EOLに向けて対応すべきポイントを解説します。

EOL（End of Life）とは

ここではEOLの意味やEOS、EOSL、EOEとの違いを説明します。

EOLの意味

EOLはソフトウェアの分野で、製品のメンテナンスのサービス終了を意味します。EOLを過ぎたものを継続して利用し続けた場合、サポートが受けられないため、様々なリスクを企業にもたらすことが考えられます。

例えば、セキュリティ上のリスクです。脆弱性が発見された際に、セキュリティパッチが適応されず、その脆弱性を悪用した者によるサイバー攻撃を受ける可能性があります。また、重大なバグへの修正対応ができずシステム障害を引き起こす危険性もあります。この結果、情報漏えいや不正アクセスなどの被害につながることもあり得るのです。

OSSがEOLを迎えることで、セキュリティ上のリスクだけではなく、以下のようなリスクももたらします。

• ソフトウェアの互換性（新しいハードウェア・ソフトウェアとの互換性に問題が生じることがある）
• パフォーマンス低下（システムの動作が遅くなる、もしくは完全にシステムが停止する場合がある）
• コスト増加（古いシステムの修理・復旧・メンテナンス・セキュリティに長時間を要する、膨大な費用がかかる恐れがある）
• コンプライアンス違反（セキュリティパッチ管理などコンプライアンス要件を満たすことが難しくなる）

サポートが終了した製品を使い続けた結果、トラブルが発生した際は自社のリソースで、もしくは外注して解決しなければなりません。具体的には、バージョンアップや後継製品、同レベルの機能を有する他社製品へのリプレイス（置き換え）が必要となるケースもあります。

EOLに対応しなければ、脆弱性や欠陥、不具合を抱えたまま業務を運用しなければなりません。何らかの問題が生じ、通常業務に支障をきたす可能性があります。

OSS（オープンソースソフトウェア）のようなソフトウェアでは、EOLは、バージョンアップやパッチ提供の終了を指します。

生産中止や生産終了に伴うサポート終了は、OSSに関係ないと思う方もいるかもしれません。

しかし、OSSも開発者側が開発中止を決定・実行したら、アップデートは基本的にされません。今までのサポートを受けられなくなります。

さらに、脆弱性の公表もされなくなり、EOLバージョンのOSSに脆弱性があっても調査・修正が行われることはありません。

EOS、EOSL、EOEとの違い

サポート終了を意味するEOLと混同しやすい用語には、EOSやEOSL、EOEがあります。EOLとは違う意味をもつ用語もあるため、注意が必要です。

EOS・EOSL・EOEの意味の違いは、このとおりです。

• EOS（End Of Sales）：生産や販売の終了
• EOSL（End Of Service Life）：サポートサービスの終了
• EOE（End Of Engineering）：技術的サポートの終了

いずれの用語も、何かしらのサポートが終了する点では似ていますが、終了するサポートの内容が違います。

EOLとほぼ同じ意味で使われるのがEOSLです。ハードウェアとソフトウェアのサポート終了日があるネットワーク機器を例に挙げると、ハードウェアのみのサポート終了がEOSL、ハードウェアとソフトウェアのサポート終了がEOLです。

ベンダーにより、各用語が指し示す内容が異なるケースがあります。自社で導入している製品・サービスのシステム構成を把握し、それぞれのEOS、EOL、EOSL、EOEの内容・期日を調べておきましょう。

OSSを活用したアプリケーションを開発する企業で、これらの情報を収集し、事前に対応していないと、セキュリティリスクの増大をはじめ、様々な企業問題を招く可能性があります。

EOLが設定される理由

世の中の需要変化や技術進化に応じて、メーカーは製品やサービスを更新し続けることが欠かせません。

EOLが設定される理由は、新しい機能や技術を開発し続けるためです。

OSSのようなソフトウェアは、新機能のリリースをはじめ、多様な目的のもとバージョンアップがなされます。しかし、開発リソースには限界があります。

古いバージョンの改修を繰り返しながら、製品・サービスを長期間にわたって提供するのは費用がかかります。ライフサイクルを事前に決め、新しいものを作る方がトータルコストを抑えられる点も、EOLが設定される理由のひとつです。

EOLを迎えるとどうなる？高まる3つのリスク

EOLを迎えると、以下の3つのリスクが生じます。

1. 不具合があっても修正されない
2. セキュリティ更新が止まりサイバー攻撃に弱くなる
3. 互換性に問題が起きる

EOLを迎えたソフトウェアの使用を続けて起きるリスクを明確にすると、今後のEOL対応に活用できます。

1. 不具合があっても修正されない

EOLを迎えたソフトウェアは、不具合が発生しても修正されません。

EOLは、サポートの終了を意味します。サポートが終了するため、不具合が原因のトラブルに見舞われても、基本的にサポートを受けられません。

EOLを迎えてもなお、ソフトウェアの使い続けたことで起きたトラブルは、自社での解消が求められます。外注することも可能ですが、EOL対応に費用が発生します。

この結果、以下のような問題が起こることがあります。

• 独力で対応するため、修復に時間がかかり通常業務に影響がでる
• 修復を依頼すると、高額な修理コストがかかる

EOLを迎えた後に、開発者側のサポートを全く受けられないとは限りません。問題を解消するための対応をしてもらえることもあります。しかし、サポートしてもらえるかは製品の契約内容によります。サポートが受けられるかは保証されているわけではなく、確実ではないことに注意が必要です。

2. セキュリティ更新が止まりサイバー攻撃に弱くなる

EOLを迎えると、セキュリティの更新が止まり、サイバー攻撃に弱くなります。サイバー攻撃を受けるリスクを高め、被害を受ける可能性が上昇するとも言い換えられます。

EOLを迎えた製品は、重大な脆弱性をはじめ不具合が検出されても、セキュリティの更新プログラムの適用が行われません。

危険性を抱えたまま使用することになり、サイバー攻撃に対して防御力がない環境に陥ります。これは常に高いセキュリティリスクに晒されている状態です。

万が一、企業の重要な情報が改ざんされたり、流出したりすると、企業の社会的な信用が低下しかねません。また、突然アプリケーションが利用できなくなり、業務の継続が難しくなるケースも考えられます。

3. 互換性に問題が起きる

EOLを迎えたソフトウェアは、新製品のソフトウェアやハードウェアとの互換性に問題が起きる場合があります。

サポートが終了し、プログラムの更新も止まるため、最新の機能が搭載されていません。直近でリリースされているOSやハードウェア環境では動作しない、もしくは正常に動作しない可能性が高まります。

例えば、脆弱性を修正するためのプログラムであるセキュリティパッチが正常に動作しないようなケースです。

互換性の問題によりアプリケーションが機能せず、通常業務や顧客との取り引きをはじめ、企業運営にも影響を及ぼすでしょう。

EOLを迎えたソフトウェアを残し続けると、最新の状態を保っているものとの間に互換性の問題が起きるのが3つ目のリスクです。

EOLに向けて対応すべきこと

EOLに向けて対応すべきことは、大きく分けると2つあります。

• 使用している製品のEOL情報を把握する
• EOLを迎える製品の入れ替え計画を作成する

EOLの対応をすることで、EOLを迎えた製品を使用するセキュリティリスクの回避につながります。

使用している製品のEOL情報を把握する

まずは自社が保有するソフトウェアやハードウェアなどのすべての製品を洗い出し、それぞれのEOL情報を把握します。

EOLに対応するには、すべてのEOL情報の取得と整理が欠かせません。EOL情報は、メーカーをはじめ、製作側がウェブサイトで発表している情報が参考になります。

情報を体系立てて整理し、部署やチーム内の各担当者で容易に共有できるようにしておくと、EOLの見落としを防止できます。

しかし、EOL情報を自社で管理する業務は、エクセルを使ってできますが難しいと感じる方もいるでしょう。

自社のオペレーションに関連するソフトウェアすべてを把握しようとすると、膨大な時間がかかります。

EOLを迎える製品の入れ替え計画を作成する

EOL情報を把握したら、EOLを迎える製品の入れ替え計画を作成します。以下の4つが、入れ替え計画のポイントです。

• 計画する内容1.製品の機能性
• 計画する内容2.既存の環境との互換性
• 計画する内容3.余裕をもった移行期間の準備
• 計画する内容4.入れ替えの費用の確認

あらかじめ考える内容をおさえると、入れ替え計画を適切に進められます。

計画する内容1.製品の機能性

入れ替え計画を立てるときは、まず、入れ替え先の製品に求める機能性を決めます。

どのような機能をもった製品が必要かが明確でなければ、目的から定めましょう。入れ替える目的と、目的に準じた機能は、以下の3つに分けられます。

既存環境の維持に重きを置くか、さらに上を目指してスペックの高い製品を選ぶ か、目的に応じて、EOLの入れ替え計画は変わります。

いずれの製品を選定する際も、トラブルなくオペレーションを実行するために必要な機能の確認は

重要です。

計画する内容2.既存の環境との互換性

EOLを迎える製品を入れ替える際は、既に導入している製品との間に互換性があるか、確認が必要です。

互換性に問題があると、正常にシステムが動作しないことがあります。その結果、障害が発生したりサービスが停止したりして、業務に深刻な影響を与えかねません。

EOLを迎える製品の入れ替えを計画するときは、発生しうる影響を調査・検討し、入れ替えても問題なく機能するか確かめます。

また、入れ替えた後の挙動の確認や検証も重要です。エンドユーザーに協力を仰ぎ、パイロットテストを実施するよう計画を立てておくと、細かいポイントまで検証できます。

計画する内容3.余裕をもった移行期間の準備

ソフトウェアの入れ替えを検討するときは、余裕をもった移行期間の設定と計画が重要です。

入れ替えは、一朝一夕で対応できるものではありません。入れ替え計画は、以下のポイントをおさえて作成します。

入れ替える製品の規模と見合った移行期間を準備する
作業開始から入れ替えまでの計画全体を見渡し、どれくらいの日数が必要か算出する
休日や長期休暇を加味し、日常業務に影響を与えない範囲で期間を設定する
社内周知や社内研修をはじめ、運用に至るまでの時間を計算する

また、EOLを迎える期日までに入れ替えが完了しない事態の予測も重要です。二重にアプリケーションを使用できる期間が長いと、コストが積み重なるため、計画時に考慮しましょう。

計画する内容4.入れ替えの費用の確認

EOLを迎える製品の入れ替えを計画するときは、入れ替えに要する費用の把握が必要です。

入れ替えにかかるコストは、高額になる場合があります。見積金額によっては、別部署を巻き込んだ予算の確保が必要です。

ソフトウェア自体の費用以外にも、付随するコストを考慮した予算取りも検討事項のひとつです。

どうしても予算を確保できない場合、EOLを迎えた製品の入れ替えが難しくなります。その際は、入れ替えができない場合の対応を定めることが必要です。今後どのタイミングで入れ替えを行うかなど、追加の作業コストも発生します。

2024年以降EOLによりサポート終了になるOSSの例

2024年以降、EOLを迎えるOSSは複数あります。代表的なOSSの例を挙げます。

• OS系
  • 2024年3月24日：Alpine Linux 3.16
  • 2024年6月30日：CentOS Linux 7
• 言語・ランタイム系
  • 2024年4月23日：Ruby 3.0
  • 2024年10月：Python 3.8
• Webサーバー・ミドルウェア・ライブラリ系
  • 2024年3月31日：Apache Tomcat 8.5

OSSがEOLを迎えるとサポートが終了となり、脆弱性や不具合が発見されても修正パッチが適用されません。

セキュリティリスクを放置すると、サイバー攻撃の被害を受ける要因にもなります。

EOLを迎えるOSSを利用している際は、期日が訪れる前の入れ替えが求められます。

EOL対策なら「yamory」にご相談を！

EOLを迎えた製品には、脆弱性をはじめ、多くのセキュリティリスクがあります。EOLを迎えるOSSのリスクを把握し、適切な対策を講じると、セキュリティ脅威の回避に役立ちます。

しかし、ソフトウェアを利用している方は、保有しているOSSの各EOLをご自身で正確に把握・管理し、更新作業を行わないといけません。EOL対策は重要な役割を果たす一方、人力のみで対応するには、非常に時間がかかります。

EOL対策は、「自社で対応はできない」と考え、EOL対策が二の次になっている方もいるかもしれません。

株式会社アシュアードが運営する、脆弱性管理クラウド「yamory」は、OSSのEOL検知・管理機能が搭載された、リスク管理をオールインワンで実行できるツールです。

EOLの検知や管理が可能なツール「yamory」を使ったEOL対策にご興味ある方は、ぜひ資料をダウンロードしてください。