GitHubのSBOM普及率は僅か0.56%？最新研究が暴くサプライチェーンの脆弱性とライセンス管理の課題
公開日
近年、SolarWinds事件やLog4jの脆弱性（Log4Shell）など、ソフトウェアのサプライチェーンを狙った攻撃が深刻化しています。こうした脅威に対抗する切り札として、「SBOM（Software Bill of Materials：ソフトウェア部品表）」への期待が高まっています。しかし、その導入や活用は本当に進んでいるのでしょうか？
本記事では、スウェーデンのBlekinge工科大学の研究者たちが発表した論文「POLICY-DRIVEN SOFTWARE BILL OF MATERIALS ON GITHUB: AN EMPIRICAL STUDY」に基づき、オープンソースソフトウェアにおけるSBOMの利用実態を深掘りします。GitHub上の人気プロジェクトを対象としたこの大規模調査から見えてきた、SBOM活用の理想と厳しい現実を解説します。
ソフトウェアの「成分表示」、SBOM（ソフトウェア部品表）とは？
SBOMとは、食品のパッケージに記載されている「原材料表示」のようなものです。あるソフトウェアが、どのようなコンポーネント（ライブラリ、モジュール、フレームワークなど）から構成されているかを一覧にした、機械判読可能なリストを指します。
なぜSBOMがなければ、Log4jのような脆弱性に対応できないのか
2021年に発覚したLog4jの脆弱性は、世界中のシステムに影響を与えました。この時、多くの組織が直面した課題は「自分たちのシステムが、脆弱性のあるバージョンのLog4jを利用しているか迅速に特定できない」ことでした。もし正確なSBOMがあれば、依存関係ツリーを素早く分析し、影響範囲を特定して、迅速なパッチ適用やリスク軽減策を講じることができたはずです。
このような背景から、米国政府が政府機関の調達要件にSBOMを義務付けたり、EUでサイバーレジリエンス法（CRA）が検討されたりと、SBOMの導入は世界的な潮流となりつつあります。
本記事の根拠：Blekinge工科大学による「ポリシー駆動SBOM」大規模調査
この記事で紹介するデータは、Blekinge工科大学の研究チームが実施した実証的研究に基づいています。この研究では、単に存在するだけでなく、セキュリティ目標（透明性の向上やコンプライアンス確保など）を達成するために意図的に作成された「ポリシー駆動SBOM」に焦点を当てています。
調査概要：人気OSSプロジェクト26,823件のSBOMを徹底分析
この調査は、GitHub上でスター数の多い人気プログラミング言語のリポジトリ26,823件を対象に、2025年4月時点のデータを用いて行われました。研究チームは、これらのリポジトリからポリシー駆動のSBOMファイルを収集・抽出し、その普及率、フォーマット、品質、そしてSBOMに記載された依存関係が抱える脆弱性やライセンス情報を詳細に分析しました。
SBOM利用の厳しい現実①：普及率はわずか0.56%
調査によって明らかになった最初の現実は、SBOMの普及率の低さです。調査対象となった26,823件の人気リポジトリのうち、ポリシー駆動のSBOMを含んでいたのはわずか152件（0.56%）でした。SBOMの重要性が叫ばれる一方で、オープンソースの世界ではまだ導入がほとんど進んでいないことが示されました。
主流フォーマットはSPDXとCycloneDXだが…
利用されているSBOMのフォーマットは、SPDX（336ファイル）とCycloneDX（284ファイル）の2つが主流でした。これらは業界標準として広く認知されています。
最新バージョンは敬遠？互換性リスクの懸念
しかし、そのバージョンに目を向けると課題が見えてきます。下の表が示すように、SPDXフォーマットでは最新のバージョン3.0が全く使われておらず、多くは一つ前のバージョン2.3を利用していました。CycloneDXでも、最新バージョン1.6の利用は限定的です。
図表1: 取得されたSBOMファイルのフォーマットとバージョン
| フォーマット | バージョン | SBOM数 | フォーマット | バージョン | SBOM数 |
|---|---|---|---|---|---|
| CycloneDX | 1.6 | 97 | SPDX | 3.0 | 0 |
| 1.5 | 51 | 2.3 | 278 | ||
| 1.4 | 71 | 2.2 | 54 | ||
| 1.3 | 59 | 2.1 | 4 | ||
| 1.2 | 5 | ||||
| 1.1 | 0 | ||||
| 1.0 | 1 |
古いバージョンのフォーマットを使い続けることは、将来的にツール間の互換性の問題を引き起こす可能性があります。
SBOM利用の厳しい現実②：品質は悪くないが、中身はリスクだらけ
次に、SBOMの「品質」と、そこに記載されている「中身」を見ていきましょう。
SBOMの品質自体は平均7/10点と高評価
驚くべきことに、数は少ないものの、作成されているSBOMの品質は決して低くありませんでした。NTIA（米国電気通信情報局）が推奨する項目（コンポーネント名、バージョン、提供元など）がどの程度網羅されているかを評価したところ、品質スコアの平均は10点満点中7.07点と、比較的良好な結果でした。
図表2: SBOM品質スコアのフォーマット別概要
| CDX (JSON) | CDX (XML) | SPDX (JSON) | SPDX (tag) | SPDX (YAML) | Total | |
|---|---|---|---|---|---|---|
| 中央値 | 6.95 | 8.17 | 7.36 | 6.09 | 8.17 | 7.32 |
| 平均値 | 6.99 | 7.61 | 7.16 | 6.65 | 8.17 | 7.07 |
この結果は、SBOMを作成しているプロジェクトは、その重要性を理解し、質の高いものを作成しようと努力していることを示唆しています。しかし、問題はその中身にありました。
課題1：多数の「中〜高深刻度」の脆弱性が未修正のまま
SBOMに記載された依存関係を分析したところ、多くの脆弱性が未修正のまま残されていることが判明しました。下の表は、見つかった脆弱性を深刻度別に集計したものです。
図表3: SBOMの依存関係で見つかった脆弱性の深刻度別サマリー
| Critical | High | Medium | Low | Total | |
|---|---|---|---|---|---|
| 平均値 | 0.55 | 2.65 | 3.89 | 0.51 | 7.61 |
| 最大値 | 56 | 232 | 296 | 37 | 296 |
1つのSBOMあたり平均で7.61件の脆弱性が存在し、特に危険度の高い「High」や「Medium」の脆弱性が、「Critical」なものよりも多く存在していることがわかります。これは、緊急度は最高レベルではないと判断された脆弱性の修正が後回しにされ、結果として多くのリスクが放置されている状況を示しています。
課題2：22%がライセンス情報なし。コンプライアンス上の大きな穴
もう一つの重大なリスクは、ライセンスコンプライアンスに関するものです。調査対象となったSBOMのうち、実に139ファイル（22.41%）で、依存関係に関するライセンス情報が一切報告されていませんでした。オープンソースソフトウェアを利用する上で、各コンポーネントのライセンスを遵守することは法的な義務ですが、そのための基本情報が欠落しているケースが多いのです。これはコンプライアンス上の大きな穴と言えます。
一方で、ライセンス情報が報告されているSBOMでは、下のグラフが示すように、Apache-2.0とMITという寛容なライセンスが全体の約70%を占めていました。しかし、多様なライセンスが混在することも事実であり、ライセンスの非互換性といった問題を防ぐためにも、正確なライセンス情報の記載は不可欠です。
図表4: ポリシー駆動SBOMにおけるライセンスの出現頻度
まとめ：SBOMの現実と向き合い、開発者が今すぐ取り組むべきこと
今回の調査は、ソフトウェアサプライチェーンセキュリティの文脈で重要視されるSBOMが、オープンソースの世界ではまだ黎明期にあることを明らかにしました。普及率は1%にも満たず、バージョン管理にも課題を抱えています。
一方で、作成されているSBOMの品質自体は高いものの、その中身には「未修正の脆弱性」と「ライセンス情報の欠如」という2つの重大なリスクが潜んでいることも判明しました。SBOMは、ただ作成するだけでは意味がありません。そこに記載された情報を基に、脆弱性に対応し、ライセンスを遵守して初めて、その価値を発揮します。
この研究結果は、開発者やセキュリティ担当者、そしてマネージャーにとって、自社のソフトウェアサプライチェーン管理を見直す良い機会となるはずです。まずは自社製品のSBOMを作成し、そこにどのようなリスクが潜んでいるのかを可視化することから始めてみてはいかがでしょうか。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: