SBOMのインポート仕様#

ここでは、SBOM ファイルをインポートした際に、ファイルに含まれる情報がどのように FutureVuls に取り込まれるか（取り込まれないか）の共通的な仕様を説明します。

CycloneDX / SPDX それぞれのフォーマット固有のパース仕様については「CycloneDX形式のインポート仕様」「SPDX形式のインポート仕様」を参照してください。

インポート処理の流れ#

SBOM ファイルは、おおまかに以下の流れで取り込まれます。 SBOM ファイルからコンポーネント（ソフトウェア）の一覧を読み取り、各コンポーネントの識別情報（PURL / CPE）から ソフトウェア種別 を判定したうえで、OS 情報・OS パッケージ・依存ライブラリとして FutureVuls に登録します。

SBOM のインポートで登録される種別

1つの SBOM には1つの OS

FutureVuls は、1つの SBOM ファイルが 1つの OS に対応していることを前提としています。 1つの SBOM に複数の OS 情報が含まれている場合はインポートエラーになります。

コンポーネントの種別判定#

コンポーネントは、含まれる識別情報（PURL / CPE）によって、登録される ソフトウェア種別 や情報の優先度が異なります。登録される情報に対して脆弱性検知がどのように行われるかは、「CPEとPURLを両方割り当てた場合の動作」を参照してください。

判定は PURL を最優先 し、PURL がない場合に CPE・名称を利用します。

持っている識別情報	登録される種別	備考
PURL（OSパッケージのエコシステム）	`os`（OSパッケージ）	サーバSBOM、または SBOM サーバに追加したアプリケーション SBOM（アプリケーションSBOMに含まれるOSパッケージを参照）。`rpm` / `deb` / `apk` など
PURL（言語のエコシステム）	`library`（言語ライブラリ）	`npm` / `maven` / `pypi` など
PURL（上記以外のエコシステム）	`private`
PURL なし＋ CPE あり	`private`	CPE の情報で登録されます
PURL・CPE なし＋名称あり	`private`	名称とバージョンで登録されます（バージョンがない場合は `unknown`）
PURL・CPE・名称いずれもなし	ー	必須情報不足のため登録されません

PURL と CPE の両方を持つコンポーネントは、両方の情報を割り当てて登録します。

なぜ PURL (Package URL) が推奨されるのか

CPE (Common Platform Enumeration) は OS パッケージや OSS ライブラリの脆弱性検知において誤検知のリスクがあります（OSパッケージのCPE登録）。

一方、PURL はパッケージマネージャのエコシステムに基づいた正確な特定が可能で、脆弱性検知の精度が向上します。そのため、FutureVuls では PURL を持つコンポーネントを優先的に取り込みます。

PURL も CPE も割り当てられていないソフトウェアは、SBOM インポート後に手動で CPE または PURL を割り当てない限り、脆弱性検知の対象になりません（CPE/PURLの割り当て参照）。

対応するエコシステム（PURL Type）#

PURL の種類（エコシステム）によって、OS パッケージか言語ライブラリかが判定されます。

OSパッケージ系（os として登録）: rpm / deb / apk / alpm / win（Windows）。dpkg / yum も os として登録されます（それぞれ deb / rpm として扱われます）。
言語ライブラリ系（library として登録）: npm（Node.js） / maven・gradle（Java） / pypi（Python） / conda（Conda） / gem（Ruby） / golang（Go） / composer（PHP） / cargo（Rust） / nuget（C# / F# / VB.NET） / conan（C/C++） / cocoapods（CocoaPods） / swift（Swift） / hex（Erlang） / pub（Dart）

FutureVuls の言語ライブラリ検知は Trivy を使用しており、library の対象エコシステムは Trivy が対応する範囲の中から定めています。

いずれにも該当しないエコシステムの PURL を持つコンポーネント（generic など）は private として登録されます。 private は PURL による脆弱性検知の対象外です。

登録される種別と脆弱性検知の対象は別です

