公開日
SBOM採用の現実は？OSSプロジェクト186件の調査で分かった3つの品質課題
ソフトウェアサプライチェーン攻撃のリスクが高まる中、その対策の切り札として「ソフトウェア部品表（SBOM）」への注目が集まっています。SBOMがあれば、ソフトウェアを構成するコンポーネントを正確に把握でき、脆弱性の発見やライセンス管理を迅速化できると期待されています。しかし、その理想とは裏腹に、実際の導入現場、特にオープンソースソフトウェア（OSS）の世界では、SBOMは本当に有効活用されているのでしょうか。
本記事では、OSSプロジェクトにおけるSBOM採用の実態を明らかにした学術論文「On the adoption of software bill of materials in open-source software projects」（2025年）の調査結果に基づき、SBOM採用の「理想と現実」を深掘りします。GitHub上の186プロジェクトの分析から見えてきた、知られざる課題を見ていきましょう。
調査概要：OSSプロジェクト186件のSBOMを徹底分析
本記事で紹介する内容は、研究者たちがGitHub上で公開されているOSSプロジェクトを対象に行った、大規模なマイニング調査に基づいています。
調査チームは、GitHubの依存関係グラフ（Dependency Graph）を使い、2023年3月5日時点で主要なSBOM標準である「SPDX」と「CycloneDX」の公式SBOM生成ツールに依存している公開リポジトリをリストアップ。そこから、活動が停止しているものやフォーク、小規模な個人プロジェクトなどを除外した 186件のOSSプロジェクトを分析対象として特定しました。 これらのプロジェクトが、どのようにSBOMを生成し、配布し、そしてどのような情報を記載しているのかを詳細に分析しました。
SBOM採用の「理想と現実」：採用は増えるも、半数でファイルが見つからない
調査から見えてきた最初の現実は、SBOMの採用が徐々に広がりを見せている一方で、その管理方法には大きな課題があるという点です。
論文によると、SBOM生成ツールの採用は、特に米国政府がSBOMの提出を義務化する大統領令を発令した2021年以降、顕著な増加傾向にあります。
図表1. SBOM生成ツールの採用数の推移
図表1が示すように、SBOMへの関心と導入の動きが加速していることは明らかです。
しかし、問題はここからです。ツールを導入しているプロジェクトのうち、 実際に生成されたSBOMファイルがバージョン管理下にある、または公開リリース版に含まれていたのは、全体のわずか46% でした。つまり、残りの半数以上（54%）のプロジェクトでは、SBOMがどこで配布されているのか追跡できなかったのです。
これは、「SBOMがあるはず」と思っていても、利用者側がそれを簡単に入手できないという大きな課題を示唆しています。せっかくSBOMを生成しても、それが利用者に届かなければ意味がありません。
SBOMの「中身」に潜む3つの課題：あなたのSBOMは大丈夫？
さらに深刻なのは、入手できたSBOMの「中身」、つまり品質の問題です。調査からは、現在のSBOMが持つ3つの大きな課題が浮き彫りになりました。
課題1：9割が必須項目不足？NTIA要件を満たしていない
SBOMに記載すべき情報の基準として、米国電気通信情報庁（NTIA）が定めた「最小要件」があります。これは、コンポーネントを追跡・識別するために最低限必要な情報（サプライヤー名、コンポーネント名、バージョンなど）を定義したものです。
しかし、驚くべきことに、 分析対象となったSBOMのうち、この最小要件をすべて満たしていたものは、全体のわずか7% しかありませんでした。実に9割以上のSBOMが、基礎的な情報すら網羅していなかったのです。
図表2. NTIA最小要件の各項目における記載率
| データ項目 | 記載数 | 記載率 |
|---|---|---|
| その他のユニークな識別子 | 119 | 100% |
| SBOMデータの作成者 | 117 | 98% |
| タイムスタンプ | 116 | 97% |
| コンポーネント名 | 110 | 92% |
| コンポーネントバージョン | 110 | 92% |
| 依存関係 | 108 | 91% |
| サプライヤー名 | 8 | 7% |
図表2を見ると、特に 「サプライヤー名」の記載率が7%と著しく低い ことが分かります。誰がそのコンポーネントを提供しているのかが分からなければ、脆弱性発生時の問い合わせやリスク評価が困難になります。
さらに、NTIAが定める「推奨要件」（コンポーネントハッシュ、ライセンス情報など）に目を向けると、状況はさらに深刻です。
図表3. NTIA推奨要件の各項目における記載率
| データ項目 | 記載数 | 記載率 |
|---|---|---|
| ライセンス情報 | 60 | 50% |
| コンポーネントハッシュ | 45 | 38% |
| 他のコンポーネント関係 | 30 | 25% |
| ライフサイクルフェーズ | 0 | 0% |
コンポーネントの完全性を検証するための 「コンポーネントハッシュ」は38% 、法務リスクを判断する上で不可欠な 「ライセンス情報」ですら50% のSBOMにしか含まれていませんでした。そして、ビルド前の情報かビルド後の情報かを示す 「ライフサイクルフェーズ」に至っては、記載はゼロ でした。これでは、SBOMが持つ本来の価値を十分に発揮できません。
課題2：標準規格への不適合
SBOMには、SPDXやCycloneDXといった標準規格が存在します。これらの規格に準拠することで、ツール間での相互運用性が保たれ、自動処理が可能になります。
調査によると、分析対象のSBOMの約12%が、準拠を宣言しているにもかかわらず、実際にはその規格に適合していませんでした。特にSPDX形式のSBOMでこの傾向が強く見られました。原因としては、ツールが生成するURLのフォーマットが間違っていたり、必須の属性が欠けていたりといった技術的な問題が挙げられています。
規格に準拠していないSBOMは、脆弱性スキャンツールや資産管理ツールで正しく読み込めず、エラーを引き起こす可能性があります。これもまた、SBOMの有用性を損なう大きな要因です。
課題3：ライセンスや脆弱性など、重要な情報が記載されない
最後に、SBOMの2大用途とも言える「ライセンス管理」と「脆弱性管理」に直結する情報の欠如です。
前述の通り、ライセンス情報が含まれていたSBOMは全体の半分に過ぎませんでした。これでは、OSS利用に伴うライセンス違反のリスクを正確に評価することができません。
そして最も衝撃的なのは、分析対象となった119のSBOMのいずれにも、脆弱性に関する情報が一切記載されていなかったという事実です。脆弱性情報を管理するためにSBOMを導入しようと考えている多くの組織にとって、これは看過できない問題でしょう。現状のSBOM生成ツールや運用プロセスが、脆弱性情報を自動的に付与する仕組みを十分に備えていない現実がうかがえます。
まとめ：SBOMの真の価値を引き出すために
今回の調査は、OSSにおけるSBOM採用の道のりがまだ始まったばかりであることを明確に示しました。採用は増加傾向にあるものの、
- 配布・管理方法が確立されておらず、半数以上でファイルが見つからない。
- 記載すべき必須情報が欠けており、9割以上がNTIAの最小要件を満たしていない。
- ライセンスや脆弱性といった、実用上不可欠な情報がほとんど含まれていない。
という大きな課題が山積しています。
SBOMは、単に「作れば終わり」ではありません。ソフトウェア開発者、そしてOSSを利用するすべての組織は、これらの現実を直視する必要があります。SBOMを生成する側は、正確で網羅的な情報を記載し、利用者がアクセスしやすい形で提供する責任があります。利用する側も、入手したSBOMの中身を鵜呑みにせず、その品質を検証する視点を持つことが重要です。
SBOMがソフトウェアサプライチェーンセキュリティの「切り札」となるためには、ツール、プロセス、そしてコミュニティ全体の成熟が不可欠です。この調査結果を、自社の取り組みを見直すきっかけとしてみてはいかがでしょうか。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: