SBOMツールの結果はなぜ異なる？最新研究が明かす「SBOM混乱の脆弱性」
公開日
%20before%20and%20(b)%20after%20running%20sbomvert.DMIOIDIi_ZHqLb9.jpg)
ソフトウェアサプライチェーンセキュリティの要として、SBOM（Software Bill of Materials / ソフトウェア部品表）への注目が世界的に高まっています。しかし、いざSBOMツールを導入してみると、「ツールによって検出される脆弱性の結果が違う」「どのツールの結果を信じれば良いのか分からない」といった新たな課題に直面するケースは少なくありません。
本記事では、この「ツールによる結果のズレ」問題の深層を、最新の学術研究に基づき解き明かします。2025年10月に公開された論文「SBOMproof: Beyond Alleged SBOM Compliance for Supply Chain Security of Container Images」を元に、なぜSBOMツール間で結果に差異が生まれるのか、その原因と深刻な影響、そして新たなセキュリティリスクについて詳しく解説します。
SBOM導入で直面する「ツールによる結果のズレ」という課題
ソフトウェアサプライチェーンへの関心の高まりを背景に、コンテナイメージに含まれるソフトウェアコンポーネントの脆弱性を検出する目的で、様々なSBOMツールが利用されています。しかし、異なるツールで同じコンテナイメージをスキャンした際に、報告されるパッケージのリストや脆弱性の数が一致しない、という経験はないでしょうか。この一貫性の欠如は、脆弱性管理の信頼性を損ない、セキュリティ対策の優先順位付けを困難にする深刻な問題です。
大規模調査で明らかになったSBOMツールの実態
この問題の根源を探るため、研究チームはコンテナイメージのSBOMに関する大規模な調査を実施しました。調査では、Amazon Inspector, Syft, Grype, Docker Scout, Trivyといった、広く利用されているオープンソースおよび商用のSBOM生成・脆弱性スキャンツールが評価対象とされました。データセットには、主要なLinuxディストリビューションであるDebianとAlpineの全パッケージ、およびDocker Hubで人気の高いコンテナイメージが使用され、各ツールの挙動が詳細に比較分析されています。
なぜ結果がズレるのか？多くのツールが軽視する「2つの標準仕様」
調査の結果、ツール間の結果がズレる根本的な原因は、多くのツールがSBOMの「標準仕様」に完全には準拠していないことにあると明らかになりました。特に問題となっているのが、「pURL」と「SPDX」という2つの仕様の扱いです。
パッケージの住所録「pURL」の不統一問題
pURL（Package URL）は、ソフトウェアパッケージをOS、名前、バージョン、アーキテクチャなどの情報を含めて一意に識別するための標準化された形式です。いわば、個々のソフトウェアパッケージに与えられた「世界共通の住所録」のようなものです。脆弱性データベースと正確に照合するためには、このpURLが正しく、かつ統一された形式で記述されていることが不可欠です。
しかし、調査対象となったツールは、このpURLの生成方法にそれぞれ独自の実装を用いており、互換性がほとんどないことが判明しました。図表1は、各ツールが生成したpURLがどれだけ似ているかをJaccard係数（0から1の値で、1に近いほど似ている）で示したものですが、多くのツール間で値が0に近く、全く互換性がないことを示しています。
図表1 ツール間で生成されたpURLの類似度（Jaccard係数）。値が1に近いほど類似度が高いが、多くのツール間で0となっており、互換性がないことを示している。
SBOMの構造形式「SPDX」の独自解釈問題
SPDX（Software Package Data Exchange）は、SBOMを記述するための標準フォーマットの一つです。パッケージ名やバージョン、ライセンス情報などをどのような構造で記述するかが定められています。
しかし、一部のツールはこのSPDXフォーマットを独自に拡張したり、本来pURLに含めるべき情報を別のオプションフィールドに記述したりしていました。その結果、pURLだけを見てもパッケージを正確に特定できず、そのツール独自のフィールドを解釈しなければ脆弱性を正しく検出できない、という状況が生まれています。これは、異なるツール間でSBOMデータを交換する際の大きな障害となります。
標準仕様の軽視が引き起こす3つの深刻な影響
pURLやSPDXといった標準仕様がツールごとにバラバラに扱われることは、単なる「表記揺れ」では済みません。脆弱性管理の現場において、以下の3つの深刻な影響をもたらします。
影響1：検出されるパッケージ数がツールごとに違う
そもそも、SBOMの元となるコンテナイメージから検出されるパッケージの総数自体が、ツールによって異なる場合があります。これは、ツールがコンテナのどのレイヤーを分析対象とするか、また、バイナリパッケージとソースパッケージをどのように扱うか、といった実装の違いに起因します。パッケージのリストが不正確であれば、その後の脆弱性スキャンが正確であるはずがありません。
影響2：無関係な脆弱性まで報告されるノイズ
コンテナはホストOSのカーネルを共有して動作するため、コンテナイメージ内にカーネル関連のヘッダファイル等が含まれていたとしても、通常はコンテナ自体の脆弱性にはなりません。しかし、一部のツールはこれらのファイルにも反応し、無関係なカーネルの脆弱性（CVE）を大量に報告してしまうことがあります。図表2を見ると、ツールによって報告される脆弱なパッケージ数やCVEの総数に大きなばらつきがあることが分かります。このようなノイズは、本当に対応すべき脆弱性の特定を妨げる原因となります。
| ツール名 | 総パッケージ数 | 脆弱なパッケージ数 | 総CVE数 | ユニークCVE数 |
|---|---|---|---|---|
| Amazon | 80,608 | 49 | 576 | 574 |
| Anchore | 63,461 | 3,998 | 30,577 | 2,725 |
| Docker | 82,619 | 507 | 1,370 | 1,292 |
| Gcloud | 63,461 | 853 | 2,675 | 2,468 |
| Microsoft | 69,006 | 9 | 203 | 203 |
| Trivy | 63,461 | 3,975 | 35,650 | 2,922 |
※各ベンダー名は、論文で評価された主要ツール群（Amazon Inspector, Anchore Grype, Google Artifact Analysisなど）を指します。
図表2 脆弱性スキャンツールごとの検出パッケージ数とCVE数の比較。ツールによって検出される脆弱なパッケージ数やCVE数に大きなばらつきがある。
影響3：脆弱性の見逃し（偽陰性）と誤検出（偽陽性）
最も深刻な影響が、脆弱性の見逃し（偽陰性）と誤検出（偽陽性）です。パッケージの識別情報が不正確であるために、本来検出されるべき脆弱性が見逃されたり、逆に対応済みのはずの脆弱性が未対応として報告されたりします。
図表3は、各ツールの脆弱性検出性能を示したものです。特に、脆弱性を見逃してしまう「偽陰性」において、ツールによって数百から数千単位の大きな差が生じていることが分かります。脆弱性の見逃しは、サイバー攻撃の機会を攻撃者に与えることに直結する、極めて危険な状態です。
| ツール名 | 真陽性 | 偽陽性 | 偽陰性 |
|---|---|---|---|
| Amazon | 178 | 15 | 2,323 |
| Anchore | 2,227 | 31 | 274 |
| Docker | 1,226 | 66 | 1,275 |
| Gcloud | 2,426 | 42 | 75 |
| Microsoft | 6 | 197 | 2,495 |
| Trivy | 2,432 | 41 | 69 |
図表3 各ツールの脆弱性検出性能。偽陽性と偽陰性の数にツール間で大きな差が見られる。
新たなセキュリティリスク「SBOM confusion vulnerability」
研究チームは、このようなツール間の非互換性が生み出す問題を、単なるツールの品質問題ではなく、「SBOM confusion vulnerability（SBOM混乱の脆弱性）」 という新たなセキュリティ上の脆弱性であると提唱しています。
これは、サプライチェーンを跨いでSBOMがやり取りされる際、ツール間の非互換性が原因で脆弱性が全く検出されなくなるリスクを指します。図表4の(a)がその危険性を明確に示しており、 異なるツールを組み合わせると（対角線以外の数値）、同じツールを使った場合（対角線上の数値）に比べて脆弱性の検出数が激減し、多くの組み合わせで「0」になっています。 これは脆弱性が完全に隠蔽されることを意味し、意図的な攻撃ではなく、現在のSBOMエコシステム自体が抱える構造的な脆弱性なのです。
%20before%20and%20(b)%20after%20running%20sbomvert.avif)
図表4 あるツールで生成したSBOMを別のツールでスキャンした際の脆弱性検出数。(a)は変換前で、多くの組み合わせで脆弱性が検出できていない。(b)はsbomvertで変換後で、検出数が大幅に改善している。
ツール間の非互換性を乗り越える翻訳ツール「sbomvert」
この「SBOM混乱の脆弱性」を緩和するため、研究チームはオープンソースのツールsbomvertを開発しました。sbomvertは、あるツールが生成したSBOM（SPDX形式）を、別のスキャンツールが正しく解釈できる形式に変換する「翻訳レイヤー」として機能します。各ツールのpURLの生成ルールやSPDXの独自フィールドの癖を吸収し、ツール間の相互運用性を向上させます。
図表4の(b)は、sbomvertを適用した後の結果です。変換前(a)では大半が0だったのに対し、変換後(b)では多くの組み合わせで脆弱性が正しく検出されるようになり、検出数が大幅に改善していることが明らかです。これは、ツール間の非互換性が技術的に解決可能であることを示唆しています。
まとめ：SBOMの精度を高め、サプライチェーンを守るために
今回の研究は、広く使われているSBOMツールが、標準仕様への準拠という点で大きな課題を抱えており、その結果として脆弱性管理の信頼性が損なわれている実態を明らかにしました。SBOMはソフトウェアサプライチェーンセキュリティを強化する上で非常に強力な手段ですが、決して万能な解決策ではありません。
私たち利用者は、SBOMがツール間の非互換性という「SBOM混乱の脆弱性」を内包している可能性を認識する必要があります。そして、ツールを選定・運用する際には、以下の点を考慮することが重要です。
- 単一のエコシステムを利用する: 可能であれば、SBOMの生成から脆弱性スキャンまで、同じベンダーが提供するツール群（例：Anchore社のSyftとGrype）で統一することで、非互換性のリスクを低減できます。
- ツールの仕様を理解する: 利用するツールがpURLやSPDXをどのように扱っているか、その特性や限界を理解した上で結果を解釈することが求められます。
- 継続的な情報収集: SBOMを取り巻く技術や標準化の動向は日々変化しています。
sbomvertのような新しいソリューションや、今後の標準化の進展に注目していくことが重要です。
SBOMの真の価値を引き出すためには、ツールベンダーによる標準仕様への準拠が進むとともに、利用者側もツールの特性を深く理解し、賢く使いこなしていく姿勢が不可欠です。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: