サポート終了 (End-Of-Life: EOL)
Node.js のリリースがサポート終了に至る理由とその方法
Node.js のメジャーバージョンは、予測可能なスケジュールに基づいてリリース、パッチ適用、そしてサポート終了が指定されます。すべてのリリースラインを永続的に維持することは現実的ではないため、計画されたメンテナンス期間が終了すると、Node.js のメジャーリリースラインはプロジェクトによるメンテナンスが停止されます。
リリースラインが EOL に達するとどうなるか
あるバージョンがサポート終了になると、セキュリティパッチを含むアップデートが提供されなくなります。これにより、これらのバージョンで実行されているアプリケーションは、修正されることのないセキュリティ問題やバグに対して脆弱な状態になる可能性があります。
- 脆弱性の修正がなくなる: 新しいセキュリティリリースで新しいメジャーラインの問題やパッチが公開された際に、同じ脆弱性が EOL のリリースラインに影響する場合でも、それらに対する新しいリリースは行われません。EOL のリリースラインに固執し、影響を受けるコードパスを使用しているユーザーは、公開された脆弱性を悪用する攻撃に対して即座に脆弱になります。
- ツールチェーンの破損: EOL リリースは、依存する共有ライブラリの新しいバージョンに動的にリンクできなくなる可能性があり、システムアップデートを妨げたり、破損させたりすることがあります。
- エコシステムからの乖離: 多くの人気のあるユーザーランドパッケージは、時間の経過とともに EOL の Node.js リリースのサポートを打ち切ります。アプリケーションが古いパッケージに固執すると、さらに多くの未修正の脆弱性やバグに悩まされ、エコシステムの標準からますます乖離していく可能性があります。
- コンプライアンス上の警告: 多くの業界監査では、メンテナンスされていないランタイムの使用が禁止されています。
EOL バージョン
| バージョン (コードネーム) | 最終更新日 | 脆弱性 | 詳細 |
|---|---|---|---|
| v23 | 2高2中 | ||
| v21 | 7高5中 | ||
| v19 | 1高3中2低 | ||
| v18 (Hydrogen) | 15高19中4低 | ||
| v17 | 1高3中1低 | ||
| v16 (Gallium) | 11高18中4低 | ||
| v15 | 1クリティカル6高1中1低 | ||
| v14 (Fermium) | 2クリティカル16高16中5低 | ||
| v13 | 1クリティカル2高 | ||
| v12 (Erbium) | 2クリティカル13高6中3低 | ||
| v11 | 3高1中 | ||
| v10 (Dubnium) | 1クリティカル12高3中1低 | ||
| v9 | 1クリティカル4高1中1低 | ||
| v8 (Carbon) | 1クリティカル11高2中1低 | ||
| v7 | 3高2中 | ||
| v6 (Boron) | 16高12中 | ||
| v5 | 15高8中 | ||
| v4 (Argon) | 2クリティカル17高9中 | ||
| v0 | 2クリティカル |
商用サポート
EOL リリースを使用することの明らかなデメリットにもかかわらず、実際には、レガシーコードベース、コンプライアンス要件、複雑な依存関係チェーンなど、組織が即時のアップグレードを妨げる制約に直面することがあります。OpenJS Foundation Ecosystem Sustainability Program を通じて、Node.js は HeroDevs と NodeSource によってサポートされており、セキュリティ修正のための商用サービスが提供されています。
HeroDevs は、公式のメンテナンスフェーズを過ぎた Node.js バージョンに対して Never-Ending Support (NES) を提供しています。これには、セキュリティパッチ、コンプライアンス支援、およびアップグレード戦略を計画する間のギャップを埋めるための技術サポートが含まれます。
NodeSource は、古いサポートされていないバージョンの Node.js を実行するためのセキュリティサポートを提供し、チームが安全な状態を維持しながら新しいリリースに移行するための時間と柔軟性を確保します。
商用サポートを通じて EOL リリースを使用することは一時的な解決策と見なすべきであり、目標は常にアクティブにサポートされているバージョンにアップグレードすることであるべきです。