SBOM・コンテナイメージ・ソフトウェア台帳を横断したサポート終了検出の自動化

目的

2026年10月25日時点の情報である。ここで提案する手順は、アプリケーションのランタイム、ディストリビューションのパッケージ、コンテナの内容を含む環境全体について、ライフサイクル上のリスクを継続的に検出する。責任者を割り当てた対処待ちの一覧と、根拠が不確かな項目の一覧を別々に作る。根拠を更新するたびに、API スキーマ、ベンダーのライフサイクルページ、その環境で受けられるサポートを再確認する。導入の成功や検出結果の測定を報告するものではない。

前提条件

使用を許可された資産台帳、デプロイ記録、イメージ識別子、利用可能なソフトウェア部品表と、サポート契約を確認できる責任者を用意する。台帳情報の古さの許容範囲、情報源の更新頻度、移行に必要な期間、エスカレーション先を定める。判断とともに、ベンダーの URL、取得時刻、公開されている場合は改訂日を保存する。

endoflife.date プロジェクトは独自の API を文書化しており、他の製品のライフサイクルを集約している。そのフィードは調査の手掛かりとして扱い、期限の判断はベンダーの情報に従う。スキーマは、アクティブサポート終了、サポート終了、延長サポート終了を区別している。API 定義。

手順

1. デプロイ済みのワークロードから観測したバージョンを収集し、責任者とデプロイ識別子に結び付ける。休止中のテンプレートとビルド段階も含める。各コンポーネントについて、エコシステム、製品、エディション、リリースブランチ、配布元、パッケージの出所を保持する。バージョン文字列だけで照合せず、曖昧な名前は人による確認を必須にする。
2. デプロイされた各イメージのダイジェストを、その SBOM とベースイメージの来歴情報に関連付ける。Docker Scout がすでに利用できる場合、docker scout sbom --format spdx local://IMAGE でローカルイメージから SBOM を生成できる。IMAGE は対象のローカルイメージ参照に置き換える。解析したプラットフォームとダイジェストを記録する。対象を明示せず、単に最後にビルドされたイメージをスキャンしてはならない。SBOM コマンド。
3. コンポーネントを確認済みの製品識別子とリリースサイクル識別子に対応付ける。文書に記載された /api/v1/products/{product} エンドポイント、またはそのリリースサイクルのエンドポイントに問い合わせる。応答をキャッシュし、リダイレクトに従い、レート制限に対応する。提供されている場合は isEol、eolFrom、eoasFrom、eoesFrom を保持する。eolFrom が null なら日付は不明である。延長サポートのフィールドがない場合、その段階が適用されないこともある。どちらも無期限のサポートを認めるものではない。
4. 影響の大きい期限はベンダーのページで確認し、どのサポート段階と利用資格が適用されるかを記録する。上流と配布元の判断は分ける。Ubuntu のライフサイクルは、Main パッケージの標準保守、サブスクリプションによるサポート、その他のパッケージ区分を区別している。OS 名だけから、すべてのパッケージに同じサポートがあると推測してはならない。ディストリビューションのサポート範囲。
5. ライフサイクルとイメージの鮮度を独立して評価する。Docker のベースイメージの古さを判定するポリシーは、ベースタグの現在のダイジェストとイメージのビルド時に使ったダイジェストを比較し、来歴情報を必要とする。その比較に合格しても、基になるリリースが今もサポートされていることは確認できない。ライフサイクルの根拠、パッケージの対応付け、来歴情報が欠けている場合は、不明という状態を明示的に維持する。イメージポリシーの意味。
6. 必要な作業に基づいてアラートのしきい値を設定する。残り時間が、合意した移行所要期間に承認と復旧の余裕を加えた長さ以下になったら、移行を開始する。残り時間がリハーサル済みの切り替え・復旧所要時間だけになったらエスカレーションし、サポートが切れた場合は直ちに報告する。これらは組織内ポリシーの提案であり、ベンダーの期限ではない。責任者とコンポーネントごとにアラートの重複を除き、例外は自動的に期限切れにして見直しの対象とする。
7. サポート中、サポート終了、不明、フィードが古い場合、文書で延長サポートを確認できる場合を使い、判断手順をテストする。ダイジェストは最新だがリリースはサポート対象外というイメージも含める。対処後に指摘を解決済みにする前に、資産の観測情報とライフサイクルの根拠を両方更新する。

期待される結果

各指摘から、影響を受けるワークロード、コンポーネント、サポート段階、ベンダーの根拠、責任者、次の対応が分かる。データが欠けているものはサポート中に数えず、欠落したままであることが見える状態にする。

限界と検証の根拠

SBOM だけでは、契約上のサポートを証明したり、実行時の変更をすべて把握したりすることはできない。これは、文書化されたインターフェースを整理し、評価手順を提案したものである。ここでのテストは受け入れ基準であり、実施結果の報告ではない。ライフサイクル監視は脆弱性検出や侵害検出を補完するものであり、どちらかの検出結果を確定するものではない。