おすすめのSBOMツール（2026年版）

結論

• コンテナイメージとファイルシステムの無料SBOM：Syft。脆弱性、シークレット、IaCのスキャナーも必要ならTrivy。
• ソースコードからのCycloneDX：CycloneDXコミュニティのcdxgen。
• すでにパッケージ化しているビルド出力のSPDX：Microsoft SBOM Tool。
• AWS上のワークロード：Amazon Inspectorにデータを渡すAmazon Inspector SBOM Generator。
• GitHubリポジトリのSBOMを手早く：GitHubの依存関係グラフのエクスポート。
• SBOMを監視する無料のセルフホスト環境：OWASP Dependency-Track。
• ライセンスコンプライアンスを最優先：FOSSA。サプライヤーとポートフォリオのSBOM：ManifestまたはCybeats。大量のコンテナと政府向けポリシーパック：Anchore Enterprise。
• 自社のビルドが実際に取り込んだもののSBOMを、脆弱性監視と来歴データとともに：GitHub Actions向けのCRACI。

SBOMツールの役割

ソフトウェア部品表（SBOM）は、ソフトウェアに含まれるコンポーネント、ライブラリ、依存関係を、CycloneDXやSPDXなどの機械可読形式で列挙したものです。SBOMツールには2種類あります。生成ツールはSBOMを作成します。管理ツールは多数の製品やサプライヤーのSBOMを保管し、脆弱性データと照合し、ポリシーを適用して共有します。管理ツールは、生成ツールから受け取るデータに依存します。

どのツールでSBOMを作成するかと同じくらい、いつ作成するかが重要です。CISAのSBOMの種類に関するガイダンスでは、開発環境とソースファイルから作成するソースSBOM、リリース可能な成果物のビルドの一環として生成するビルドSBOM、ビルド後に実行ファイルやコンテナイメージなどの成果物を解析して生成する解析SBOMを区別しています。以下の生成ツールのほとんどはソースSBOMまたは解析SBOMを作成します。CRACIが作成するのはビルドSBOMです。違いの詳細はビルド時SBOMで説明しています。

このページの対象読者

このページは、Cyber Resilience Act、顧客からの質問票、あるいは自社の脆弱性対応のためにSBOMを必要とし、選択肢を比較検討しているチーム向けです。CRACIは当社の製品であることを踏まえてお読みください。他のツールに関する記述はすべて各ツールのドキュメントに基づいており、各ツールについてはより詳しいCRACIとの比較ページがあります。

SBOMツールの選び方

• SBOMを作成したいのか、管理したいのか、その両方か。生成ツールはファイルを出力します。管理ツールは、多数の製品やサプライヤーのファイルを保管し、情報を付加し、対応につなげる場を提供します。
• 自社のソフトウェアか、購入したソフトウェアか。自社のビルドなら入力を管理できるので、それを記録できます。サプライヤーのソフトウェアには、受け入れ、検証、場合によってはバイナリ解析が必要です。
• リストの完全性をどこまで確かめる必要があるか。生成ツールは事後にファイルを読み取るもので、ツール間の差異は多くの人が予想する以上に大きくなります（後述）。ビルドSBOMは、ビルドが使用したものを記述します。
• 顧客が求める形式はどれか。CycloneDXとSPDXはどちらも広く受け入れられており、ほとんどのツールは少なくとも一方を出力します。
• どのCIを使っているか、セルフホストが必須か。オープンソースの生成ツールはどこでも実行できます。CRACIは現時点ではマネージドサービスとしてLinux上のGitHub Actionsに対応しており、GitLab CI、Jenkins、顧客ホスト型ランナーはロードマップに掲載されています。

複数のチームが同じ方法でSBOMを作成する必要がある場合は、エンジニアリングチーム横断のSBOM生成をご覧ください。

SBOM生成ツール

ここでは各生成ツールの機能を比較しており、返されるコンポーネント数を比較するものではありません。

CRACI

