この記事はビギナーズ Advent Calendar 2025の17日目の記事です。
はじめに
近年、ソフトウェア開発において「SBOM（Software Bill of Materials）」という言葉を耳にする機会が増えてきました。SBOM は「ソフトウェアの部品表」のようなもので、どんな部品（ライブラリ）が使われているかを一覧にしたものです。セキュリティや品質管理の面で、重要な役割を持ちます。
とはいえ、いざ SBOM を作ってみると、ツールによって中身がまったく違うことがあります。
その問題意識の高まりを受けて、米国CISA（Cybersecurity and Infrastructure Security Agency）・カーネギーメロン大学・SBOMの標準団体らによって2024年に開催されたのが、「SBOM Harmonization Plugfest」 という国際的な取り組みです。これは、各ベンダーや開発者がそれぞれのツールで生成した SBOM を持ち寄り、その互換性や表現の違いを比較・検証する試みです。分析の結果は2025年7月に公開されました。
この記事では、その Plugfest で議論された内容を紹介するとともに、私自身が実際に Trivy、Syft、Black Duck といった代表的なツールを使って SBOMを作成し、その結果を比較してみたプロセスもあわせてまとめました。
こうした実験を通じて、「SBOM はなぜ揃わないのか」「どこに差が生まれるのか」を具体的に見ていきたいと思います。
想定読者
- SBOMについてなんとなく聞いたことがある人
- 作成ツール間でどんな違いがあるのか気になる人
- SBOMについての国際的な動向を知りたい人
前提知識
SBOMとは何か
SBOMとは、Software Bill of Materialsの略称で、1つのアプリケーションを構成するすべてのコンポーネント、ライブラリ、依存関係、バージョン、ライセンスなどを一覧化したものです。近年SBOMが注目されているのは、サプライチェーン攻撃の増加や脆弱性対応の高度化により、「自分たちが何を使っているか」を正確に把握する必要性が急速に高まっているためです。SBOMがあれば、脆弱性が見つかった際に影響範囲をすぐに特定でき、リスク管理やコンプライアンス対応を効率化できます。
SBOMにはどんな課題があるのか
SBOMは有用である一方で、現在の実務ではいくつかの課題も存在します。代表的なのは、ツールごとに生成されるSBOMの形式や粒度、依存関係の解釈が大きく異なる点です。
同じソースコードから SBOMを作っても、ツールによって「含まれるコンポーネント数が違う」「バージョン表記が揃わない」「依存関係の階層が一致しない」といった差分が生じ、取り扱いに注意が必要となります。
こうした「ツール間の不整合」を解消し、SBOMをより実用的にするため、国際的に比較・検証する取り組みとして SBOM Harmonization Plugfest が開催されました。次章では、その内容と議論されたポイントを解説します。
SBOM Harmonization Plugfestでの実験
SBOM Harmonization Plugfest では、「同じソフトウェアでも、作成する人やツールによって SBOM がどれだけ変わるのか？」を確かめるために、さまざまな比較検証が行われました。参加者は共通のターゲットソフトウェア（全9種）に対して SBOM を作成し、その内容を持ち寄りました。詳細な条件は以下に示す通りです。
- 参加者: 21組織、243件のSBOMを提出
- 対象ソフトウェア: NodeJS-goof, HTTPie, MineColonies, OpenCV, Gin, Hexyl, Dependency-Track, PHPMailer, jq の9種類
- SBOM形式: 主にCycloneDXとSPDX、JSON形式が中心（XML/YMLは少数）
- 種類:
- Source SBOM：ソースコードを対象に生成したSBOM。
- Build SBOM：実際に HTTPie をビルドし、ビルド環境に存在するOSライブラリやPythonランタイムを含むSBOM。
Plugfestの主な発見
- （全体を通じて）SBOM には著しいばらつきがある。
- 宣言された依存関係に基づくSource SBOM と、実際のビルド環境に依存する Build SBOM は本質的に異なる。
- Minimum Elements（最小要素）の充足率が低い。特に充足率が低かったのは、Licenses, Cryptographic Hash、SBOM Authorである。
- 依存関係の扱いに不統一性がある。どこまでの依存関係を含めるかに統一基準がない。加えて、プログラミング言語ごとの依存管理の違いが揺らぎを加速させた。
- 正規化（Normalization）が必須である。例えば、バージョン表記では“v2.0”, “2.0.0”,“2.0”といった表記揺れがある。
- SBOM 生成ツール間で大きな挙動差がある。依存の検出方法や走査の対象がツールによって異なる。
そこで、このような結果が自身の環境でも再現されるのかどうかを実際にSBOMを作成して試してみました。
実際にSBOMを作って内容を解析してみた
検証の狙い
本検証では、Source SBOM と Build SBOMの差異 、および SBOM生成ツール間の差異を確認することを目的としています。比較の軸として、最もわかりやすく、差が出やすい指標として、コンポーネント数に着目します。
検証の方法
対象ソフトウェア
検証の対象として、Python製のコマンドラインツールである、HTTPieを選択しました。
HTTPieはREST APIなどのテストに利用される代表的な CLI ツールであり、
- Python による依存管理が複雑
- Source SBOMとBuild SBOMの差異が出やすい
という理由から選択しました。
本検証で使用した HTTPie のソースコードは、次のコミットから取得しています：
使用したSBOM生成ツール
SBOMの作成には、以下の3種類のツールを用いました。
- Syft（Anchore, v1.37.0）
- Trivy（Aqua Security, v0.67.2）
- Black Duck SCA（Black Duck, v2025.7.1）
SBOM生成条件
SyftのSBOM作成にはsyft dir:./httpie -o cyclonedx-json を、
Trivy の SBOM 作成には trivy fs --format cyclonedx --output sbom.json を使用しました。
Black Duckは、Black Duck DetectのオフラインスキャンでBDIOファイルを生成し、Black DuckサーバーにアップロードしてSBOMを作成しました。
各ツールでSource SBOMとBuild SBOMを生成し、合計6種類のSBOMを得ました。
結果
作成したSBOMのコンポーネント数を比較したところ、以下のような差が見られました。
| ツール | Source SBOM | Build SBOM |
|---|---|---|
| Syft | 33 | 65 |
| Trivy | 0 | 21 |
| Black Duck | 42 | 41 |
各ツールで生成した Source SBOM と Build SBOM のコンポーネント数を比較したところ、Source SBOM と Build SBOM では構成要素数に明確な差が見られました。また、ツール間でも依存関係の検出結果が大きく異なることが確認できました[1]。
考察
Source SBOMとBuild SBOMの違い
本検証では、Source SBOM と Build SBOM の間でコンポーネント数に明確な差異が生じました。
- Syft は、Build SBOM のコンポーネント数が Source SBOM よりも大幅に増加しています。これは ビルド環境に存在する Python ランタイムや OS パッケージなどが追加で検出されるためです。
- Trivyは、Source SBOMが0件となりました。 Trivy はファイルシステムスキャン時、既知の依存ファイル（例：requirements.txt / Pipfile.lockなど）や「インストール済みパッケージ（wheel/egg 等）」からライブラリを検出して SBOM を組み立てます。しかし、該当ファイルが見当たらない場合、もしくは動的な setup.py / setup.cfg しか無い場合、検出対象が無く、0件になります。今回の検証の条件では、setup.py / setup.cfg しか無かったため、0件となりました。ただし、仮想環境を作ってrequirements.txtを用意したBuild SBOMでは、21件のコンポーネントが検出されています。
- Black Duckは、Source SBOM（42件）と Build SBOM（41件）が同程度となりました。差分の1件は、ファイルの構造に依存するもので、Source SBOMとBuild SBOMにかかわらず、同等の要素が安定して取れています。
SBOM生成ツール間での違い
各ツールで作成した、Build SBOMのコンポーネントを比較することで、ツールごとの特徴を整理します。
- Syftは、コンポーネント数が65で最多でした。しかし、重複が多く、実質的なコンポーネント数は47でした。環境の情報をなるべく多くとりたい場合には有利ですが、その分ノイズも多くなるのが特徴です。
- Trivyは、コンポーネント数が21と最小でした。重複がなく軽量であり、識別子であるPURLや依存関係の情報も保持しているため、シンプルにPythonの依存関係を把握することができます。一方で、ライセンス情報やsupplier情報は未記載となっています。
- Black Duckは、コンポーネント数が41でした。重複がなく、すべてに識別子であるPURL、ライセンス、supplierの情報がそろっています。加えて、固有の特徴として、PURLがapk, rpm, GitHubなどの複数のエコシステムにまたがっているため、OSパッケージレベルのアドバイザリや、GitHubのセキュリティ情報といった多様な情報源へつなげやすい設計となっています。以上から、作成した中では、最もセキュリティ・コンプライアンスの観点で実務に使えるSBOMとなっていると考えられます。
この結果を受けてのCISAの動き
この結果を受けて、Plugfest主催者であるCISAは、2025年8月に、SBOMの最小構成要素についての新たなガイドラインを公開しました。ガイドラインでは、最小構成要素の名称変更や、要素の新規追加が議論されています。
その中で、新規の要素として
- Tool Name：SBOM生成に使用したツール名
- Generation Context：生成時点でのライフサイクルフェーズを明示
が追加されています。今回の検証で、ツール名や生成時のタイミングによって結果が変わりうるということを認識したために、新たな最小要素としてこれらが追加されたと推測できます。
まとめ
この記事では、SBOM Harmonization Plugfestでの発見結果を紹介するとともに、実際に自分でもSBOMを作ってみて、ツールやSBOMの種類でどのような違いが生まれるのかを検証しました。実験を通じて改めて明らかになったのは、「SBOMはツールを変えるだけで内容が大きく変わる」ということです。ツールごとに依存関係の解析手法や対象範囲が異なるため、同じソースコードから生成した SBOM であっても粒度・検出数・構造が大きく変化します。また、Source SBOM と Build SBOM の間にも明確な差があり、目的に応じて適切な SBOM を選択する必要性があることが分かりました。また、今回の検証結果は、CISAの最小構成要素にも影響しています。
参考文献
Software Engineering Institute（CMU）「SBOM Harmonization Plugfest 2024」（2024年11月19日） Software Engineering Institute（CMU）「Software Bill of Materials (SBOM) Harmonization Plugfest 2024」（2025年7月17日） Cybersecurity and Infrastructure Security Agency（CISA）「2025 Minimum Elements for a Software Bill of Materials (SBOM)」（2025年8月22日）
-
Plugfestで実際に提出されたSBOMの一部を確認したところ、コンポーネント数について、今回生成したものと同程度になっていたため、作成のプロセスは妥当だと考えられます。 ↩︎
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。