一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
IEICE Technical Report

GitHub 上の OSS を対象とする SBOM データセット構築の試み
岸本 理央†

神田哲也††

眞鍋 雄貴††† 井上 克郎†††† 仇実†††††

肥後 芳樹†† 大阪大学大学院情報科学研究科 〒565–0871 大阪府吹田市山田丘 1–5†† ノートルダム清心女子大学情報デザイン学部情報デザイン学科 〒700–8516 岡山県岡山市北区伊福町 2-16-9††† 福知山公立大学情報学部情報学科 〒620–0886 京都府福知山市堀 3370†††† 南山大学理工学部ソフトウェア工学科 〒466–8673 愛知県名古屋市昭和区山里町 18††††† 株式会社東芝 デジタルイノベーションテクノロジーセンター 〒212–8582 神奈川県川崎市幸区小向東
芝町 1
E-mail: †{r-kisimt,higo}@ist.osaka-u.ac.jp, ††kanda@m.ndsu.ac.jp, †††manabe-yuki@fukuchiyama.ac.jp,††††inoue599@nanzan-u.ac.jp, †††††shi1.qiu@toshiba.co.jp
あらまし

近年，ソフトウェア部品表（Software Bill of Materials, SBOM）を用いたソフトウェアの管理が推奨されている．しかし，ソフトウェアの SBOM が開発者によって提供されている例は少なく，SBOM の普及は進んでいな
い．その要因として，SBOM に関連するツールの機能の不足や不完全さが指摘されている．この課題を解決するた
めに，GitHub で公開されている OSS の SBOM を作成し，それらを SBOM データセットとして提供することを目指す．本論文では，SBOM データセットの要件を整理し，SBOM データセットを作成するうえで既存の SBOM 生成
ツールを利用する際の課題を調査した．調査の結果，複数の SBOM 生成ツールを組みわせることで，SBOM データ
セットの要件を満たす SBOM を作成できることが分かった．
キーワード

1.

SBOM, SPDX, OSS, GitHub

まえがき

そのソフトウェアが依存するライブラリに存在する既知の脆弱性やライセンス違反を確認できる．

ソフトウェア開発におけるライブラリの利用には開発期間

SBOM は普及が十分に進んでいるとは言えず，ソフトウェの短縮や開発費用の削減が可能になるというメリットがある

アの開発者によって SBOM が提供されている例は少ない [6]．

一方，ライブラリに含まれる不具合が取り込まれるというデメ

SBOM の普及を阻害する要因として，SBOM の生成ツールや，リットがある [1], [2]．ソフトウェアに含まれるセキュリティ

SBOM を用いたソフトウェアの管理を支援するツールが提供上の欠陥は脆弱性と呼ばれ，脆弱性の発見時には脆弱性が含する機能の不足や不完全さが指摘されている [7]〜[9]．

まれないバージョンへの更新対応などを迅速に行う必要があSBOM に関連するツールを改善し，SBOM を普及させるためる．しかし，利用しているソフトウェアの管理は十分に行わにはツールの評価に使用できる SBOM データセットがあるこ

れておらず，ソフトウェア自身やソフトウェアが依存するラとが望ましい．SBOM の元になるプロジェクトは多数公開さイブラリの脆弱性への対応の遅れや対応漏れが問題となってれており，GitHub で公開されているオープンソースプロジェ

いる [3]．2021 年に深刻な脆弱性が発見された Java のログライ

クトを用いることができる．一方，それらのプロジェクトからブラリである Log4j では，2024 年 6 月時点においても，直近手作業で多数の SBOM を作成することは容易ではない．そこ

1 か月間に日本から行われたダウンロードの 20% 程度が脆弱で，本研究では，SBOM データセットを作成するうえで既存性を含むバージョンであることが確認されている [4]．

の SBOM 生成ツールを利用する際，どのような課題があるか

このようなライブラリを含むソフトウェアの管理に関するを調査した．調査では，ビルド済みのバイナリファイルを提供

問題を解決するために，ソフトウェア部品表（Software Bill of

しているプロジェクトからの SBOM 作成，ビルド成果物が無Materials, 以降 SBOM）の利用が推奨されている [5]．SBOM は，いプロジェクトからの SBOM 作成，GitHub が提供する SBOM