CRACIはスキャナーではなく記録ツールです。GitHub ActionsのジョブはCRACIのランナー上で実行され、パッケージを認識するプロキシが、CIキャッシュから復元されたパッケージを含め、各ジョブが取得したものを記録します。CycloneDXまたはSPDX形式のSBOMには、ビルドが使用した推移的依存関係が含まれ、ジョブごと、キャッシュごとに完全性が示されます。その後もCRACIは監視対象のSBOMを再評価し続けるため、生成ツールと管理ツールの役割を兼ねます。GitHub Actionsでビルドするソフトウェアに最適です。注意点：イメージやディレクトリはスキャンできず、現時点ではGitHub Actions上のLinuxジョブを実行します（他のCIシステム、Windows、macOSはロードマップに掲載）。CRACIのSBOM生成

Syft

SyftはAnchoreが提供する、コンテナイメージとファイルシステム向けの無料のApache-2.0ライセンスの生成ツールです。数十種類のパッケージタイプを認識し、CycloneDX、SPDX、Syft JSONを出力し、署名付きのin-toto SBOMアテステーションを作成できます。姉妹ツールのGrypeが、SBOMを脆弱性と照合します。イメージや、無料の生成ツールが必要なあらゆるパイプラインに最適です。注意点：カタロガーはスキャンの種類によって選ばれるため、expressをインストール済みのチェックアウトでは、1つのフラグでnpmパッケージが結果に含まれるかどうかが決まります。CRACIとSyft・Grypeの比較

Trivy

TrivyはAqua Securityが提供する多機能なApache-2.0ライセンスのスキャナーで、イメージ、ファイルシステム、リポジトリ、VMイメージ、Kubernetesに対応しています。脆弱性、IaCの設定ミス、シークレット、ライセンスを検出し、その副産物としてCycloneDXやSPDXを出力します。多数のセキュリティチェックを1つの無料バイナリで行いたいチームに最適です。注意点：リポジトリではロックファイルを読み取るため、express 5.2.1（ロックファイルなし）やclaude-code（マニフェストなし）では読み取るものがありません。これはドキュメントどおりの動作です。CRACIとTrivyの比較

cdxgen

cdxgenはOWASP CycloneDXのプロジェクトで、ソースとコンテナイメージからCycloneDX BOMを作成します。ライセンスはApache-2.0です。CycloneDXに統一しており、その形式のコミュニティが開発した生成ツールを使いたいチームに最適です。注意点：他のスキャナーと同様、目の前にあるファイルが宣言しているものしか報告できません。CRACIと自作SBOMスタックの比較

Microsoft SBOM Tool

Microsoft SBOM ToolはMITライセンスの生成ツールで、SPDX 2.2（指定によりSPDX 3.0）を出力し、SBOMをSPDX仕様に照らして検証できます。コマンドラインでビルドのドロップフォルダー、パッケージ名、バージョン、サプライヤーを指定する必要があるため、ビルド後の工程として使うもので、GitHub ActionsとAzure Pipelinesで動作します。すでにパッケージ化しているビルド出力のSPDXが必要なチームに最適です。注意点：ビルドのドロップではなく、コミットされた状態のリポジトリを対象にすると、記述できるものはほとんどありません。コマンドラインでサプライヤーを受け取るため、サプライヤーのフィールドは埋めることができます。CRACIと自作SBOMスタックの比較

GitHubの依存関係グラフのエクスポート

GitHubの依存関係グラフは、リポジトリのマニフェストとロックファイル、および依存関係送信APIで送られた情報をまとめたもので、UIまたはREST APIからSPDXとしてエクスポートできます。Dependabotアラートの基になっており、GitHubのすべてのプランに含まれています。すでにGitHubを使っており、手早くSBOMが必要なチームに最適です。注意点：固定されたコミットではなくデフォルトブランチの状態を反映し、スキャナーが読み取るファイルではなく、GitHubがリポジトリについて把握している情報から作成されます。CRACIとGitHub Advanced Securityの比較

Amazon Inspector SBOM Generator

Sbomgenは、Amazon Inspector自身によるイメージ、Lambda、EC2のスキャンを支える生成ツールで、単体のLinuxバイナリとして提供されています。コンテナイメージ、ディレクトリ、アーカイブ、マウントされたボリューム、コンパイル済みのGoとRustのバイナリからパッケージのメタデータを読み取り、OSパッケージ（APK、DPKG、RPM）と、C#、Go、Java、Node.js、PHP、Python、Ruby、Rustなどの言語に対応し、CycloneDXを出力します。脆弱性の検出結果を得るためにSBOMをAmazon Inspector Scan APIに送信でき、これにはAWSアカウントが必要です。ワークロードがすでにAWS上で稼働しているチームに最適です。注意点：Linuxでのみ動作し、他のスキャナーと同様、読み取ったファイルが宣言しているものを検出します。

