SBOM

SBOM（Software Bill of Materials）とはソフトウェアを構成する各部品や、部品同士の依存関係を一覧にした技術的資料を指します。日本語では「エスボム」と読み、「ソフトウェア部品表」などと訳されます。

近年のソフトウェア開発では、開発者が自ら書いたプログラムだけでなく、誰もが無償で利用可能なオープンソースソフトウェア（OSS）やプロプライエタリソフトウェアなど、外部で開発されたプログラムが部品（コンポーネント）として取り入れられるのが一般的になっています。こうした部品を外部から調達するメリットは、ソフトウェアのすべてを一から自作する必要がなくなり、開発効率を上げられる点です。

とはいえ、無償で使えるOSSにもさまざまな約束事＝ライセンスがあり、意図せず規約に違反する危険性がつきまといます。OSSに脆弱性が見つかれば、ソフトウェア全体にリスクが及ぶデメリットもあります。

これらのリスクを軽減するために、ソフトウェアの部品を把握・管理するリストとしてSBOMが活用されます。SBOMはソフトウェア開発者がリスクを特定する、あるいはソフトウェアを選定・購入する側がリスクを評価するための指標です。その目的は製品に使われた部品のリストを完成させることではなく、コンプライアンスリスクへの対処、脆弱性の特定・評価に役立てることにあります。

2021年の米大統領令や脆弱性「Log4Shell」をめぐる騒動などをきっかけに、日本でもSBOMが注目されるようになりました。経済産業省もSBOMの活用を推進しており、2023年7月には『ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引』を策定しています。さらに2025年9月には、SBOMの共有ビジョンに関する国際ガイダンス『A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity』に共同署名しました。

米商務省電気通信情報局（NTIA）が2021年に発行した資料『SBOM at a Glance』（JPCERT/CC訳の日本語版も公開済み）には、SBOMの活⽤法や役割、記載すべき情報、データフォーマットとツール、共有方法などが概説されています。

SBOMを作るのは「ソフトウェアやソフトウェアシステムを作成、修正、一括販売、納入するすべての組織＝サプライヤー」です。ソフトウェア本体の開発と並行してSBOMを作成することが最も効率的とされ、新しい部品がリリースされる度に新たなSBOMを用意することが望ましいものの、部品自体の変更はなかったとしても、部品についての情報が変更・更新されたらSBOMを作成・アップデートすることが奨励されています。

SBOMは手作業で作ることもできますが、部品数や工数の多さなどを理由に現実的とは言えず、通常はSCA（Software Composition Analysis）と呼ばれる自動化ツールが使われます。このため、データフォーマットにはマシンリーダブルな（機械によって容易に処理できる）ものを使用することが求められます。

SBOMで使われるデータフォーマットは主に3種類あり、それぞれ「SPDX」「Cyclone DX」「SWIDタグ」と呼ばれています。NTIAは特定のフォーマットの使用を推奨しておらず、さまざまなニーズに合わせてユーザーが選択すべきとしています。

『SBOM at a Glance』に記された「Baseline Component Information」（基本部品情報）が最低限必要な情報とされ、そのほかにも「部品のサポート終了日」や「部品が実装もしくは対応しているテクノロジー」など、利用目的に合わせた情報を追加します。

脆弱性に関するリスクを特定するため、SBOMに脆弱性情報を盛り込むことも可能です。しかし、SBOMには特定の時点におけるソフトウェアの属性が反映されているのに対し、脆弱性データは時間の経過とともに刻々と変化します。こうした背景から、NTIAは基本的に「SBOM内の脆弱性データを完全かつ最新だと決めてかかってはならない」と警告しており、SBOMを脆弱性管理に役立てる場合は脆弱性データベースが別途必要とされています。

SBOMについて、さらに詳しくはこちらの記事もご覧ください：

「SBOMとは？　日本でも重要な理由と作り方、活用方法」