SBOMのインポート仕様#

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

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

インポート処理の流れ#

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

flowchart LR
    subgraph S1["① 読み込み"]
        A["SBOMファイル<br>コンポーネント一覧"]
    end
    subgraph S2["② 種別判定"]
        C{"識別情報を判定"}
    end
    subgraph S3["③ ソフトウェア種別"]
        D["OSパッケージ（os）<br>※サーバSBOMのみ"]
        E["言語ライブラリ（library）"]
        F["private"]
        G["登録されない"]
    end
    subgraph S4["④ 登録"]
        Z["FutureVulsに登録"]
    end
    A --> C
    C -->|"OSパッケージ系のPURL"| D
    C -->|"言語系のPURL"| E
    C -->|"その他のPURL / CPE / 名称のみ"| F
    C -->|"識別情報なし"| G
    D --> Z
    E --> Z
    F --> Z

1つの SBOM には1つの OS

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

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

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

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

持っている識別情報	登録される種別	備考
PURL（OSパッケージのエコシステム）	`os`（OSパッケージ）	サーバSBOMのみ。`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 ライブラリの脆弱性検知において誤検知のリスクがあります（詳細）。

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

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

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

PURL の種類（エコシステム）によって、OS パッケージか言語ライブラリかが判定されます。代表的なものは以下の通りです。

OSパッケージ系: rpm / deb / apk など
言語ライブラリ系: npm（Node.js） / maven・gradle（Java） / pypi（Python） / gem（Ruby） / golang（Go） / composer（PHP） / cargo（Rust） / nuget（C#）など

上記以外のエコシステムの PURL を持つコンポーネントは private として登録されます。

取り込まれる情報#

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

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

OSパッケージ情報（サーバSBOMのみ）#

OS のパッケージマネージャで管理されるソフトウェア（RPM, deb, apk など）の情報で、サーバ SBOM としてアップロードした場合のみ取り込まれ、サーバ詳細 > ソフトウェアタブに種別 os で表示されます。

OS パッケージの種別が複数混在している場合（例: rpm と deb）や、OS パッケージ情報があるのに OS 情報が含まれていない場合は、インポートエラーになります。

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

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

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

ライセンス情報#

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

取り込まれない情報#

脆弱性情報#

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

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

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

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

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

原因	詳細・対処法
OS情報の不整合	「OS パッケージ情報（rpmなど）」が含まれているのに、「OS 情報（OS名）」が含まれていない場合、登録に失敗します。 → OS 情報を追記するか、ツール設定を見直してください。
OS情報の重複	1つの SBOM に複数の OS 情報が含まれています。 → シングル OS の構成に修正してください。
パッケージ形式の混在	異なる種別の OS パッケージ（例: apk と deb）が混在しています。 → どちらか一方のみを含むようにしてください。
非対応のOS	検出された OS が FutureVuls のサポート対象外です。 → 対応環境を確認してください。
非対応のフォーマット	CycloneDX / SPDX 以外、またはサポート外のバージョン（SPDX v3 など）です。 → 対応環境の形式・バージョンで出力してください。

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

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