Safeguard

SafeguardのCLIはSyftとGrypeを実行して、リポジトリ、コンテナイメージ、アップロードされたマニフェストからCycloneDXとSPDXのSBOMを作成し、プラットフォームではさらに、AIが作成する修正プルリクエストとポリシーゲートを利用できます。スキャンと自動修正を1つのサブスクリプションで利用したいチームに最適です。注意点：他のスキャナーと同様、読み取ったファイルが宣言しているものを列挙します。CRACIとSafeguardの比較

スキャンによるSBOMを左右する要因

上記の生成ツールを同じリポジトリに対して実行すると、それぞれ異なるリストが返されます。各ツールのドキュメントから予想されるパターンは次のとおりです。

• 何をコンポーネントとみなすかがツールによって異なる。どのファイルを信頼し、見つけたものをどう命名するかは各生成ツールが独自に決めるため、1つのリポジトリからでもツールごとに異なるリストが得られます。
• ロックファイルがなければ依存関係もない。Express 5.2.1はロックファイルをコミットしていないため、ロックファイルから依存関係を解決する生成ツールはnpmの依存関係を1つも報告せず、それ以外に認識できたものだけを返します。
• マニフェストがまったくない。claude-codeリポジトリにはマニフェストもロックファイルもないため、各ツールが返す結果は他の種類のファイルから組み立てられたもので、プロジェクトよりもツールの特性を反映したものになります。
• メタデータが乏しい。ほとんどの生成ツールには情報源がないため、サプライヤーのフィールドは空になることが多くあります。

これらのツールに不具合があるわけではありません。いずれも設計どおり、目の前にあるファイルを読み取っています。教訓は、スキャンによるSBOMが、ツール、その設定、事前に誰かが依存関係をインストールしたかどうかに左右されるということです。Syft、Trivy、cdxgenがそれぞれ何を読み取るかについては、オープンソースのSBOM生成ツールが見落とすものをご覧ください。

SBOM管理ツール

Anchore Enterprise

Anchore EnterpriseはSyftとGrypeを基盤とし、大規模組織に必要な機能を追加しています。コンテナ、ソース、ファイルシステムのSBOM、スキーマの正しさを検証したうえでのSBOMのインポート、元の成果物なしでの継続的な再スキャン、FedRAMP、NIST、CIS、PCI DSS、CMMC向けのポリシーパックです。Kubernetes、Docker Compose、エアギャップ環境にデプロイできます。複数のCIシステムにまたがる大量のコンテナや、政府関連の業務に最適です。注意点：SBOMが記述するのはあくまでスキャナーが見つけたものであり、料金は見積もりです。CRACIとAnchoreの比較

FOSSA

FOSSAはライセンスコンプライアンスから始まった製品で、全文によるライセンス検出、ポリシー、帰属表示を備えています。SPDXとCycloneDXのSBOMを生成・インポートし、VDRやVEXのステートメントを追加でき、インポートしたSBOMをNTIAとFDAの最小要素に照らしてチェックし、EnterpriseではポータルでSBOMを共有できます。Freeプランは5プロジェクトまで対応します。ライセンスリスクを最優先に考えるチームに最適です。注意点：CLIは、動作するビルドがあればビルドツールに問い合わせ、なければソースから推測します。また、バイナリとスニペットのスキャンはアドオンです。CRACIとFOSSAの比較

Cybeats SBOM Studio

SBOM Studioは自らを「SBOMの記録システム」と称しています。SPDX 2.2～3.0.1とCycloneDX 1.2～1.7のインポートとエクスポートに対応し、インポート前にSBOMの品質をスコア化し、すべてのコンポーネントを継続的に照合し、Transparency Exchange API経由を含めて顧客とSBOMやVEXのデータを共有します。ICS、医療機器、通信、自動車の分野でSBOMプログラムを運営する製品セキュリティチームに最適です。注意点：SBOMを作成するのではなく管理するツールであり、品質スコアが確認するのは形式であって、生成ツールが見落としたものではありません。CRACIとCybeatsの比較、Cybeatsの代替ツール

