EOL 管理入門（AWS、OSS ライブラリ、コンテナイメージ）

「このライブラリのサポートいつまでだっけ？」「Lambda ランタイムの EOL っていつだったかな？」

システム運用をしていると、こんな疑問がよく浮かびますよね。サービス・ライブラリの EOL を皆さんはどうやって管理しているでしょうか。

なぜEOLチェックが重要なのか

EOL（End of Life）を放置すると、セキュリティ・運用・ビジネスのリスクが高まります。

EOL（End of Life）と脆弱性は混同しやすいので簡潔に違いを示します。

EOL（End of Life）: ソフトウェアやサービスのサポート期間が終了すること。セキュリティパッチや公式サポートが受けられなくなる点が問題です。例: OS の LTS 終了、ランタイムのサポート終了。
脆弱性（Vulnerability）: 実際に発見されたセキュリティ上の欠陥で、修正やパッチが必要なもの。例: ライブラリの CVE、コンテナ内パッケージの脆弱性。

運用上の扱い方:

実務では EOL と脆弱性をセットで確認することが多く、両方を併せて運用フローに組み込むと効果的です。下記で紹介する一部のツールでも、両方のチェックを行うことができます。

プロダクトで利用している様々な技術スタックの EOL を確認したいのですが、実際のところ大変です。ここでは主要な要素について、どのようにEOLを確認できるかを一度整理します。

コンテナ化されたアプリケーションでは、ベースイメージのOSやその中に含まれるパッケージのEOL状況を把握する必要があります。特にECRで管理しているイメージは、定期的にスキャンして古いコンポーネントを特定することが重要です。

方法1: Amazon Inspector

Amazon Inspectorは脆弱性管理を行うツールですが、ECR に保存されたコンテナイメージの EOL を検知可能です。

方法2: Security Hub

Security Hub と連携して簡易的なダッシュボードを作ることも可能です。情報ソースは Amazon Indpector であるため、確認できる情報はいっそですが Security Hub のほうがダッシュボードとして確認しやすいのではないでしょうか。

※アカウントIDは念の為削除

現在の運用課題

クラウドサービスを利用していると、AWSが提供するサービスのバージョンアップや廃止予定を把握することが重要になります。Lambda ランタイムや Aurora のバージョンなど、事前の情報収集と計画的な移行が必要です。

方法1: AWS Health Dashboard

AWS Health Dashboardではバージョンアップ予定の AWS サービス（Lambda, Auroraなど）、終了予定の AWS サービスが確認可能です。

方法2: メール通知

正直にいえば上記の AWS Health Dashboard コンソールへアクセスしてのチェックは大変なため、AWS からの EOL のメール通知を元に対応しています。

現在の運用課題

カケハシでは Github Dependabot + Renovate で OSS ライブラリの脆弱性管理を行っています。

本格的に OSSライブラリの EOL を管理したい場合は SBOM を作成して endoflife.date 等で突き合わせる必要があります。今回は Github Dependabot Dashboard で脆弱性パッチ適用状況を確認し、簡易的な EOL 管理の代替とします（今後の課題）。

GitHub Dependabot Dashboard にアクセス
プロダクトごとにリポジトリをフィルタリング
- 私は Github Teams で開発チームごとにフィルタリング
- さらに不要なリポジトリを -repo: でフィルタリング
優先度（has:patch、severity、epss_percentage）ごとの件数を確認する
- 特に epss_percentage:>=0.01 のアラートを確認
- ※EPSS とは、その脆弱性が実際に攻撃で悪用される可能性を示すスコア