OS パッケージは、SBOM の OS が FutureVuls の対応環境に含まれる場合に脆弱性検知の対象になります。例: alpm（Arch Linux）は os として登録されますが、対応 OS ではないため検知されません。SBOM の OS 自体が非対応の場合はインポートエラーになりますが、「OS 情報を無視して取り込む」を有効にすると、OS パッケージを除いて取り込めます。
言語ライブラリは、Trivy が脆弱性検知に対応しているエコシステムが対象です。例: conda は library として登録されますが、Trivy が脆弱性検知の対象としていないため検知されません。

詳細は「対応環境 > アプリケーション依存ライブラリ」を参照してください。

取り込まれる情報#

OS情報（サーバSBOMのみ）#

サーバ SBOM としてアップロードした場合のみ、SBOM ファイルに含まれる OS 情報がサーバの OS として登録されます（OS 情報がない場合は Pseudo として登録されます）。 OS 名とバージョンの両方を含めることを推奨します（例: Ubuntu 20.04, CentOS 7）。なお、OS 情報が複数含まれているとインポートエラーになります。

Windows の KB 情報#

Vuls が生成したサーバ SBOM からは、Windows の Release とカーネルバージョンをもとに、適用済みと未適用の KB を取り込むことができます。取り込んだ KB をもとに、Windows のスキャンで脆弱性の修正状況を判定します。エクスポートした SBOM での KB の出力位置は「1つのサーバ情報をSBOMエクスポート」を参照してください。

OSパッケージ情報#

OS のパッケージマネージャで管理されるソフトウェア（RPM, deb, apk など）の情報で、サーバ詳細 > ソフトウェアタブに種別 os で表示されます。サーバ SBOM としてアップロードした場合に脆弱性検知の対象になります。アプリケーション SBOM に含まれる OS パッケージは、SBOM サーバに追加した場合のみ検知の対象になります（アプリケーションSBOMに含まれるOSパッケージを参照）。

OS パッケージの種別が複数混在している場合（例: rpm と deb）や、OS パッケージ情報があるのに OS 情報が含まれていない場合（SBOM サーバに追加するアプリケーション SBOM を除く）は、インポートエラーになります。 OS 情報がない場合でも、「OS 情報を無視して取り込む」を有効にすると、OS パッケージを除いて取り込めます。

アプリケーションSBOMに含まれるOSパッケージ#

SBOM サーバ（サーバ SBOM から作成したサーバ）へ追加したアプリケーション SBOM 内の OS パッケージは、サーバ SBOM の OS パッケージと同様に脆弱性検知の対象になります。ベースとなる機器の SBOM に、後から追加したパッケージを別の SBOM として登録する場合などに利用できます。対象は、OS が判明している SBOM サーバのみです。

アプリケーション SBOM に OS 情報が含まれていない場合は、取り込み先サーバの OS のパッケージとして取り込みます
1 台のサーバには、同じ名前の OS パッケージを 1 バージョンのみ登録できます。サーバ内の他の SBOM と同じ名前でバージョンの異なる OS パッケージを含む SBOM を取り込む・更新すると、エラーになります。エラーメッセージには、衝突したパッケージと相手の SBOM 名が表示されます
取り込んだ内容は、翌日の定期スキャン、または手動スキャンの後に検知結果へ反映されます

依存ライブラリ（アプリケーション）情報#

言語のパッケージマネージャで管理されるライブラリ（Java, Python, Node.js, Go など）の情報で、サーバ SBOM・アプリケーション SBOM の両方で取り込まれ、サーバ詳細 > ソフトウェアタブに種別 library で表示されます。

依存ライブラリは、言語エコシステム単位、またはマニフェストファイル（pom.xml, package-lock.json 等）単位で アプリケーション としてまとめられます（まとめ方は SBOM の生成ツールによって異なります）。なお、ロックファイルやマニフェストファイル自体はライブラリとして登録されず、その中に記載された依存関係のみが登録されます。

CPE 情報#

SBOM に記載された CPE は、そのソフトウェアに割り当てる CPE として取り込まれ、脆弱性検知に使われます。取り込まれた CPE は手動で割り当てた CPE と同じ扱いになり、CPE の自動割当では上書きされません。

CycloneDX ではコンポーネントの cpe を読み取ります
SPDX では externalRefs のうち、referenceCategory が SECURITY で、referenceType が cpe23Type または cpe22Type のもの（大文字・小文字を区別します）を読み取ります。CPE が複数記載されている場合は、条件に合う最初の 1 件だけを使います。その 1 件が正しくない場合も、2 件目以降は使いません
CPE 2.3 形式（cpe:2.3: で始まり、11 個の要素をコロンで区切ったもの）と、CPE 2.2 形式（cpe:/ で始まるもの）に対応しています

CPE の要素のうち、次の 4 つは値によって取り込みや検知の結果が変わります。* は「任意の値（ANY）」、- は「該当なし（NA）」を表す値です。

要素	必要な値	値が `*` または `-` の場合
part	`a`（アプリケーション）/ `o`（OS）/ `h`（ハードウェア）のいずれか	CPE が取り込まれません（`a` / `o` / `h` 以外の値でも同様）
vendor	NVD などの脆弱性データベースで使われているベンダー名	CPE は取り込まれますが、脆弱性の検知には使われません
product	NVD などの脆弱性データベースで使われている製品名	CPE は取り込まれますが、脆弱性の検知には使われません
version	ソフトウェアのバージョン	バージョンを比較できないため、影響するバージョンの範囲外（修正済みのバージョン）でも脆弱性が検知され、過検知の原因になります

そのほかの要素（update、edition など）は、分かる値を記載してください。分からない要素は * のままでも検知できます。

例として、OpenSSL 3.0.13 の CPE は次のように扱われます。

SBOM に記載された CPE	結果
`cpe:2.3:::openssl:3.0.13:::::::*`	part が `*` のため、取り込まれません
`cpe:2.3:a::openssl:3.0.13:::::::`	vendor が `*` のため、取り込まれますが検知には使われません
`cpe:2.3:a:openssl:openssl:3.0.13:::::::*`	取り込まれ、検知に使われます

このほか、CPE の書式として正しくない場合も CPE は取り込まれません。CPE 2.3 形式では、次のような場合です。

要素の数が足りない
空の要素がある
値の途中にエスケープされていない * や ? がある
値に空白を含む

CPE 2.2 形式には * という表記がなく、要素を空にするか省略すると「任意の値（ANY）」として扱われます。そのため、上の表の * と同じ条件が当てはまります。たとえば、part を空にした cpe:/:openssl:openssl:3.0.13 は取り込まれません。

CPE が取り込まれなくてもインポートはエラーになりません

CPE が取り込まれなかった場合も、SBOM のインポート自体は成功し、そのソフトウェアには SBOM の CPE が割り当てられません。 SBOM の生成ツールによっては、part や vendor を * として出力するものがあります（例: Yocto）。 SBOM の CPE で脆弱性を検知するには、part・vendor・product を含む CPE が出力されるよう生成ツールの設定を見直すか、SBOM の CPE を修正してから取り込んでください。 SBOM を修正できない場合は、インポート後に FutureVuls 上で CPE を割り当ててください。

ライセンス情報#

SBOM 内に記載されたコンポーネントのライセンス情報を取り込み、ソフトウェア詳細 > OSSライセンスで確認できます。複数のライセンスが指定されている場合は、AND / OR / WITH を用いた SPDX ライセンス式として表示されます。なお、ライセンス名として不自然なもの（空、極端に長い、著作権表記や定型文を含む文字列など）は取り込まれません。

OS を特定できない SBOM の取り込み#

OS パッケージ（rpm / deb / apk など）を含む SBOM は、OS を特定できないと取り込めません。取り込みダイアログの「OS 情報を無視して取り込む」（FutureVuls API では ignoreOS: true）を有効にすると、OS パッケージを除いたコンポーネントだけを取り込めます。