Manifest

Manifestは、自社製品、ベンダー、AIモデルにまたがってSBOMを収集し、情報を付加し、共有します。ベンダーはセキュアなポータルからアップロードし、SBOMが提供されない場合、Manifestはバイナリを解析してSBOMを生成できます。SPDX、CycloneDX、VEXに対応し、FDAのガイダンス、NIST 800-218、UNECE R155にマッピングされています。主なリスクが購入したソフトウェアにある組織に最適です。注意点：ManifestのGitHub Actionは、自社ソフトウェアのSBOMをデフォルトでSyftを使って生成します。CRACIとManifestの比較

OWASP Dependency-Track

Dependency-TrackはApache 2.0ライセンスのプラットフォームで、すべてのアプリケーションのすべてのバージョンにわたってコンポーネントを追跡し、NVDやGitHub Advisoriesなどの情報源から脆弱性データを取得し、セキュリティ、ライセンス、運用のポリシーを適用し、CycloneDX VEXの取り込みと出力に対応しています。パイプラインはAPI経由でSBOMをアップロードします。透明性の高いセルフホスト型の分析プラットフォームを求めるチームに最適です。注意点：SBOMは生成せず、自社で運用する必要があります（APIサーバーには少なくとも2 GBのRAMと2つのCPUコアが必要です）。Dependency-TrackユーザーのためのCRACI

CycloneDXかSPDXか

どちらの形式もオープンな標準であり、このページのほとんどのツールは少なくとも一方を出力します。CycloneDXはOWASPのプロジェクトで、Ecma InternationalによりECMA-424として標準化されており、コンポーネントリストとともに脆弱性データやVEXデータも扱えます。SPDXはLinux Foundationのプロジェクトで、国際標準ISO/IEC 5962:2021です。Cyber Resilience Actは特定の形式を指定せず、「一般的に使用される機械可読形式」を求めているため、顧客や下流のツールが読み取れる形式を選んでください。両形式を並べた例はSBOMの例を、運用方法はSBOMのベストプラクティスをご覧ください。SBOMを大規模に保管・監視する方法についてはSBOM管理をご覧ください。

CRACIの位置付け

CRACIはスキャナーでも管理ツールでもなく、記録ツールです。GitHub ActionsのジョブはCRACIのランナー上で実行され（runs-onをcraciに変更）、パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースとダウンロードプリセットから各ジョブが取得したものを記録します。CIキャッシュから復元されたパッケージは、そのエビデンスを引き継ぎます。CycloneDXまたはSPDX形式のSBOMには、ビルドが使用した推移的依存関係が含まれ、ジョブごと、キャッシュごとに完全性の状態（Complete、Complete with connections、Incomplete、Unavailable、Not recorded）が示されます。CRACIのインベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかを、グローバルに正確に把握できます。

ビルド後も、CRACIは監視対象のSBOMを再評価し続け、ビルドやリポジトリをまたいで脆弱性を集約し、VEXに対応し、API経由でSBOM、ネットワークトレース、来歴を返し、SBOMをCycloneDXまたはSPDXのファイルとしてエクスポートします。ベンダーのSBOMも追加できるため、購入したコンポーネントも自社のビルドと並べて監視できます。企業がより広範なCRAコンプライアンスのプロセスで必要とする、ソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。機能の全体像はCRACIのSBOM生成をご覧ください。

つまりCRACIは、自社でビルドするソフトウェアについて、生成ツールと管理ツールの役割を兼ねます。次のような場合には適していません。

• 自社でビルドしていないイメージやソフトウェアのSBOMが必要な場合（SyftやTrivyなどの生成ツールをご利用ください）
• 製品やサプライヤーのポートフォリオ全体にわたって多様なルールを扱える成熟したポリシーエンジンが必要な場合（管理ツールをご利用ください）
• パイプラインがGitHub Actions以外で動作している、WindowsやmacOS上で動作している、またはセルフホストが必須である場合（いずれもCRACIのロードマップに掲載）