特定のソフトウェアを構成するパッケージやドキュメントな生成機能について調査した．調査の結果，複数の SBOM 生成

どの要素，それらのライセンス，および要素間の関係が記述さツールを組みわせることで，SBOM データセットの要件を満れているドキュメントである．開発者が SBOM を作成し，ソ

たす SBOM を作成できることが分かった．

フトウェア本体とともに提供することで，ソフトウェアの利
用者は SBOM に記述された情報に基づいて，ソフトウェアやThis article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©20xx by IEICE

2.

背

景

本章では，SBOM および SBOM の生成を支援するツールに成・使用時に直面した課題を調査し，SBOM の生成や SBOMを用いたソフトウェアの管理を支援するツールの機能不足や不完全さが課題であると報告している．

関する課題を説明する．また，その解決を目的として構築を

2. 3

目指す SBOM のデータセットについて述べる．

SBOM 生成ツールの改善を行うためには，ツールを評価す

2. 1

SBOM

SBOM のデータセット

るためのベンチマークとなるデータセットがあることが望ま

SBOM は，ソフトウェアを構成するライブラリやファイルにしい．例として，コードクローン検出やソフトウェアテスト

ついて，名前やバージョン，ライセンス，それらの間の依存関の分野において，ツールやアルゴリズムの評価に用いること係などの情報を開発者が記述したドキュメントである．SBOMができるデータセットが公開されている [12], [13]．

を利用して，ソフトウェアが依存するライブラリに脆弱性が発公開されている SBOM はあるものの，SBOM 生成ツールを評見されていないかや，使用しているライブラリのライセンス違価することを意図したデータセットは存在していない．Linux反が発生していないかを確認できる．近年，ソフトウェアが依Foundation [14] は 13 個のソフトウェアプロジェクトに対して存するライブラリに含まれる脆弱性を利用した攻撃が増加し作成した SPDX 形式のサンプルファイルを公開している．まていることから，適切なソフトウェアの管理のために SBOM

た，OWASP [15] は 7 個のソフトウェアプロジェクトに対してを利用することが推奨されており，日本でも経済産業省によっ作成した CycloneDX 形式のサンプルファイルを公開している．

て企業による SBOM 導入の手引きが公開されている [10]．

Chainguard [16] は OSS の開発者により公開されている 53 個のSBOM の主要なフォーマットとして，Software Package Data

SBOM と，人気のある 1,000 個の Docker イメージから複数の

Exchange（SPDX）と CycloneDX がある．SPDX は Linux Foun-

SBOM 生成ツールを用いて作成した 3,397 個の SBOM を公開

dation が策定しているフォーマットであり，バージョン 2.2.1 はしている．

ISO/IEC 5962:2021 として国際標準化されている．CycloneDX
はソフトウェアのセキュリティ分野の研究やガイドラインの作成活動を行っている OWASP が策定しているフォーマット
であり，SBOM のみでなく，機械学習モデルに関する BOM で

3. SBOM のデータセットが満たすべき要件
本章では，SBOM のデータセットが満たすべき要件を検討し，整理する．

ある ML-BOM や，IoT デバイスなどのハードウェアに関する

SBOM に関連するツールの開発や検証のためのデータセッ

BOM である HBOM なども記述できるように設計されている．

トとして満たすべき要件を考えたとき，最も重要な記述は依両フォーマットともにソフトウェアに関連するより多くの情存関係に関する部分である．依存関係は，SBOM を用いた脆報を記述できるようにするために仕様の改定が継続的に行わ

弱性検査など多くの重要なタスクにも用いられる部分であり，れている．バージョン 2 系列までの SPDX は SBOM の記述のそのため既存研究での SBOM 生成ツールの課題としても重点

みをサポートしていたが，2024 年 4 月に，CycloneDX と同様に的に調査されている [11]．

ML-BOM なども記述できるように仕様が拡張されたバージョ

データセット内の SBOM に記載されているライブラリ間のン 3.0.0 が公開された．また，CycloneDX も同月にバージョン

依存関係が正確であることは必須である．また，SBOM の理

1.6 が公開され，仕様の継続的な改善が行われている．

念として，あるソフトウェアの実行に必要なライブラリだけ

2. 2

SBOM 生成ツールと課題

でなく，ビルドやテスト時にのみ用いたライブラリなど，開発

SBOM はソフトウェアの構成要素や，依存関係にある要素

環境やデプロイ環境に用いられた依存関係も全て記載するこから情報を収集して作成するため，手作業で作成するのは容とが理想的とされている [11]．そのため，正確性に加え網羅性

易ではない．これらの負荷を軽減するため，様々な SBOM 生

もデータセットに備わっているべき要素となる．

成ツールが存在している [10]．

SBOM に記述可能なライブラリに関する情報としては，ラ

一方で，SBOM 生成ツールが生成する SBOM は正確でない

イブラリの一意な識別子，名前，バージョン，ライセンス，ラ可能性がある．Balliu ら [11] は Java で記述されたソフトウェ

イブラリに含まれるファイルのチェックサムなどがある．一

アプロジェクトを対象に，CycloneDX 形式の SBOM を生成す

意な識別子が記述されていれば，その他の情報はパッケージ

るツールの比較研究を行った．その結果，ツールによってソ

管理システムなどから取得可能であると考えられるが，SBOM

フトウェアからの情報収集方法が異なっており，ソフトウェに関連するツールの検証に利用されるデータセットでは，識アが依存するライブラリに対する完全な情報を含む SBOM を別子以外の情報も正確に含む必要がある．

出力できるツールがないことを報告している．

また，依存関係はソフトウェア毎に異なるため，これらの要

SBOM 生成ツールが未成熟であることは，SBOM 普及にも件を満たすデータセットが十分な規模である必要がある．各

影響を及ぼしている．Xia ら [8] は 65 名のソフトウェア開発

言語のエコシステムによっても依存関係の情報取得の仕組み

者を対象にオンライン調査を行い，調査対象者の多くが既存は異なるため，データセットには多様なプログラミング言語での SBOM に関するツールの使いにくさや，相互運用性や標準開発されているソフトウェアの SBOM が含まれるべきである．

化の欠如を課題として挙げていたことを報告している．また，
Stalnaker ら [9] は，SBOM のステークホルダーが SBOM の作
—2—

4.

調査目的と方法
SBOM（Analyzed）

このような要件が考えられる一方で，多くのソフトウェア
プロジェクトの SBOM からなる大規模な SBOM データセット

GitHubを構築するためには，SBOM の作成作業を可能な限り自動化

条件（1）から（4） ⽣成対象でフィルタリング
リポジトリ
依存関係グラフ機能する必要がある．そこで，既存の SBOM 生成ツールが生成した SBOM と要件とを照らし合わせ，SBOM データセット構築

SBOM（Source）

図 1 Java を対象とする SBOM の作成手順に向けた課題の調査を行う．
SBOM は，生成対象のソフトウェアに関する情報を，いつ，どのように収集するかによって，表 1 に示す 6 種類に分類さることで，SPDX 形式や CycloneDX 形式の SBOM を生成する

れる [17]．ソースファイルを解析して生成される Source タイことができる．生成対象のリポジトリのビルド済みのバイナ

プの SBOM や，ソフトウェアのバイナリなどの成果物を解析

リをダウンロードし，Syft に入力として与えて SPDX 形式のして生成される Analyzed タイプの SBOM の作成には，ソフト

SBOM を作成した．

ウェアのビルドが不要であるため，作成作業の自動化が容易

一方，Source タイプの SBOM は GitHub の機能を用いて作であると予想される．そこで，本調査では，Source タイプや成した．GitHub は，リポジトリ内のマニフェストファイルや

Analyzed タイプの SBOM を生成する SBOM 生成ツールを用い

ロックファイルを静的に解析してプロジェクトが依存するラて GitHub 上の OSS を対象に SBOM を作成し，SBOM データ

イブラリの情報を取得し，プロジェクトの依存関係を確認可

セットの構築に向けた課題を調査する．

能にする依存関係グラフ機能を提供しており，プロジェクト

また，複数言語を対象とすることで，言語による現状の違いの依存関係の情報は SPDX 形式の SBOM としてダウンロード

を明らかにする．具体的には，Java に対して Source タイプとできる．この機能によって得られる SBOM は，マニフェスト

Analyzed タイプの生成ツールそれぞれ 1 種類を，C#に対してファイルやロックファイルを静的に解析して生成されたもの

Source タイプの生成ツール 2 種類を適用し，出力された SBOMであるため，Source タイプの SBOM に該当する．

を分析する．

4. 2 C#を対象とする SBOM 生成ツールの適用可能性

Java を対象とする SBOM 生成ツールの適用可能性

C#は Java に次いで多くのリポジトリが GitHub 上で公開されGitHub 上で公開されている Java のソフトウェアプロジェている言語であり，Java に似た構文を持つプログラミング言語

クトを対象に，Source タイプの SBOM と Analyzed タイプのである．C#を対象とした SBOM 生成ツールの調査は行われてSBOM を作成した（図 1）．2 種類の SBOM を組み合わせるこ

いないが，C#では Windows 環境でのみ利用可能なライブラリとで，SBOM データセットを構成する SBOM として必要な情が存在するなど，Java とはソフトウェアエコシステム間の差異

報を含む SBOM を作成できるかを調査する．

があるため，C#を対象とした SBOM 生成に特有の課題が存在

4. 1

4. 1. 1SBOM の生成対象

この調査では，GitHub 上で公開されているリポジトリから，する可能性がある．そこで，C#を対象とした SBOM 生成ツー
ルを用いて SBOM を作成し，C#を対象とする SBOM 生成の課

SBOM の生成対象のリポジトリを以下の条件で選択した．

題を調査する．作成手順の概要を図 2 に示す．なお，C#のビ（ 1 ） 使用されているプログラミング言語が Java

ルド済みバイナリから SBOM を生成する OSS のツールは著者（ 2 ） 2023 年以降にコミットがあるの調査した限り存在しなかったため，Source タイプの SBOM

（ 3 ） アーカイブされていない

作成のみを調査する．
SBOM の生成対象（ 4 ） スター数が 1,000 以上

4. 2. 1

現在もアクティブに開発されているプロジェクトを生成対

この調査では，GitHub 上で公開されているリポジトリから，象とするために，2023 年以降にコミットが行われており，か

生成対象のリポジトリを以下の条件で選択した．

つアーカイブされていないプロジェクトを対象とした．

（ 1 ） 使用されているプログラミング言語が C#

これらの条件を満たすリポジトリを，GitHub が提供するリ（ 2 ） 2023 年以降にコミットがある

ポジトリの検索 API を用いて得た．得られたリポジトリには，（ 3 ） アーカイブされていない

サンプルプログラムやドキュメントなどの通常のソフトウェ（ 4 ） 通常のソフトウェアプロジェクトである

アプロジェクト以外のリポジトリも存在する可能性があるが，現在もアクティブに開発されているプロジェクトを生成対その場合はバイナリとしての成果物が含まれていることは少象とするために，2023 年以降にコミットが行われており，かないと考えられるため，SBOM の生成対象からは除かれるとつアーカイブされていないプロジェクトを対象とした．また，考えられる．

C#に対する調査では，Analyzed タイプの SBOM を生成する

4. 1. 2

SBOM の作成

ツールを利用せず，サンプルプログラムやドキュメントなど

Analyzed タイプの SBOM は Syft [18] を用いて作成した．Syft

バイナリとしての成果物が含まれないリポジトリが多く生成

は，Java のアーカイブファイルを入力としてサポートしてお対象となる恐れがある．そこで，目視で通常のソフトウェア

り，生成対象のソフトウェアのアーカイブファイルを指定す

プロジェクトをフィルタリングする．

—3—

表1

SBOM の分類

SBOM の種類

定義

Design

ソフトウェアの設計段階に作成され，利用が想定される要素の情報を含む SBOM．

Source開発環境，ソースファイル，ビルド時の依存情報から直接作成される SBOM.

Build

ソフトウェアのリリース可能な成果物をビルドする過程で生成される SBOM.

Analyzed

ソフトウェアの成果物を解析することで生成される SBOM.

Deployed

設定ファイルの内容やデプロイ環境での動作の分析結果などに基づいて生成される SBOM.

Runtime実行中に実際に使用されているコンポーネントの情報を収集することで生成される SBOM.

