ソフトウェア部品表（SBOM）について

2025年5月1日2025年5月14日

東京システムハウス
山口

SBOMとは

SBOM (Software Bill Of Material)とは、ソフトウェアのコンポーネントや依存関係等の情報を著した機械処理可能なドキュメントを指します。このページでは、SBOMが注目された経緯、およびSBOMの中身についての説明を行います。

SBOMが注目された経緯

新しいソフトウェアを作成する際、すべてを独自のコードでまかなうことは今ではめったにありません。プログラミング言語に用意されているライブラリや、OSS（オープンソースソフトウェア）を下敷きに、自分が欲しい機能を追加してソフトウェアを作る、というのが今のセオリーです。

ではもし、使ったOSSやライブラリにセキュリティ上の脆弱性があった場合どうなるか。当然、それを利用したソフトウェアにも同様の脆弱性があると考えられます。さらに、OSS自体もまた別の脆弱性があるソフトウェア・ライブラリを使って作られていて、そのライブラリも・・・という話になってくると、大元のライブラリ等に脆弱性があった場合、多くのソフトウェアに影響を与えます。実際、2021年にApache Log4jの脆弱性が発見された際は、昔からあるライブラリであることも手伝って多くのOSやサービスが対応に追われることになりました。

このLog4jの事件や、事件前後に件数が急増したソフトウェアサプライチェーンへの攻撃を受けて、ソフトウェアの脅威の適切な管理が急務となりました。例えば、ソフトウェアに含まれるOSS・ライブラリを把握し、脆弱性が見つかったら迅速に対応できるようにする、というような管理体制が考えられます。この、”ソフトウェアに含まれるOSS・ライブラリの把握”に有効な手段として注目されたのがSBOMでした。

SBOMの情報

前置きが長くなりましたが、ここからはSBOMがどういったものなのか、例を交えて説明していきます。
SBOMは、ソフトウェアに含まれるコンポーネント（OSS, ライブラリなどのこと）の情報や各コンポーネントの依存関係を機械が可読な形式で記したドキュメントです。ソフトウェアのサプライチェーンで上流から下流に向け情報共有するための手段として一部の業界で使われていましたが、前述のように脆弱性の管理にも有効であると注目されています。

では具体的にSBOMがどのようなものであるか、経済産業省が公開している手順書「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver 2.0(https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html)」（以下、手引書と呼称）の例をもとに見ていきましょう。

シナリオ:
・A 社は、B 社の Browser とコミュニティ P の Protocol という 2 つのコンポーネントを使用して、Application というソフトウェアを開発した。
・B 社の Browser は、C 氏が開発した Compression Engine のコンポーネントを使用している。
・B 社は、Browser に関する SBOM を自社で作成し、A 社に共有した。
ただし、C 氏やコミュニティP のコンポーネントに関する SBOM 情報を取得できなかったため、A 社にて、C 氏とコミュニティ P のコンポーネントの SBOM を作成した。

以下の図は、上記のシナリオに基づく各企業の関係性です。

(ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver 2.0　P10より抜粋)

このとき、A社はB社から提供されたSBOM情報と、独自に集めた情報から下記のような表を作成できます。(コンポーネントバージョン、識別子は図示されていませんが、手引書の定義に倣っています。)

	サプライヤー名	コンポーネント名	コンポーネントバージョン	識別子	依存関係	SBOM作成者	タイムスタンプ
1	Company A	Application	1.1	234	Primary	Company A	05-09-2022 13:00:00
2	Company B	Browser	2.1	334	Included in Application	Company B	04-18-2022 15:00:00
3	Mr.C	Compression Engine	3.1	434	Included in Browser	Company A	05-09-2022 13:00:00
4	Community P	Protocol	2.2	534	Included in Application	Company A	05-09-2022 13:00:00

これらの情報を、機械処理可能なJSONやXMLなどの形式でファイル化したものをSBOMと呼びます。上記の例のアプリケーション部分だけJSONで書きだすと、以下のような表記になります。

“components”: [{
“id” = “234”,
“name” = “Application”,
“version” = “1.1”,
“supplier” = “Company A”,
“dependency” = [{“relation” = “Primary”}]
“last_update” = “05-09-2022 13:00:00”,
“info_supplier” = “Company A”
}, ・・・]

この例ではとてもシンプルに見えますが、実際はBrowserやEngine, Protocolのそれぞれで使われているOSSやライブラリについても、できる限り全て記述する必要があります。そうした膨大な数のコンポーネントと依存関係を記述するとなると、人間が書いたり読んだりするのは到底無理な文章量になります。だからこそ、機械処理できる形式のドキュメントを整備して、これら一切の情報をツールやプログラムで一気に読み込み・書き込みできるようにしようというのが、SBOMの持つ大きな意義なのです。