対象は、OS 情報がないのに OS パッケージを含む SBOM と、対応環境に含まれない OS の SBOM です
OS を特定できる SBOM では、有効にしても従来どおり OS パッケージも取り込みます
取り込まなかった OS パッケージは登録されないため、脆弱性検知の対象になりません
サーバ SBOM として取り込んだ場合、サーバの OS は Pseudo になります

取り込まれない情報#

脆弱性情報#

SBOM ファイル内に記載されている脆弱性情報は取り込まれません。

FutureVuls は、インポートされたコンポーネント情報（ PURL や CPE ）をもとに、最新の脆弱性データベースを使って独自に再マッチング処理を行います。これにより、SBOM 作成時点では検知されていなかった新たな脆弱性も発見可能になります。

トラブルシューティング#

SBOM ファイルのインポートがうまくいかない場合の主な原因と対処法です。

ファイル登録時にエラーになる場合#

原因	詳細・対処法
生成ツール情報がない	SBOM に生成ツールの情報が含まれていません。 → `metadata.tools`（CycloneDX）または `creationInfo.creators`（SPDX）にツール情報が出力されるよう SBOM を再生成してください。手作業で作成した SBOM の場合は、ツール名に `manual` と記載してください（生成ツール参照）。
OS情報の不整合	「OS パッケージ情報（rpmなど）」が含まれているのに、OS の種類とバージョンを特定できない場合、登録に失敗します（OS が判明している SBOM サーバへ追加するアプリケーション SBOM は、OS 情報がなくても取り込めます）。 → OS 情報（CycloneDX: type が `operating-system` のコンポーネント、SPDX: `primaryPackagePurpose` が `OPERATING-SYSTEM` のパッケージ）を含めて SBOM を再生成するか、SBOM に OS 情報を追記してください。OS パッケージを除いて取り込む場合は、「OS 情報を無視して取り込む」を有効にして再実行してください。
OS情報の重複	1つの SBOM に複数の OS 情報が含まれています。 → シングル OS の構成に修正してください。
パッケージ形式の混在	異なる種別の OS パッケージ（例: apk と deb）が混在しています。 → どちらか一方のみを含むようにしてください。
非対応のOS	検出された OS が FutureVuls のサポート対象外です。 → 対応環境を確認してください。OS パッケージを除いて取り込む場合は、「OS 情報を無視して取り込む」を有効にして再実行してください。
非対応のフォーマット	CycloneDX / SPDX 以外、またはサポート外のバージョン（SPDX v3 など）です。 → 対応環境の形式・バージョンで出力してください。
ファイルを解析できない	ファイルが破損している、または CycloneDX / SPDX の仕様どおりの構造になっていません。 → ファイルが破損していないか、仕様に準拠しているかを確認してください。
アプリケーション名の重複	SBOM 内に同じ名前のアプリケーションが複数含まれています。 → 名前が重複しないよう SBOM を修正してください。
同名・別バージョンの OS パッケージ	サーバ内の他の SBOM と同じ名前で、バージョンの異なる OS パッケージが含まれています。 → ベースのパッケージを更新した場合はサーバ SBOM を修正し、追加分と重なった場合は先にアプリケーション SBOM から該当パッケージを外してから、取り込み直してください。

インポートは成功したが、情報が不足している場合#

OS/パッケージ情報がない: 「アプリケーション SBOM」として登録していませんか？アプリケーション SBOM では OS 情報は無視され、OS パッケージは SBOM サーバに追加した場合のみ検知の対象になります。
脆弱性が表示されない: SBOM 内の脆弱性情報は利用されず、FutureVuls 側で次回スキャン時に検知されます。すぐに反映したい場合は、サーバ詳細から手動スキャンを実行してください。また、PURL と CPE が両方ないコンポーネントは自動では脆弱性検知されないため、手動で CPE または PURL を割り当ててください。
SBOM に記載した CPE が割り当てられていない、または CPE で脆弱性が検知されない: CPE の part・vendor・product が * や - になっていないか確認してください（CPE 情報を参照）。