表 2 GitHub の Release 機能でバイナリが提供されていたリポジトリ
sbom-tool

GitHubSBOM（Source）

条件（1）から（4） ⽣成対象でフィルタリング
リポジトリ
依存関係グラフ機能条件（1）から（3）について，使用されているプログラミン
グ言語，コミット時期，アーカイブについて GitHub の API を用いてフィルタリングを行った．その中から，スター数上位のリポジトリについて README ファイルや説明文を確認し，条件（4）に当てはまるものを 30 件選択した．
SBOM の作成

SBOM の作成には，Microsoft が公開している sbom-tool [19]を用いた．sbom-tool は，生成対象のソフトウェアのソースコー
ドが存在するディレクトリを入力として与えることで，ディレクトリ内に存在するソフトウェアのマニフェストファイル
やロックファイルを分析し，SPDX 形式の SBOM を出力するツールである．また，Java を対象にした調査と同様に，GitHubの依存関係グラフ機能を用いて SBOM を作成した．

5.

件数

割合

Java のアーカイブファイル

108

3.38%

Java のアーカイブファイルを含む zip ファイル 121

3.78%

合計

6.88%

220

SBOM
（Source）

図 2 C#を対象とする SBOM の作成手順

4. 2. 2

ファイルの種類

調査結果と考察したため，ビルド済みのバイナリが提供されていたリポジト
リは合計 220 個である．
5. 1. 2

Syft で作成した SBOM

これらの Java のアーカイブファイルを対象として，SBOM
生成ツールの Syft を実行すると，すべてのファイルに対してSBOM の生成に成功した．生成された SBOM には，Java のアー
カイブファイルに含まれる依存ライブラリの情報が含まれており，直接的または推移的に依存するライブラリの情報が含まれていた．一方で，単体テストのライブラリのように実行時に使用されないライブラリの情報は含まれなかった．
ライブラリに関する情報の記述例をコード 1 に示す．この例では caﬀeine というライブラリのバージョン 2.9.3 に関する情報が記述されている．5 行目から 8 行目には，ライブラリのファイルのチェックサム情報が記述されている．SPDX 形式では，異なるアルゴリズムを用いて計算された複数のチェック
サムの値を記述することができるが，生成された SBOM には
SHA1 で計算された値のみが記述されていた．9 行目にはライ
ブラリのライセンス情報が，ライブラリのライセンスファイ

本章では，SBOM データセットの構築における SBOM 生成
ツールの適用可能性について調査した結果と考察を述べる．
5. 1

Java を対象とする SBOM 生成ツールの適用可能性

ビルド済みのバイナリが提供されていたリポジトリの割合と，SBOM 生成ツールによって生成された SBOM の内容について説明し，Java を対象として SBOM 生成ツールをデータセットの構築に利用する際の課題について考察する．
5. 1. 1

ビルド済みのバイナリが GitHub の Release 機能で提供されているリポジトリの割合

4. 1 で述べた条件（1）から（3）を満たすリポジトリは 3,198
リポジトリであり，そのうち 220 リポジトリ（6.88%）で GitHubの Release 機能を用いてビルド済みのバイナリが提供されていた（表 2）．jar ファイルなどの Java のアーカイブファイルが提供されていたものが 108 リポジトリ（3.38%），zip ファイルに圧縮されて Java のアーカイブファイルが提供されていたものが 121 リポジトリ（3.78%）であった．両方の形式で Java のアーカイブファイルが提供されていたリポジトリが 9 個存在

ルへの URL を記述した要素への参照として記述されている．
11 行目から 13 行目にはライブラリの識別子である purl の情報が記述されている．これらの情報は，ソースコードに記述された情報や，生成元のアーカイブファイルの中身を展開して確認できる情報と一致しており，Syft が依存するライブラ
リの情報を正確に取得できていることが確認できた．ただし，ライセンスの情報はライセンスファイルへの URL を用いて記述されており，SPDX で定められた SPDX-License-Identiﬁer と呼ばれる正規化されたライセンス識別子は使用されていない．
5. 1. 3

GitHub の依存関係グラフ機能で作成した SBOM

GitHub の依存関係グラフ機能で作成した SBOM には，直接的に依存する Java のライブラリなどの情報が含まれていた．
一方で，推移的に依存するライブラリの情報は含まれなかった．
依存する Java のライブラリは，Maven の pom.xml ファイルに記述されたプロジェクトの依存関係から特定されている．
pom.xml では，ライブラリのバージョンを省略したり範囲指定したりすることが可能なため，pom.xml の静的な解析では—4—

コード 11

コード 3 sbom-tool で生成した SBOM でのライブラリ情報の例{"name": "caffeine","SPDXID": "SPDXRef-Package-java-archive-caffe...","versionInfo": "2.9.3","checksums": [{"algorithm": "SHA1","checksumValue": "b162491..."}],"licenseDeclared": "LicenseRef-https---www.apache.org-l
icenses-LICENSE-2.0","externalRefs": [{"referenceCategory": "PACKAGE-MANAGER","referenceType": "purl","referenceLocator": "pkg:maven/com.github.ben-manes.caffeine/caffeine@2.9.3"} ...], ...

2
3
4
5
6
7
8
9

10
11
12
13

14
15

Syft で生成した SBOM でのライブラリ情報の例

1{"name": "ReactiveUI.WPF","SPDXID": "SPDXRef-Package-A0E054779263F...","licenseDeclared": "NOASSERTION","versionInfo": "19.6.1","externalRefs": [{"referenceCategory": "PACKAGE-MANAGER","referenceType": "purl","referenceLocator": "pkg:nuget/ReactiveUI.WPF@19.6.1"}], ...

2
3
4
5
6
7
8
9

10
11

}

以外のツールも用いて情報を取得し，不足する情報を SBOM}に追加することで対応が可能であると考えられる．
5. 2
コード 2
1

"SPDXID": "SPDXRef-maven-com.github.ben-ma...","name": "maven:com.github.ben-manes.caffe...","versionInfo": "", ...

3
4SBOM 生成ツールによって生成された SBOM の内容について説明し，C#を対象として SBOM 生成ツールをデータセット

{

2

5

GitHub で生成した SBOM でのライブラリ情報の例

C#を対象とする SBOM 生成ツールの適用可能性}の構築に利用する際の課題について考察する．
5. 2. 1sbom-tool で作成した SBOM

sbom-tool を用いて，依存するライブラリの情報を含む SBOMを作成するためには，C#のパッケージ管理システムを用いて依存関係の復元処理を行う必要があった．依存関係の復元処依存するライブラリのバージョンを特定できないことがある．

理を行うことで，ビルド時に使用されるライブラリのバージョ

そのため，生成された SBOM にはバージョン情報を含まないンが決定され，依存するライブラリのバージョン情報を正確

ライブラリ情報が多く見られた．生成された SBOM に含まれに取得できるようになる．依存関係の復元処理は，生成対象

るライブラリ情報の例をコード 2 に示す．この例では，コーとして選択された 30 個のリポジトリのうち，19 個のリポジ

ド 1 と同様に caﬀeine というライブラリに関する情報が記述さトリ（63%）で成功した．これら 19 個のリポジトリについてれているが，バージョンの特定に失敗しているためバージョ

sbom-tool を実行すると，すべてのリポジトリで SBOM が生成

ン情報は空文字列であり，ライセンスに関する記述も含まされた．

れていない．一方で，バージョンの特定に成功したライブラ

sbom-tool で作成した SBOM には，直接的または推移的に依リの場合はバージョン情報が記述され，ライセンスの情報も存するライブラリの情報が含まれていた．生成された SBOM

SPDX-License-Identiﬁer を用いて記述されていた．

に含まれる依存ライブラリの情報の例をコード 3 に示す．この5. 1. 4

考察

例では，ReactiveUI.WPF というライブラリのバージョン 19.6.1

GitHub の Release 機能を用いてビルド済みのバイナリが提供に関する情報が記述されており，ライブラリのバージョン情

されている Java のリポジトリの割合は 7% 程度であった．ス

報や識別子（7 行目から 11 行目）が含まれていることが確認

ター数が比較的少ないリポジトリでもビルド済みのバイナリできる．一方で，ライセンスに関する情報や，ライブラリのが提供されていたことから，リポジトリの選択条件であるスファイルのチェックサム情報は含まれていなかった．

ター数の下限をより小さくすることで，十分な数の SBOM 生
成対象を得られると思われる．
Syft と GitHub の依存関係グラフ機能では生成される SBOMが含む情報に違いがあり，一方のツールのみでは SBOM デー

5. 2. 2

GitHub の依存関係グラフ機能で作成した SBOM

GitHub の依存関係グラフ機能で作成した SBOM には，直接的に依存するライブラリなどの情報が含まれていた．一方で，推移的に依存するライブラリの情報は含まれなかった．

タセットの要件を満たす SBOM は作成できない．SBOM デー

生成された SBOM に含まれるライブラリ情報の例をコー

タセットの要件を満たす SBOM を作成するためには，複数のド 4 に示す．この例では，コード 3 と同じく ReactiveUI.WPF

SBOM 生成ツールを用いて作成した SBOM を組み合わせて，というライブラリに関する情報が記述されている．ライブラ

単一のツールでは不足する情報を補うことが有効であると考リのバージョン情報や識別子（5 行目から 9 行目）は含まれえられる．また，ライブラリのチェックサムについては，今ているが，ライセンスに関する情報や，ライブラリのファイ回調査した両ツールともに情報が不足していた．SBOM 生成

ルのチェックサム情報は含まれていない．C#においても Java

ツールのみでは補えない情報については，SBOM 生成ツール（Maven）と同様に，依存するライブラリのバージョンの指定—5—

コード 4
1{"SPDXID": "SPDXRef-nuget-ReactiveUI.WPF-20.1.1","name": "nuget:ReactiveUI.WPF","versionInfo": "20.1.1","externalRefs": [{"referenceCategory": "PACKAGE-MANAGER","referenceLocator": "pkg:nuget/ReactiveUI.WPF@20.1.1","referenceType": "purl"}], ...

2
3
4
5
6
7

8
9
10

GitHub で生成した SBOM でのライブラリ情報の例
[3]

[4]

[5]

}
[6]

を省略したり，範囲指定したりすることができるため，バージョン情報が含まれていないライブラリ情報が存在した．
5. 2. 3考[7]

察

sbom-tool は，ビルド時に使用されるライブラリのバージョン情報を正確に取得するために，依存関係の復元処理を行う必要があった．依存関係の復元処理に成功する割合は 63% で[8]あり，十分な数の SBOM 生成対象を確保する上で大きな問題にはならないと考えられる．
sbom-tool と GitHub の依存関係グラフ機能は，ともに Source[9]

タイプの SBOM を生成するが，生成された SBOM に含まれる情報には違いがあった．C#においても，複数の SBOM 生成
ツールや，不足する情報を取得できるその他のツールを組み合わせることで SBOM データセットの要件を満たす SBOM が[10]作成可能であると考えられる．

6.

ま

と

め

[11]

本研究では，GitHub 上で公開されている OSS を対象に既存のツールを用いた SBOM の作成を行い，SBOM データセットの構築における課題を調査した．Java と C#のいずれの場合も，[12]単一の生成ツールのみでは SBOM データセットの要件を満た
す SBOM は作成できず，複数のツールを用いて不足する情報を補う必要があることが分かった．

[13]

ソフトウェアエコシステム毎に SBOM の作成における課題は異なる可能性があるため，他の言語に対しても同様の調査を行う必要がある．また，複数のツールから得た情報を組み合わ[14]

せて要件を満たす SBOM を作成する方法の検討が必要である．

[15]

謝辞
本研究は，
JSPS 科研費 JP24H00692，
JP21K18302，
JP21H04877，[16]

JP23K24823，JP22K11985，
JP24K14895，JP21K02862，
JP23K28065， [17]2024 年度南山大学パッヘ研究奨励金 I-A-2 の助成を得て行わ
れた．
文

献

[1] O.P.N. Slyngstad, A. Gupta, R. Conradi, P. Mohagheghi, H. Rønneberg,
and E. Landre, “An Empirical Study of Developers Views on Software Reuse in Statoil ASA,” Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE),
pp.242–251, 2006.
[2] Y. Wang, B. Chen, K. Huang, B. Shi, C. Xu, X. Peng, Y. Wu, and Y.
Liu, “An Empirical Study of Usages, Updates and Risks of Third-Party

