サプライチェーンリスク#

使用するソフトウェアには、セキュリティ上のリスクが常に存在します。特にサポートが終了したソフトウェアは脆弱性が放置されるリスクが高く、セキュリティインシデントの原因となります。また、マリシャスパッケージ（悪意のあるパッケージ）の混入は、情報漏洩やシステム侵害に直結する重大なリスクです。サプライチェーンリスク機能を使うことで、オーガニゼーション内の全サーバで使用されているソフトウェアの EOL 状況やマリシャスパッケージを一元管理し、計画的な対応を実現できます。

サプライチェーンリスク機能とは#

サプライチェーンリスク機能は、EOL（End of Life）やマリシャスパッケージなどサプライチェーン上のリスクを検知し、チケットとして一元管理する機能です。

主な機能#

網羅性の高いEOL検知#

Linux/Windows OS、コンテナ、OSS ライブラリ、サードパーティー製ソフトウェアなど幅広く対応
endoflife.date 掲載の400製品超、OS ベンダー公式 EOL 情報、FutureVuls 独自ロジックによる実質 EOL（EOL-Effective）検知を組み合わせた網羅性の高い検知

チケット形式での一元管理#

EOL 情報やマリシャスパッケージを集約した専用画面で、ステータス、期限、影響資産を確認
対応ステータス、優先度、担当者、対応期限の設定、コメントが可能
フィルター・ソート機能で効率的な管理を実現
EOL 解消時やマリシャスパッケージ削除時は次回スキャンで自動クローズ

自動通知#

随時通知: 新規サプライチェーンリスク検知時、サプライチェーンリスク情報更新時
EOL 月次レポート: グループ別・ソフトウェア別の EOL 集計

この機能で解決できること#

FutureVuls は、立場や役割の異なるそれぞれのユーザのサプライチェーンリスク管理に関する課題を解決します。

システム運用者#

自分のシステムに存在する「サポート切れ（EOL）のソフトウェア」や「マリシャスパッケージ」を漏れなく発見したい
EOL が迫っているソフトウェアを特定し、計画的にバージョンアップや移行を進めたい
マリシャスパッケージが検知された場合に、迅速に影響範囲を把握して対応したい
どのサプライチェーンリスクから対応すべきか、優先順位を判断したい
サプライチェーンリスクに関する対応状況をチーム内で共有し、管理したい

セキュリティ部門のサプライチェーンリスク管理者#

自社の全システムに存在する「サポート切れ（EOL）のソフトウェア」や「マリシャスパッケージ」を漏れなく発見したい
EOL が迫っているソフトウェアやマリシャスパッケージを特定し、各システム運用者に画面上から対応を指示したい
各システム運用者の対応状況を画面上で追跡したい
経営層に自社のサプライチェーンリスク一覧と対応状況をレポート報告したい

マリシャスパッケージの検知から対応完了までの流れ#

マリシャスパッケージが検知された際の全体的な対応フローは以下のとおりです。

flowchart LR
    A[スキャン実行] --> B[マリシャスパッケージ検知<br>OSV照合]
    B --> C[即時通知送信<br>Email / Slack / Teams]
    B --> D[サプライチェーンリスクタブに<br>チケット起票 ステータス:NEW]
    D --> E[担当者・優先度・<br>期限を設定]
    E --> F[対応実施<br>INVESTIGATING → ONGOING]
    F --> G{パッケージ<br>削除済み?}
    G -- Yes --> H[次回スキャンで<br>自動クローズ（CLOSED）]
    G -- No --> F

スキャン手順について#

サプライチェーンリスク検知のために特別なスキャン手順は不要です。通常の脆弱性スキャンにより取得されたソフトウェア構成情報を基に、FutureVuls が自動的に EOL 情報やマリシャスパッケージ情報とマッチングし、サプライチェーンリスクとしてチケット登録します。

なお、脆弱性スキャンで取得できなかったソフトウェアについては、CPE/PURLを手動登録することで EOL やマリシャスパッケージ検知の対象に追加できます。

CSIRT プラン限定機能

サプライチェーンリスク機能は、現在 CSIRT プラン限定の機能です。

検知対象#

EOLの検知対象#

サプライチェーンリスク機能は、OS、コンテナ、OSS ライブラリ、サードパーティー製ソフトウェアなど、多様なソフトウェアの EOL を網羅性高く検知します。複数のツールを使い分けることなく、1つのプラットフォームで全ての EOL リスクを一元管理できます。

endoflife.date との照合では、ソフトウェアのバージョンに最も詳しく一致するサポートサイクルの EOL 期限を採用します。

EOL 判定が変わった場合の再起票

2026年10月のリリースによる照合方法の修正は、次回のスキャン（SBOM の更新を含む）以降に反映されます。スキャンや SBOM の更新が行われないサーバは、従来の判定のままです。判定が変わった EOL のサプライチェーンリスクは起票し直され、RISK_ACCEPTED などに変更していた場合もステータスが NEW に戻ります。主担当者はサーバの担当者に戻り、対応予定日・対応期限は引き継がれません。起票時の通知も送信されます。 EOL 期限が同じでも、照合したサイクルが変われば再起票の対象です。該当のリスクは、改めて対応方針を設定してください。

EOL には、確定 EOL（EOL-Confirmed） と 実質 EOL（EOL-Effective） の2種類があります。確定 EOL は、提供元による明示的なサポート終了（EOL）宣言で確定している状態です。実質 EOL は、公式宣言がないものの、メンテナンス停止や未修正の重大な脆弱性などから事実上 EOL とみなせる状態です。なお、リポジトリのアーカイブ／無効化のみで明示的な EOL 宣言がない場合は、確定 EOL ではなく、メンテナンス状況に応じてソフトウェアヘルスで可視化されます。

サプライチェーンリスクとしてタスクが起票されるのは、確定 EOL と EOL 予定だけです。実質 EOL もソフトウェアヘルスやグループセットの横断検索で検知・可視化されますが、タスクとしては起票されません。

カテゴリー	スキャン対象	関連するスキャン方法・設定	備考
Linux	Linux OS	ローカルスキャン/リモートスキャン/ペーストスキャン/Inspector連携/SBOMインポート	Linux OS パッケージに関してはOSサポート期限と同じため、チケットとして個別に起票はしない（詳細は OSパッケージについてを参照)
	RHEL Application Streams	ローカルスキャン/リモートスキャン/ペーストスキャン/Inspector連携/SBOMインポート	・OSパッケージのサポート期間と異なるため検知対象（詳細は OSパッケージについてを参照）・Inspector連携では一部パッケージの EOL 情報が取得できないことがあります
	Linux上のBinary	CPEスキャン CPE手動登録が必要	vuls-saas/endoflife.date に登録されているEOL
	サードパーティーリポジトリパッケージ（CPE）	CPEスキャン CPE手動登録が必要	vuls-saas/endoflife.date に登録されているEOL
Windows	Windows OS	ローカルスキャン/リモートスキャン/ペーストスキャン/Inspector連携/SBOMインポート	-
	Windowsサードパーティー製ソフトウェア	CPEスキャン CPE自動割り当て、またはCPE手動登録が必要	vuls-saas/endoflife.date に登録されているEOL
コンテナ	Container Image OS	Trivy/Inspector SBOM インポート/SBOM	・OS パッケージに関してはOSサポート期限と同じため、チケットとして個別に起票はしない（詳細は OSパッケージについてを参照）・ECR の OS EOL 検知にはAmazon Inspector SBOMのインポートの設定が必要
	Container Image内のBinary	Trivy+CPEスキャン CPE手動登録が必要	・Bitnamiイメージイメージ内に配置されているバイナリは自動で脆弱性とEOLが検知可能。Trivyの機能でBitnamiイメージのバイナリのPURLを特定し、FutureVulsの機能でEOLを検知します。参考: Trivy/Bitnami Images ・Bitnami以外はBinaryのCPEをFutureVuls上から手動登録すると脆弱性とEOLが検知可能
OSS	OSS ライブラリ	Lockfile/Trivy/Inspector SBOM インポート/SBOMインポート	・vuls-saas/endoflife.date に登録されている EOL ・endoflife.date に登録されていない OSS は、FutureVuls の独自ロジックにより実質 EOL（EOL-Effective）を検知可能・AWS 環境の OSS の EOL 検知にはAmazon Inspector SBOMのインポートの設定が必要
非公開 EOL	公式 endoflife.date 未掲載の自社製品・商用ソフトウェアなど	オーガニゼーション API で EOL 情報を登録突合用に CPE/PURL の割り当てが必要	オーガニゼーション単位で登録した非公開 EOL 情報。同一ソフトウェアに公式 endoflife.date の情報がある場合でも優先（詳細は非公開 EOL 情報の登録を参照）
その他	CPE	CPEスキャン CPE手動登録が必要	vuls-saas/endoflife.date に登録されている商用製品やネットワーク機器などのEOL

OS パッケージの扱い

基本原則

