SBOM(Software Bill of Materials)ツールは、ソフトウェアに含まれるOSSやライブラリ、依存関係などを把握し、SBOMの生成・管理・共有や、脆弱性・ライセンス情報との照合を支援するツールです。
SBOMツールを比較する際は、「SBOMを出力できるか」だけでは十分ではありません。米国CISAは2025年版の「Minimum Elements for a Software Bill of Materials」で、コンポーネント名やバージョン、一意識別子、依存関係だけでなく、ハッシュ、ライセンス、生成ツール、生成コンテキストなどをSBOMのデータ項目として整理しています。NISTは、SBOMリポジトリと脆弱性検出機能を連携し、ソフトウェアサプライチェーン上のリスクを継続的に確認する考え方を示しています。
英国National Cyber Security Centre(NCSC)も、SBOMはソフトウェアインベントリを改善する手段の一つであり、完全性、正確性、生成タイミングを確認する必要があるとしています。
本記事では、これら米国・英国の公的資料とイスラエル国家サイバー総局(INCD)のサプライチェーン対策を参考に比較項目を設定し、国内外のSBOM関連ツール6製品を公式公開情報から比較します。
※機能は2026年10月1日時点で各社が公開している情報を基に整理しています。契約プラン、対象言語、対象環境、提供地域などによって利用可能な機能が異なる場合があります。
SBOMツールとは
SBOMツールは、ソフトウェアを構成するコンポーネントを検出し、Software Bill of Materialsとして出力・管理するためのツールです。
実際の製品は大きく次の3タイプに分けられます。
| タイプ | 主な役割 |
|---|---|
| SBOM生成ツール | ソースコード、パッケージ、コンテナなどを解析しSBOMを生成 |
| SBOM管理ツール | 複数のSBOMを取り込み、バージョンや製品単位で管理 |
| SCA・脆弱性管理型 | SBOM生成に加え、CVE、ライセンス、依存関係、VEXなどを管理 |
実務では3タイプが明確に分かれているとは限りません。SCA製品がSBOMを生成したり、SBOM管理製品がCVEとの照合まで提供したりするためです。
SBOMそのものの仕組みやSPDX、CycloneDX、VEXとの違いについては「SBOMとは」で詳しく整理します。
SBOMツールが必要になる理由
SBOMツールの役割は、規制対応用のファイルを作ることだけではありません。
大量のソフトウェアコンポーネントを利用する企業では、新たな脆弱性やサプライチェーンインシデントが発生した際に、「対象コンポーネントを自社がどこで利用しているか」を短時間で特定する必要があります。
Axiosへのサプライチェーン攻撃では週1億ダウンロード規模のライブラリが影響
2026年3月31日、JavaScriptで広く利用されるHTTPクライアントライブラリ「Axios」で、悪意あるバージョンがnpmへ公開されるサプライチェーン攻撃が発生しました。
セキュリティ対策Labで確認した事後報告では、攻撃対象となったAxios 1.14.1は週次約1億ダウンロード規模でした。
このような事案では、担当者が「Axiosを直接導入したか」だけを確認しても十分とは限りません。別のパッケージの依存関係として利用している可能性があるためです。
SBOMやSCAによって直接依存・推移的依存を把握できれば、影響調査の対象を絞り込みやすくなります。
Next.jsの脆弱性では利用バージョンの確認が必要になった
2025年にはNext.jsの認証回避脆弱性CVE-2025-29927が公表されました。影響するバージョンと修正版が示されたため、利用企業は自社システムでNext.jsを使用しているか、どのバージョンかを確認する必要がありました。
Next.jsが危険度の高い脆弱性を修正(CVE-2025-29927)
SBOMツールを選ぶ際は、単に「一覧を出せるか」ではなく、新しいCVEが公表された後に既存のSBOMへ継続的に照合できるかまで確認する必要があります。
公的機関の資料から見るSBOMツールの比較項目
本記事では、CISA、NIST、NCSC、INCDの公開資料を基に、次の項目を比較します。
1. SPDX・CycloneDXに対応しているか
CISAはSBOMを機械処理可能な形式で共有することを前提としており、実務ではSPDXとCycloneDXが広く利用されています。
ツール間やサプライヤー間でSBOMを交換する場合、独自CSVだけではなく標準形式を扱えることを確認します。
2. 外部から受け取ったSBOMを取り込めるか
自社開発ソフトウェアのSBOMを生成するだけなら出力機能だけでも利用できます。
一方、調達先やグループ会社からSBOMを受け取り、脆弱性管理へ利用する場合はインポート機能が必要です。
NISTは、ソフトウェアを調達する組織がサプライヤーから機械可読なSBOMを受け取り、カタログ化する考え方を示しています。
3. 依存関係をどこまで取得できるか
SBOMの価値はコンポーネント名の一覧だけでは決まりません。
直接利用しているライブラリだけでなく、そのライブラリがさらに利用している推移的依存関係をどこまで把握できるかを確認します。
4. SBOMを継続的に更新できるか
NCSCは、ソフトウェア構成が変化するたびにインベントリを最新状態に保つ必要性を示しています。
一度SBOMを作成しても、次のリリースや依存ライブラリ更新後には内容が変わります。CI/CDやビルド工程へ組み込み、更新を自動化できるかが比較項目になります。
5. CVEなどの脆弱性情報と照合できるか
SBOMは構成情報であり、SBOMだけでは脆弱性を修正できません。
NISTはSBOMリポジトリと脆弱性検出機能を組み合わせる方法を示しています。新しいCVEが公開された際に、保存済みSBOMへ自動照合できるかを確認します。
6. VEXに対応しているか
SBOMに脆弱なコンポーネントが含まれていても、対象製品では脆弱な機能を使用しておらず、実際には影響を受けない場合があります。
VEX(Vulnerability Exploitability eXchange)は、その脆弱性が製品へ影響するかを機械可読形式で伝えるために利用されます。
イスラエルINCDは、ソフトウェアの各バージョンについてサプライヤーからSBOMとVEXを受け取ることを推奨しています。
7. OSSライセンスを管理できるか
CISAの2025年版Minimum Elementsではライセンス情報がSBOMデータ項目に追加されています。
ソフトウェアサプライチェーン管理では、脆弱性だけでなく、OSSライセンスの条件や利用リスクも確認対象になります。
8. ソースコード・コンテナ・バイナリなど何を解析できるか
SBOM生成方式によって取得できる情報は変わります。
- ソースコード
- パッケージマネージャー
- コンテナイメージ
- ビルド成果物
- バイナリ
- 外部SBOM
自社の開発・調達形態に合った解析方式があるかを確認します。
SBOMツール6製品の比較
以下は各社公式サイト・公式ドキュメントで確認できた範囲を整理したものです。
「要確認」は、機能が存在しないという意味ではなく、今回確認した公式公開情報だけでは明確に判断できなかった項目です。
| 製品 | SPDX | CycloneDX | SBOM取込 | 脆弱性照合 | ライセンス管理 | VEX | 主な特徴 |
|---|---|---|---|---|---|---|---|
| yamory | ○ | ○ | ○ | ○ | ○ | 要確認 | 国産。SBOMと脆弱性管理を一元化 |
| JFrog Xray | ○ | ○ | ○ | ○ | ○ | ○ | JFrog Platform内の成果物・SBOMと連携 |
| Snyk | ○ | ○ | 要確認 | ○ | ○ | 要確認 | 開発者向けSCAとCLIによるSBOM生成 |
| Mend SCA | ○ | ○ | ○ | ○ | ○ | ○ | SBOM、SCA、到達可能性分析などを統合 |
| Black Duck SCA | ○ | ○ | ○ | ○ | ○ | ○※ | OSS・ライセンス・SBOM管理に対応 |
| Anchore Enterprise | ○ | ○ | ○ | ○ | ○ | ○ | SBOMを中心に生成・保存・継続評価 |
※Black DuckのVEX機能は契約ライセンスでVEXモジュールを有効にする必要があります。
yamory
yamoryは株式会社アシュアードが提供する国産の脆弱性管理クラウドです。
公式情報では、SCAによるソフトウェア構成把握、SBOM生成、外部SBOMのインポート、脆弱性管理、OSSライセンス管理、EOL管理などに対応しています。
SBOMはSPDX、CycloneDX、CSVで出力でき、外部で作成されたSPDX・CycloneDX形式のSBOMも取り込めます。
さらに、取り込んだソフトウェア構成情報を脆弱性データベースと照合し、CISA KEVやEPSSなどの情報を含めて対応優先度を判断できます。
GitHub ActionsやJenkinsなどのCI/CDパイプラインとの連携も公式FAQで案内されています。
確認できた主な機能
- SPDX・CycloneDX出力
- SPDX・CycloneDXインポート
- SCA
- OSSライセンス管理
- 脆弱性管理
- CISA KEV
- EPSS
- コンテナスキャン
- CI/CD連携
- 日本語サポート
国内企業でSBOMと脆弱性管理を同じ基盤に集約したい場合に比較対象となります。
JFrog Xray
JFrog Xrayは、JFrog Platform上のアーティファクトや依存関係を解析し、脆弱性やライセンスリスクを管理する製品です。
公式ドキュメントでは、スキャン結果からSPDXとCycloneDX形式でSBOMをエクスポートできます。
SPDXは2.3と3.0、CycloneDXはJSON・XMLに対応し、CycloneDXではVEX情報を含めることもできます。
また、外部ツールで生成したCycloneDXまたはSPDX形式のSBOMをXrayへインポートし、脆弱性やライセンス情報を付加できます。
確認できた主な機能
- SPDX出力
- CycloneDX出力
- SBOMインポート
- 脆弱性情報付加
- ライセンス情報
- CycloneDX VEX
- JFrog Platformとの統合
すでにJFrog Artifactoryなどを開発基盤として利用している組織では、成果物管理とSBOM・脆弱性管理を接続しやすい構成です。
Snyk
Snykは開発者向けセキュリティプラットフォームで、オープンソース依存関係やコンテナなどの脆弱性を開発工程で検出できます。
Snyk CLIのsbomコマンドでは、CycloneDX 1.4、1.5、1.6とSPDX 2.3形式のSBOMを生成できます。
パッケージマネージャーで管理されるプロジェクトだけでなく、対応するアンマネージドプロジェクトについてもSBOM生成機能が提供されています。
確認できた主な機能
- SPDX 2.3
- CycloneDX 1.4~1.6
- CLIによるSBOM生成
- OSS脆弱性管理
- ライセンス情報
- 開発工程との連携
今回確認したSnykのSBOM公式ドキュメントでは、外部SBOMの汎用的な管理・インポート機能やVEX出力について明確な記載を確認できなかったため、必要な場合は契約前に確認してください。
Mend SCA
Mend SCAは、OSSコンポーネントの検出、脆弱性・ライセンス管理、SBOM生成などを提供するSCA製品です。
公式ドキュメントでは、SPDX 2.2・2.3とCycloneDX 1.4・1.5・1.6に対応しています。
2026年にはSPDX・CycloneDXのSBOMインポート機能を強化し、ファイルレベルのコンポーネントやソースファイルのカバレッジにも対応しています。
コンテナ向けSBOMではVEXデータをCycloneDXレポートへ含めることができます。
Mendは保存済みSBOM内のコンポーネントを継続監視し、新たに脆弱性が公開された場合に通知する機能も案内しています。
確認できた主な機能
- SPDX
- CycloneDX
- SBOMインポート
- SBOM継続更新
- 脆弱性管理
- OSSライセンス管理
- VEX
- コンテナSBOM
- Reachability分析
「SBOMを作る」だけでなく、脆弱性が実際に利用コードから到達可能かまで含めて優先順位付けしたい組織では確認対象になります。
Black Duck SCA
Black Duck SCAは、ソフトウェア内のOSS・第三者コンポーネントを識別し、脆弱性やライセンスリスクを管理するSCA製品です。
2026年の公式ドキュメントでは、SBOM出力形式としてSPDX 2.2、2.3、3.0とCycloneDX 1.3~1.6を選択できます。
SBOMをインポートしてプロジェクト情報へ反映する機能も提供されています。
VEXについてはCSAF 2.0形式のレポートを生成でき、製品ごとの脆弱性の影響有無を関係者へ伝える用途に利用できます。ただしVEX機能は製品登録キーで有効化する必要があります。
確認できた主な機能
- SPDX 2.2~3.0
- CycloneDX 1.3~1.6
- SBOMインポート
- OSS脆弱性管理
- ライセンス管理
- VEX
- 依存関係管理
- SBOMテンプレート
OSS利用が多く、セキュリティだけでなくライセンス・コンプライアンスを同じ基盤で管理したい場合に比較対象となります。
Anchore Enterprise
Anchore EnterpriseはSBOMを中心にソフトウェアサプライチェーンのセキュリティを管理するプラットフォームです。
オープンソースのSBOM生成ツール「Syft」を基盤にし、ソースリポジトリやコンテナイメージからSBOMを生成できます。
外部から受領したSPDX・CycloneDX形式のSBOMも取り込めます。
保存されたSBOMは新しい脆弱性情報と継続的に再照合され、ライセンスやポリシー評価にも利用できます。
公式ドキュメントでは、CycloneDX 1.6またはSPDX 2.3形式の統合SBOM、Vulnerability Disclosure Report、VEX文書をエクスポートできます。
確認できた主な機能
- SPDX
- CycloneDX
- 外部SBOMインポート
- ソースコード・コンテナ解析
- 継続的な脆弱性照合
- ライセンス管理
- VEX
- SBOM差分・ドリフト確認
- ポリシー評価
調達先から受領したSBOM、自社開発のSBOM、コンテナなどを同じSBOM管理基盤へ集約したい組織では比較しやすい製品です。
SBOMツールの選び方
SBOM生成だけか、生成後の管理まで必要か
規制・顧客要求に対応するためSBOMファイルを生成することだけが目的なら、生成機能を中心に比較できます。
一方、企業内で継続的な脆弱性管理へ利用する場合は、次も確認します。
- 外部SBOMのインポート
- 新規CVEとの継続照合
- 影響製品の検索
- VEX
- 修正状況管理
- ライセンス管理
- SBOM更新履歴
サプライヤーから受領したSBOMを管理するならインポート機能を見る
大企業では、自社開発だけでなく、購入ソフトウェア、委託開発、グループ会社の製品を管理するケースがあります。
この場合、SBOM生成機能よりも「他社のSBOMを取り込み、社内基準で再評価できるか」が選定ポイントになります。
SPDX・CycloneDXのバージョンまで確認する
単に「SPDX対応」「CycloneDX対応」と記載されていても、対応バージョンやJSON/XMLなどの出力形式が異なります。
取引先や規制要件で形式が指定される場合は、バージョンまで確認してください。
VEXが必要かを決める
SBOMだけでは、脆弱なコンポーネントが存在するという情報と、実際に製品がその脆弱性の影響を受けるかを区別しにくい場合があります。
製品ベンダーやPSIRTとして顧客へ脆弱性影響を通知する場合は、VEX対応を確認します。
SBOMと脆弱性管理を別製品にするか統合するか
すでに脆弱性管理基盤やSCAを導入している企業では、新しいSBOM専用ツールを追加するより、既存製品のSBOM機能を利用できる場合があります。
一方、複数のSCAや開発基盤からSBOMを受領する場合は、中央のSBOM管理基盤を設ける方法もあります。
公的要件をそのまま○×比較しない
CISAやNISTの資料は、特定のSBOM製品を認定・ランキングするための基準ではありません。
例えばCISAのMinimum Elementsに「ハッシュ」が含まれているからといって、画面上にハッシュを表示する製品が自動的に優れているわけではありません。
実務では、
- 自社のSBOM利用目的を決める
- 必要な公的要件を整理する
- 必要なSBOM形式・データ項目を決める
- 製品がその情報を取得・維持できるか確認する
- 脆弱性管理や調達プロセスまで含めて運用を評価する
という順序で比較します。
SBOMツール導入前に確認したい質問
ベンダーへは、少なくとも次を確認すると製品差を把握しやすくなります。
- SPDX・CycloneDXの対応バージョンは何か
- SBOMの生成方法は何か
- 直接依存・推移的依存をどこまで取得できるか
- パッケージマネージャー外のコンポーネントを検出できるか
- コンテナやバイナリを解析できるか
- 外部で生成したSBOMを取り込めるか
- SBOMを更新するタイミングはいつか
- 新しいCVEが公開された際、既存SBOMを再評価するか
- VEXを生成・インポートできるか
- OSSライセンスをどこまで管理できるか
- API・CI/CD連携が可能か
- グループ会社やサプライヤー単位で権限を分けられるか
- SBOMの保管期間・変更履歴を管理できるか
- 料金は何を基準に課金されるか
公開情報だけでは確認できない項目も多いため、2~3製品に絞った段階で資料・デモを比較する方が実運用とのズレを減らせます。
まとめ
SBOMツールは「SBOMを出力できるか」だけで選ぶと、作成後の運用で追加作業が発生する可能性があります。
CISA・NIST・NCSC・INCDの公開資料を踏まえると、標準形式、依存関係、更新、外部SBOM取込、脆弱性照合、VEX、ライセンス、開発工程との連携まで確認すると比較しやすくなります。
SBOMの利用目的が「顧客へ提出するため」なのか、「自社の脆弱性管理へ利用するため」なのか、「サプライヤーから受領して管理するため」なのかを先に整理し、目的に合う機能を持つ製品を比較してください。
出典
公的機関
- Minimum Elements for a Software Bill of Materials (SBOM) – CISA
- Software Security in Supply Chains: Software Bill of Materials (SBOM) – NIST
- SBOMs and the importance of inventory – UK National Cyber Security Centre
- Israel National Cyber Directorate CERT-IL Alert 1934 – INCD
製品公式情報
- サービス詳細 – yamory
- よくあるご質問 – yamory
- SBOM Import – JFrog Xray
- SBOM Export – JFrog Xray
- SBOM – Snyk User Docs
- Mend SBOM – Mend.io
- The Dependencies SBOM Report – Mend.io Documentation
- Software Bill of Materials (SBOM) report – Black Duck Documentation
- Vulnerability Exploitability EXchange (VEX) – Black Duck Documentation
- SBOM Management – Anchore Enterprise
- SBOMs – Anchore Enterprise