SBOMフォーマット

広義のSBOMは機械可読性があればその形式までは指定しません。ただし、ある程度書き方を統一しなくてはSBOMを共有したり統合する際に不都合が生じやすくなります。そのため、いくつかのSBOMのフォーマットが各コミュニティから提案されています。

SPDX

公式サイト: https://spdx.dev/
Linux Foundation 傘下のプロジェクトによって開発された SBOM フォーマットで、ISO/IEC 5962:2021として国際標準化されています。
元がOSSのライセンス情報を扱うためのフォーマットとして開発されたので、ファイル単位まで細かく記述可能で、コンポーネント・ライセンス・コピーライトがあらかじめ独自のデータベース（SPDX Specification）に登録されていることが特徴です。
記述を簡易化したSPDX Liteという派生フォーマットも存在します。

CycloneDX

公式サイト: https://cyclonedx.org/
ソフトウェア・Webアプリケーションのセキュリティ情報に関するコミュニティ、OWASP上のプロジェクトで開発されたSBOMフォーマットです。

セキュリティ特化のSBOMがコンセプトのため、脆弱性情報を直接SBOM内に記述することができるのが大きな特徴です。（ただし、記述できるのはCycloneDX 1.4以降のバージョンです。）VEXという脆弱性情報を記述したドキュメントのフォーマットとしても利用されていることがあります。

SWIDタグ

デバイスにインストールされたソフトウェア追跡のため開発されたドキュメント形式です。この中では最も古いフォーマットですが、そもそもSBOMとして開発されたわけではないので、SBOMの話題ではSPDXやCycloneDXほど引き合いに出されない気がします・・・。それでも、コンポーネント情報やパッチ情報、脆弱性情報は十分記載できる機能があります。

これらのうち、SPDX, CycloneDXは多くのSBOM取扱ツールで対応していて、大きく普及しているSBOMフォーマットの二大勢力といっても過言ではありません。

具体的なフォーマットの書き方についてはここでは割愛します。興味がございましたら、SBOM BENCHMARK(https://sbombenchmark.dev/)というサイトに、無償SBOMツールで出力したSBOMが保存されているので、適当な1件をダウンロードして中身をご覧になってみてはいかがでしょうか。

SBOMのメリット

脆弱性管理への有効性

前章で示したような形式で、ソフトウェアのコンポーネントを平易にまとめておくことで、脆弱性発覚から対応開始までの時間を短縮できます。

特に、現在はソフトウェアを解析しSBOMを作ってくれたり、解析結果や外部から読み込んだSBOM情報から脆弱性管理を自動で行ってくれるツール（SBOMツール）が出てきているため、わざわざ人力で脆弱性情報とソフトウェアを突合する手間が大幅に軽減されます。ツール導入・習得の手間はかかるものの、長い目で見れば脆弱性対応にかかるコストもカットできます。

ライセンス管理への有効性

コンポーネント絡みのリスクは脆弱性に限りません。OSSはライセンスがつきもので、要求事項の遵守が求められます。コンポーネントのライセンスを把握できていないと、知らないうちに要求事項違反を起こすリスクが発生します。国内では訴訟まで起こされる例はあまりありませんが、海外ではGNU General Public License（GPL）違反によって、2009年に家電メーカー等14社が一斉に起訴されたり、2013年にメディアプレイヤーのメーカーが訴訟を起こされたケースが存在しています。

SBOMは任意でライセンス情報も記載できるので、コンポーネント管理と一緒にライセンス管理も可能です。また、SBOMツールの中にはライセンスの検出やライセンス違反をアラートしてくれる機能を搭載しているものもあるので、より効率的にライセンス管理ができます。

SDLCの改善

コンポーネントや依存関係の整理、そして脆弱性管理やライセンス管理が円滑に行えるようになれば、それらの対応業務にかかる時間が削減でき、間接的にソフトウェア開発ライフサイクル（SDLC）の生産性も向上します。Linux Foundationの2021年の調査によれば、SBOMから得られた恩恵について最も高い割合の回答が、”開発者が複雑なプロジェクト間の依存関係を理解しやすくなること”で、生産性向上に一役買っていることが見受けられます。

まとめ

今回はSBOMの概要について記事を書いてみました。
今回の記事を書くにあたり、経済産業省が公開するソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver 2.0(https://www.meti.go.jp/press/2024/08/20240829001/20240829001-1r.pdf)を参考にしました。文書のボリュームはかなりありますが、SBOMの概要から管理・運用手法の提案などが分かりやすく書かれているので、こちらを読んでみてもよいかもしれません。