[18]
[19]

Libraries in Java Projects,” Proceedings of the 2020 IEEE International
Conference on Software Maintenance and Evolution (ICSME), pp.35–
45, 2020.
M. Alfadel, D.E. Costa, and E. Shihab, “Empirical Analysis of Security Vulnerabilities in Python Packages,” Proceedings of the 2021
IEEE International Conference on Software Analysis, Evolution andReengineering (SANER), pp.446–457, 2021.
Sonatype, “Log4j Updates and Vulnerability Resources”. 2024
年 6 月 25 日 に 閲 覧. https://www.sonatype.com/resources/log4jvulnerability-resource-center
NTIA Multistakeholder Process on Software Component Transparency Framing Working Group, “Framing Software Component
Transparency: Establishing a Common Software Bill of Material(SBOM),” https://www.ntia.gov/files/ntia/publications/framingsbom_20191112.pdf, 2019.
S. Nocera, S. Romano, M.D. Penta, R. Francese, and G. Scanniello,“Software Bill of Materials Adoption: A Mining Study from GitHub,”
Proceedings of the 2023 IEEE International Conference on Software
Maintenance and Evolution (ICSME), pp.39–49, 2023.
The Linux Foundation, “The State of Software Bill of Materials(SBOM) and Cybersecurity Readiness,” 2022. 2024 年 6 月 25 日に閲覧. https://www.linuxfoundation.org/research/the-state-of-softwarebill-of-materials-sbom-and-cybersecurity-readiness
B. Xia, T. Bi, Z. Xing, Q. Lu, and L. Zhu, “An Empirical Study on
Software Bill of Materials: Where We Stand and the Road Ahead,” Proceedings of the IEEE/ACM 45th International Conference on Software
Engineering (ICSE), pp.2634–2646, 2023.
T. Stalnaker, N. Wintersgill, O. Chaparro, M. Di Penta, D.M. German, and D. Poshyvanyk, “Boms away! inside the minds of stakeholders: A comprehensive study of bills of materials for software systems,” Proceedings of the IEEE/ACM 46th International
Conference on Software Engineering (ICSE), pp.513–525, 2024.
https://doi.org/10.1145/3597503.3623347
経済産業省 商務情報政策局サイバーセキュリティ課，“ソフトウェア管理に向けた sbom（software bill of materials）の導入に関する手引,” https://www.meti.go.jp/press/2023/07/
20230728004/20230728004.html，2023．
M. Balliu, B. Baudry, S. Bobadilla, M. Ekstedt, M. Monperrus, J. Ron,
A. Sharma, G. Skoglund, C. Soto-Valero, and M. Wittlinger, “Challenges of Producing Software Bill of Materials for Java,” IEEE Security& Privacy, pp.2–13, 2023.
F. Al-Omari, C.K. Roy, and T. Chen, “Semanticclonebench: A semantic code clone benchmark using crowd-source knowledge,” 2020 IEEE
14th International Workshop on Software Clones (IWSC), pp.57–63,
2020.
肥 後 芳 樹 ，“自 動 テ ス ト 生 成 技 術 を 利 用 し た 機 能 等 価 メ ソ
ッ ド デ ー タ セ ッ ト の 構 築,” ソ フ ト ウ ェ ア エ ン ジ ニ ア リ ン
グ シ ン ポ ジ ウ ム 2023 論 文 集 ，vol.2023，pp.30–38，08 2023．
https://cir.nii.ac.jp/crid/1050018218946104192
SPDX Workgroup, “spdx-examples,” https://github.com/spdx/
spdx-examples.
CycloneDX, “bom-examples,” https://github.com/CycloneDX/
bom-examples.
Chainguard, “bom-shelter,” https://github.com/chainguarddev/bom-shelter, 2022.
CISA, “Types of software bill of materials (sbom) documents,” https://www.cisa.gov/sites/default/files/202304/sbom-types-document-508c.pdf, 2023.
anchore, “syft,” https://github.com/anchore/syft, 2020.
Microsoft, “sbom-tool”.
2024 年 6 月 25 日 に 閲 覧.
https://github.com/microsoft/sbom-tool—6—