サプライチェーンリスク#
組織で使用するソフトウェアには、セキュリティ上のリスクが常に存在します。 特にサポートが終了したソフトウェアは脆弱性が放置されるリスクが高く、セキュリティインシデントの原因となります。 また、マリシャスパッケージ(悪意のあるパッケージ)の混入は、情報漏洩やシステム侵害に直結する重大なリスクです。 サプライチェーンリスク機能を使うことで、組織内の全サーバで使用されているソフトウェアの 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 が迫っているソフトウェアやマリシャスパッケージを特定し、各システム運用者に画面上から対応を指示したい
- 各システム運用者の対応状況を画面上で追跡したい
- 経営層に自組織のサプライチェーンリスク一覧と対応状況をレポート報告したい
スキャン手順について#
サプライチェーンリスク検知のために特別なスキャン手順は不要です。 通常の脆弱性スキャンにより取得されたソフトウェア構成情報を基に、FutureVuls が自動的に EOL 情報やマリシャスパッケージ情報とマッチングし、サプライチェーンリスクとしてチケット登録します。
なお、脆弱性スキャンで取得できなかったソフトウェアについては、CPE/PURLを手動登録することで EOL やマリシャスパッケージ検知の対象に追加できます。
CSIRT プラン限定機能
サプライチェーンリスク機能は、現在 CSIRT プラン限定の機能です。
検知対象#
EOLの検知対象#
サプライチェーンリスク機能は、OS、コンテナ、OSS ライブラリ、サードパーティー製ソフトウェアなど、多様なソフトウェアの EOL を網羅性高く検知します。 複数のツールを使い分けることなく、1つのプラットフォームで全ての EOL リスクを一元管理できます。
EOL には、確定 EOL(EOL-Confirmed) と 実質 EOL(EOL-Effective) の2種類があります。確定 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 パッケージおよび Windows パッケージ、EPEL(Extended Package for Enterprise Linux)からインストールしたパッケージ、Container Image OS のパッケージは、それぞれ OS の EOL と同じライフサイクルのため、個別にはサプライチェーンリスクとしてチケット起票していません。
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 が自動で割り当てられます。
- VulsスキャナによるLockfileを指定したスキャン
- Trivyでファイルシステム上のパスを指定したスキャン
- Lockfileのペーストスキャン
- コンテナイメージ内にインストールされた依存ライブラリをTrivyでスキャン
- アプリケーションのSBOMインポート
- Amazon Inspector SBOMのインポート
- GitHub Security Alerts連携
上記以外のスキャン方法で検知されたソフトウェアについては、CPE/PURLの手動割り当てにより PURL を設定することで検知対象に追加できます。
脆弱性タブの CVE-ID に MAL-○○ (MAL-ID) が表示されるケースについて
脆弱性タブ の「CVE ID」カラムに MAL-○○(例: MAL-2025-47141)という ID が表示される場合があります。
これは Amazon Inspector などがマリシャスパッケージとして検出した脆弱性 ID で、FutureVuls にそのまま取り込まれて表示されています。
この MAL-○○ は、本ページで説明しているサプライチェーンリスク機能のマリシャスパッケージ検知(OSV の情報との突合)で検知されたものではありません。
サプライチェーンリスクの確認と管理#
検知されたサプライチェーンリスクは、専用の画面で確認・管理できます。
- サプライチェーンリスク一覧: 検知されたすべての EOL やマリシャスパッケージを一覧で確認し、ステータスや優先度でフィルタリング・ソートできます
- サプライチェーンリスク詳細: 個々のリスクの詳細情報を確認し、対応状況の管理やコメントの記録ができます
通知機能#
以下の通知機能を提供しています。
- 随時通知: 新規サプライチェーンリスク検知時、サプライチェーンリスク情報更新時にメールで通知
- EOL 月次レポート: グループ別・ソフトウェア別の EOL 集計を月次でメール通知
詳細については サプライチェーンリスク通知 をご参照ください。