判断する最も手早い方法は、並べて比較することです。デモを予約し、ワークフローの1つをCRACIで実行して、そのSBOMを現在のツールが作成するSBOMと並べてみてください。

あわせてSCAツールの比較、AI生成SBOMとビルド時SBOMの比較、ビルド時SBOMとスキャンによるSBOMの違いもご覧ください。

SBOMツール：よくあるご質問

SBOMツールとは何ですか？

SBOMツールは、ソフトウェア部品表（SBOM）を作成または管理するツールです。SBOMは、ソフトウェアに含まれるコンポーネント、ライブラリ、依存関係を機械可読形式で列挙したものです。Syft、Trivy、cdxgenなどの生成ツールは、ファイルを読み取ってSBOMを作成します。Dependency-Track、FOSSA、Anchore Enterpriseなどの管理ツールは、SBOMを保管し、脆弱性データと照合し、共有します。CRACIはビルドの実行中にSBOMを記録し、その後も監視します。

おすすめの無料SBOMツールは何ですか？

何を対象にするかによります。SyftとTrivyは、コンテナイメージとファイルシステム向けの無料のApache-2.0ライセンスの生成ツールです。cdxgenはソースとイメージからCycloneDXを作成します。Microsoft SBOM Toolはビルド出力フォルダーのSPDXを作成します。OWASP Dependency-Trackは、これらのツールが作成したSBOMを管理する、無料のセルフホスト型の管理ツールです。

SyftとTrivyのどちらを使うべきですか？

SyftはSBOM生成に特化しており、脆弱性の照合にはGrypeと組み合わせて使います。Trivyはより幅広いスキャナーで、IaCの設定ミス、シークレット、ライセンスも検出し、その過程でCycloneDXやSPDXも出力します。どちらも目の前にあるファイルを読み取るため、ロックファイルやインストール済みパッケージが存在することが前提になります。

CycloneDXとSPDX、どちらのSBOM形式を使うべきですか？

どちらもオープンで広くサポートされている標準です。CycloneDXはOWASPのプロジェクトで、Ecma InternationalによりECMA-424として標準化されており、脆弱性データやVEXデータも扱えます。SPDXはLinux Foundationのプロジェクトで、国際標準ISO/IEC 5962:2021です。顧客や下流のツールが求める形式を使ってください。ほとんどの生成ツールは両方に対応しています。

同じプロジェクトでもSBOMツールによって結果が異なるのはなぜですか？

どのファイルを信頼し、何をコンポーネントとみなすかは、生成ツールごとに異なります。ロックファイルを読むもの、インストール済みパッケージを読むもの、バイナリを読むものがあり、ロックファイルのないリポジトリでは、ロックファイルを読むツールには手がかりがありません。スキャンによるSBOMは、ツール、その設定、スキャン前に依存関係がインストールされていたかどうかに左右されます。ビルド時SBOMは、ビルドが実際に取得したものを記録することで、この問題を回避します。

Cyber Resilience Actは特定のSBOMツールや形式を求めていますか？

いいえ。CRAの附属書I第II部は、製造者に対し、少なくとも製品のトップレベルの依存関係を対象とするソフトウェア部品表を、一般的に使用される機械可読形式で作成するよう求めています。CycloneDXとSPDXはどちらも該当します。同規則は特定のツールを指定していません。

CRACIは自社でビルドしていないソフトウェアのSBOMを生成できますか？

いいえ。CRACIは自社のランナー上で実行されるビルドを記録するため、そのSBOMはお客様がビルドするソフトウェアを記述します。購入したソフトウェアについては、ベンダーのSBOMをCRACIに追加し、自社のビルドと並べて監視できます。自社でビルドしていないサードパーティのコンテナイメージには、SyftやTrivyなどのスキャナーが現実的な選択肢です。

CRACIはどのCIシステムに対応していますか？

現時点ではGitHub Actionsに対応しており、Linux x86-64とARM64のランナーで動作します。runs-onをcraciに変更するだけで、実行結果は引き続きGitHubに表示されます。GitLab CIとJenkinsをはじめとする他のCIシステムはロードマップに掲載されています。