Linux OS パッケージ、EPEL(Extended Package for Enterprise Linux)からインストールしたパッケージ、Container Image OS のパッケージは、それぞれ OS の EOL と同じライフサイクルのため、個別にはサプライチェーンリスクとしてチケット起票していません。 SBOM インポートや Inspector 連携で登録したサーバのように、OS パッケージに PURL や CPE が割り当てられている場合も同様です。すでに起票されていた該当のリスクは、そのサーバで SBOM の更新（再取り込み）または vuls のスキャン結果のアップロードが行われた時点で自動的に CLOSED になります。SBOM を手動でアップロードしたサーバでは、SBOM を更新するまで自動では CLOSED になりません。

Windows のインストール済みプログラム（SQL Server、Office など）は、割り当てられた CPE をもとに個別に EOL を検知します。

非公開 EOL 情報を登録した場合

非公開 EOL 情報として登録したソフトウェアは、OS パッケージであっても個別にサプライチェーンリスクとして検知します。

RHEL Application Streams は例外

RHEL (Red Hat Enterprise Linux) 8以降で導入された Application Streams は、OSのライフサイクルとは独立したサポート期限を持つため、個別にサプライチェーンリスクとして管理します。

Application Streams（Node.js、PHP、Python、MariaDB などのランタイムやツール）には個別のRetirement Dateが設定されています。

検知対象例: nodejs:18, php:8.2, java-21-openjdk, dotnet-runtime-8.0 など
データソース: Red Hat Application Streams Life Cycle

非公開 EOL 情報の登録#

公式の endoflife.date に掲載されていない自社製品や商用ソフトウェアの EOL 情報を、オーガニゼーション単位で登録できます（非公開 EOL / Private EOL）。登録した非公開 EOL 情報はサプライチェーンリスクの検知対象となり、同一ソフトウェアに公式 endoflife.date の情報が存在する場合でも、非公開 EOL 情報が優先して扱われます。

登録・更新・削除・一覧取得は、FutureVuls のオーガニゼーション APIから行います（画面 UI からの登録には対応していません）。

利用にあたって

オーガニゼーション設定で発行した オーガニゼーション用 API トークン を使用します（トークンの作成方法）。
ソフトウェアと突合するための purlList（PURL）または cpeList（CPE）を登録します。いずれもバージョンを含めずに製品を特定する PURL / CPE を指定し、バージョンの突合は releaseCycle で行われます。
突合対象のソフトウェア側にも、登録した PURL / CPE と一致する識別子が割り当てられている必要があります。スキャンで自動割り当てされないソフトウェア（例: 自社開発の製品・バイナリ、ソースからビルドしたミドルウェア、ネットワーク機器・IoT 機器など）は、CPE/PURL の手動割り当てで設定してください。
productName と releaseCycle の組み合わせはオーガニゼーション内で一意です。

エンドポイント・パラメータ・curl の具体例は「FutureVuls API サンプル：非公開 EOL の登録」を参照してください。

マリシャスパッケージの検知対象#

PURL が割り当てられているソフトウェアを対象に、OSV（Open Source Vulnerability）の情報と突合し、マリシャスパッケージ（悪意のあるコードを含むパッケージ）を自動検知します。

PURL が自動割り当てされるスキャン方法#

マリシャスパッケージの検知には、ソフトウェアに PURL が割り当てられている必要があります。以下のスキャン方法では PURL が自動で割り当てられます。

上記以外のスキャン方法で検知されたソフトウェアについては、CPE/PURLの手動割り当てにより PURL を設定することで検知対象に追加できます。

脆弱性タブの CVE-ID に MAL-○○ (MAL-ID) が表示されるケースについて

脆弱性タブ の「CVE ID」カラムに MAL-○○（例: MAL-2025-47141）という ID が表示される場合があります。これは Amazon Inspector などがマリシャスパッケージとして検出した脆弱性 ID で、FutureVuls にそのまま取り込まれて表示されています。

この MAL-○○ は、本ページで説明しているサプライチェーンリスク機能のマリシャスパッケージ検知（OSV の情報との突合）で検知されたものではありません。

サプライチェーンリスクの確認と管理#

検知されたサプライチェーンリスクは、専用の画面で確認・管理できます。

サプライチェーンリスク一覧: 検知されたすべての EOL やマリシャスパッケージを一覧で確認し、ステータスや優先度でフィルタリング・ソートできます
サプライチェーンリスク詳細: 個々のリスクの詳細情報を確認し、対応状況の管理やコメントの記録ができます

通知機能#

以下の通知機能を提供しています。

随時通知: 新規サプライチェーンリスク検知時、サプライチェーンリスク情報更新時にメールで通知
EOL 月次レポート: グループ別・ソフトウェア別の EOL 集計を月次でメール通知

詳細についてはサプライチェーンリスク通知をご参照ください。