サポート終了（EOL）オープンソースのセキュリティ
サポート終了（EOL）となったオープンソースソフトウェアとは、元の作者やコミュニティによるメンテナンスが終了したソフトウェアのことです。サポート終了後は、新しいセキュリティパッチ、バグ修正、公式アップデートは一切リリースされません。セキュリティとメンテナンスの責任は、そのソフトウェアを引き続き運用している組織に完全に移ります。
「サポート終了（EOL）オープンソースソフトウェア」とは何ですか？
サポート終了（EOL）オープンソースソフトウェアとは、元のメンテナンス担当者やコミュニティによるメンテナンスがもはや行われていないソフトウェアのことです。
EOL とは、ソフトウェアが動作しなくなることを意味するわけではありません。それは、以下のことを意味します：
- 新しいセキュリティパッチはありません
- バグ修正なし
- 公式な更新情報はありません
ソフトウェアがEOL（サポート終了）に達すると、そのソフトウェアを使用している組織がそのセキュリティ体制について全責任を負うことになります。
EOLのオープンソースソフトウェアはなぜセキュリティ上のリスクとなるのか？
EOLソフトウェアは、アップストリームでのパッチ提供が終了した後も脆弱性が発見され続けるため、セキュリティ上のリスクとなります。
新しい脆弱性が発見された場合：
- CVEが割り当てられる可能性はまだある
- 依然として悪用される可能性がある
- 元のプロジェクトでは修正されません
攻撃者は、エクスプロイトを無期限に再利用できるため、EOL（サポート終了）コンポーネントを積極的に標的にしています。時間が経つにつれてリスクは増大する一方で、防御手段はますます限られてきます。
メンテナンス担当者がパッチの適用をやめたらどうなるのか？
メンテナンス担当者がパッチの適用を停止したとき：
- 脆弱性の公開は今後も続く可能性がある
- CVEは引き続き割り当てられ、記録される
- エクスプロイトは依然として開発され、悪用される可能性がある
何が修復を妨げているのか？
当該ソフトウェアを運用する組織は、以下のいずれかを行う必要があります：
- リスクを受け入れる
- 依存関係を置き換えるか、アップグレードする
- パッチを独自に入手して適用する
規制の厳しい環境では、パッチが適用されていない脆弱性が、監査上の指摘事項となることがよくあります。
ライフサイクルの終了がオープンソースのセキュリティに関する意思決定に与える影響
オープンソースソフトウェアは、古いからといってリスクが高まるわけではありません。メンテナンスが終了した時点で、リスクが高まるのです。
サポート終了（EOL）とは、セキュリティに対する責任がオープンソースコミュニティから、そのソフトウェアを引き続き運用している組織へと完全に移行する時点のことです。その時点以降、新たに発見された脆弱性は、独自に対処しない限り、恒久的なものとなります。
EOLステータスは、オープンソースの長期的なセキュリティリスクを予測する最も有力な指標の一つです。
ソフトウェアがEOLに達した後はどうなるのでしょうか？
製造終了後：
- 脆弱性は依然として発見され、CVEが割り当てられる可能性がある
- エクスプロイトは依然として開発・再利用される可能性がある
- 上流のセキュリティパッチの提供が完全に停止する
これにより、非対称的なリスクが生じます。攻撃者は時間の経過とともに新たな情報を得ていく一方で、防御側は公式な是正措置の選択肢を失っていきます。この時点で、組織はリスクを排除するか、リスクを補うか、あるいはリスクを受け入れるかを決定しなければなりません。
EOL後はどのような選択肢がありますか？
組織には一般的に4つの選択肢があります。
- リスクを受け入れる
パッチを適用せずにソフトウェアを使い続ける。これはよくあることですが、リスクは時間の経過とともに増大し、後になってインシデント、監査指摘、あるいは緊急移行といった形で表面化することがよくあります。 - アップグレードまたは移行
サポート対象のバージョンまたは代替製品へ移行します。これによりEOL（サポート終了）のリスクを回避できますが、多くの場合、大規模なリファクタリングや再トレーニングが必要となり、また長い期間を要します。 - アプリケーションを書き換える
完全に書き換えることで、依存関係を完全に排除できます。これは最もコストがかかり、リスクも最も高い選択肢であり、計画通りに迅速に完了することはめったにありません。 - 延長セキュリティサポートの導入
一部の組織では、サードパーティのメンテナンス事業者を活用し、EOL（サポート終了）となったオープンソースソフトウェアへのパッチ適用を継続しています。このモデルでは、ソフトウェアはアップストリームではEOLのままですが、脆弱性については独立して調査・修正が行われ、既存のAPIや動作を維持したままのドロップインパッチとしてリリースされます。これにより、直ちに移行を迫られることなく、パッチ適用経路が回復します。
EOL（サポート終了）に関する議論を超えて、なぜこれが重要なのか
オープンソースにおいて、サポート終了（EOL）は例外的なケースではありません。それは避けられないことです。
あらゆるオープンソースの依存関係は、いずれサポート終了を迎えます。セキュリティ上の課題は、それが起こるかどうかではなく、発生した際に組織がどのように対応するかという点にあります。
成熟したオープンソースのセキュリティ戦略では、以下の点を考慮に入れています：
- バージョンだけでなく、依存関係のライフサイクル
- 脆弱性の数だけでなく、パッチの提供状況も
- 理想化されたアップグレードの道筋ではなく、運用上の現実
EOLを理解することは、オープンソースのセキュリティ全体を理解する上で不可欠です。
「NEVER-ENDING SUPPORT (NES)」とは何ですか？
Never-Ending Support (NES) 、サポート終了（EOL）となったオープンソースソフトウェア向けの拡張セキュリティ保守Never-Ending Support (NES) 。
アプリケーションの書き換え、フレームワークのアップグレード、APIの変更を必要とせずに、継続的な脆弱性修正を提供します。NESは、既存の動作と互換性を維持しつつ、重要な依存関係に対するセキュリティパッチの提供を再開します。
製品ライフサイクル終了（EOL）後も、コンプライアンス要件を満たしていますか？
必ずしもそうとは限りません。
EOL（サポート終了）になったからといって、ソフトウェアが即座にコンプライアンス違反となるわけではありませんが、ほとんどのセキュリティおよびコンプライアンス・フレームワークにおける重要な要件である「脆弱性の適時な修正」が満たされなくなります。
EOL後は、アップストリームからのパッチ提供が終了します。脆弱性が存在する場合、あるいは後に発見された場合、組織はそれらのリスクをどのように軽減しているかを証明しなければなりません。
コンプライアンスの遵守は、代替的な管理措置が講じられているかどうかにかかっています。
EOLがコンプライアンス上のリスクをもたらす理由
ほとんどのセキュリティおよび規制の枠組みでは、特定のソフトウェアバージョンを義務付けていません。その代わりに、以下の要件を定めています：
- 既知の脆弱性が特定された
- セキュリティパッチは適時適用されます
- 未対応のコンポーネントは是正されるか、正式にリスクが容認される
ソフトウェアがEOL（サポート終了）に達すると、組織はアップストリームの更新を通じてこれらの要件を満たすという従来の手段を失うことになります。
パッチが適用されていないEOL依存関係は、一般的に以下の場所に現れます：
- ペネトレーションテスト報告書
- サードパーティによるリスク評価
- SOC 2およびISO監査の結果
組織はEOL後にどのようにコンプライアンスを維持しているか
コンプライアンスを維持するために、組織は通常、以下のことを行います：
- EOLとなった依存関係をアップグレードまたは置き換える
- 影響を受けるアプリケーションのリファクタリングまたは書き換え
- 拡張セキュリティサポートを利用して、EOLソフトウェアのパッチ適用プロセスを再開する
セキュリティ保守期間の延長により、組織は既存のシステムを停止させることなく、是正措置の要件を満たすことができます。