SBOMとは？基礎知識やできること、選び方までをわかりやすく解説！

SBOMは、製品に組み込んだソフトウェアの中身を明らかにするための一覧表です。ここでは、定義、記録する情報、求められる理由、代表的な形式を押さえます。SBOMで管理する対象のソフトウェア本体は、組み込みソフトウェア（RTOS）カテゴリで扱っています。

ソフトウェア版の部品表

SBOMは、Software Bill of Materialsの略称です。日本語では「ソフトウェア部品表」と訳されます。製品を構成する部品を書き出した部品表（BOM）の、ソフトウェア版と考えると分かりやすいでしょう。

いまの組込み機器は、自社で書いたコードだけでは動いていません。OSSのライブラリや商用コンポーネントなど、外部から調達した多くの部品の上に成り立っています。ハードの部品表がネジや基板を並べるように、SBOMはこうしたソフトの部品を並べます。

SBOMに記録する情報

SBOMには、部品ごとに少なくとも名称、バージョン、ライセンス、依存関係を記録します。脆弱性は特定のバージョンに紐づくため、とくにバージョンの記録が欠かせません。

依存関係には、ある部品が内部でさらに別の部品を呼ぶ入れ子の構造も含めます。これらを機械可読な形で表した一覧が、SBOMの実体です。新しい脆弱性が出たときも、一覧との照合で影響の有無を確かめられます。SBOMがないと、影響を調べるだけで膨大な手間がかかります。

今SBOMが求められる理由

背景には3つの流れがあります。1つ目は、OSSや外部部品、ビルドの過程といった上流を狙うサプライチェーン攻撃の増加です。何が入っているかを把握していなければ、影響を受けるかすら判断できません。2つ目は、Log4jの脆弱性で表面化したOSS管理の難しさです。

Log4jのときは、多くの組織が自社のどこに含まれるかの洗い出しに追われました。3つ目は、規制や取引先からの要求です。SBOMを出せないと製品を採用してもらえない、という商談上の事情も生まれています。

代表的な形式（SPDX・CycloneDX）

SBOMは、ツール間でやり取りしたり、提出先で機械的に処理したりするため、標準形式で作ります。代表的なのがSPDXとCycloneDXの2つです。

SPDXは、ライセンスの管理・開示を重視する文脈で発展してきた形式です。OSSライセンスの順守の用途でも広く使われています。CycloneDXは、脆弱性管理などのセキュリティ用途を強く意識して設計されました。どちらも多くのツールが対応しており、使い分けは提出先の要件で決まります。

編集部メモ：SBOMは、セキュリティ部門だけでなく開発・品質・調達・法務が横断して関わるテーマです。製品ライフサイクルが長い組込み機器ほど、出荷後も更新し続ける前提で体制を考える必要があります。

SBOMの利点は、製品の中身をいつでも答えられる状態にしておけることから生まれます。脆弱性対応、規制・取引への対応、ライセンス管理の3つの場面で効果が表れます。

• 脆弱性の影響範囲をすぐに特定できる
• 規制や取引先の要求に応えられる
• ライセンスの問題を早く見つけられる

脆弱性の影響範囲をすぐに特定できる

広く使われるOSSに脆弱性が出ると、影響は多くの製品へ連鎖的に広がります。SBOMがあれば、該当する部品を含む製品とバージョンを一覧の照合で絞り込めます。調査に追われず、対応の初動を早められるのが利点です。

Log4jのときも、SBOMが整っていれば洗い出しは照合で済んだはずです。出荷済みの製品まで遡って確かめられるため、長く使われる機器ほど安心感が増すでしょう。影響がないと分かれば、不要な調査に工数を割かずに済みます。

規制や取引先の要求に応えられる

CRAやWP.29、医療機器の規制では、ソフトウェア構成の透明性が問われるようになりました。規制は分野ごとに違っても、問われる中身は共通しています。構成を把握し、脆弱性が出たら対応できる体制があるかという点です。SBOMを整備しておけば、その土台を示せます。

調達側の企業が、取引先にSBOMの提出を求めるケースも増えています。求められてから慌てて調べるのではなく、すぐに出せる状態にしておけるのが強みです。商談で不利にならない点も、見逃せない利点になるでしょう。

ライセンスの問題を早く見つけられる

SBOMには、部品ごとのライセンスも記録されます。OSSを組み込んだ製品で、ライセンスの条件に反する使い方をしていないかを早い段階で確かめられます。

出荷後に問題が見つかると、製品の改修や顧客への説明に追われかねません。開発中に気づけば、別の部品へ差し替える判断もしやすくなります。法務部門とも同じ一覧をもとに話せるため、確認のやり取りが短く済むでしょう。ライセンス順守の用途では、SPDX形式のSBOMが広く使われています。

ツールを入れれば済むと考えて導入すると、検出結果の山に現場が疲弊しがちです。いずれも事前に手を打てるので、対処法とあわせて押さえておきましょう。

• 誤検知の判断に手間がかかる
• ソースが手元にない部品を把握しにくい
• 出荷後も更新し続ける体制が要る

誤検知の判断に手間がかかる

SCAツールの自動検出は強力ですが、結果には誤検知が一定の割合で混じります。実際には使っていない部品や、影響しない部品を脆弱性ありと判定する場合です。すべてを鵜呑みにすると、対応不要なものに振り回され、現場が疲弊します。

対処法：検出結果が自社製品に本当に影響するかを判断する担当を、ツールとセットで用意してください。この仕分けをトリアージと呼び、担う人と体制がなければ運用は回りません。

ソースが手元にない部品を把握しにくい

組込み開発では、ソースが手元にない部品が珍しくありません。サプライヤー提供のバイナリや、チップベンダーのSDK・ドライバなどです。過去のプロジェクトから引き継いだファームウェアも、これに当たります。多くのSCAはソースや依存関係の定義を起点に解析するため、こうした部品の中身を把握しきれません。

対処法：バイナリやファームウェアそのものを解析できるツールを選んでください。出荷されるイメージを解析すれば、実態に即した構成を把握できます。

出荷後も更新し続ける体制が要る

組込み・車載・医療機器には、出荷後に十年以上使われる製品もあります。開発時点のSBOMを作るだけでは足りません。その間も新しい脆弱性は次々と公表されるため、過去の出荷製品まで遡って照合できる仕組みが要ります。

対処法：いきなり全製品を対象にせず、影響の大きい1製品から小さく始めてください。誤検知の量、判断する担当、出荷後の更新の担い手を洗い出し、体制を育ててから広げます。ツール選定と同じかそれ以上に、対応を回し続ける体制づくりが成否を分けます。

SBOMの作成と運用は、専用のツールが支えます。ツールが備える主な機能は次の4つです。

• 構成の自動検出：ソースコードや依存関係を解析し、含まれるOSS・部品とバージョンを特定する
• バイナリ・ファームウェアの解析：ソースがない部品も、製品に書き込むイメージから構成を特定する
• 標準形式での出力：検出した構成情報を、SPDXやCycloneDXの形式で書き出す
• 脆弱性・ライセンスの評価：検出した部品に、既知の脆弱性や問題のあるライセンスがないかを調べる

それぞれの中身を見ていきましょう。

構成の自動検出

ソースコードや依存関係の定義を解析し、含まれるOSSやサードパーティ製部品を特定する機能です。この手法をSCA（ソフトウェア構成分析）と呼び、SBOM生成の中核を担います。解析の前に、どの製品・どのリリースを対象にするかを決めます。

手作業で部品とバージョンを書き出すのは、複雑なソフトウェアでは現実的ではありません。開発・ビルドのパイプラインに組み込み、ビルドのたびに構成を確かめる使い方もできます。この運用はDevSecOpsと呼ばれます。

バイナリ・ファームウェアの解析

製品に書き込まれるバイナリやファームウェアそのものを解析する機能です。中に含まれるOSSやコンポーネントを、ソースコードなしで特定できます。サプライヤー提供のバイナリなど、ソースが手元にない部品も対象にできます。

解析の起点は、最終的に焼き込むイメージです。そのため、出荷される製品の中身を実態に近い形でつかめます。ソースベースの解析だけを前提にしたツールは、この領域に対応していません。対応の有無はツールによって異なります。

標準形式での出力

検出した構成情報を、SPDXやCycloneDXといった標準形式で書き出す機能です。SBOMは、自由な書式のメモでは役に立ちません。形式が揃っていれば、ツール間の受け渡しや、提出先での機械的な処理ができます。

どちらの形式が要るかは、提出先の要件によって変わります。そのため、両形式の出力に対応しているかがツールの確認点です。出力したSBOMは、部品の追加や更新に合わせて作り直し、最新の状態に保ちます。

脆弱性・ライセンスの評価

検出した部品に、既知の脆弱性や問題のあるライセンスがないかを調べる機能です。SBOMの一覧と脆弱性の情報を突き合わせ、対応の要否を判断する材料を出します。ライセンスの確認は、OSSを使う製品のコンプライアンスに欠かせません。

昨日まで安全だった部品に、今日新しい脆弱性が見つかることもあるでしょう。そのため評価は一度で終わらせず、部品の更新や脆弱性の公表のたびに見直します。検出には誤検知も混じるので、最終的な判断は人が担う前提です。

SBOMが求められる場面は、製品を出す市場と分野でほぼ絞り込めます。どの規制も、ソフトウェア構成を把握し、脆弱性に対応できる体制があるかを問うています。代表的な4つの場面を見ていきましょう。

EU向け製品のCRA対応

EU市場に組込み機器やIoT製品を出す企業の、製品セキュリティ担当者が使う場面です。CRA（サイバーレジリエンス法）は、デジタル要素を含む製品のセキュリティを包括的に定める規制です。

ソフトウェア構成の把握と脆弱性対応が、より明確に求められる方向に進んでいます。その文脈で、SBOMの整備が重要な論点になっています。EU向けに製品を展開するなら、避けて通れないテーマでしょう。具体的な適合判断は、一次情報や専門家の確認を前提に進めてください。

車載ソフトウェアのWP.29対応

ECUや車載ソフトウェアを手がけるサプライヤーの、開発・品質担当者が使う場面です。国連のUNECE WP.29のもとでは、2つの規則が定められています。サイバーセキュリティに関するR155と、ソフトウェアアップデートに関するR156です。

あわせて、国際規格のISO/SAE 21434も定められています。開発から運用までの、サイバーセキュリティ活動の枠組みを示す規格です。製品に含むソフトウェアの構成管理と脆弱性対応は、この枠組みで求められる取り組みの一部です。

産業機器・医療機器の規制対応

制御システムや産業用機器のメーカーでは、IEC 62443が広く参照されています。産業用オートメーション・制御システムのサイバーセキュリティに関する国際規格です。構成の把握は、この規格が求める対策の基盤になります。

医療機器では、米FDAをはじめとする規制当局が要求を強めています。患者の安全に直結するため、出荷後を含む脆弱性管理が重視される分野です。承認と市販後対応の双方で、SBOMの提出・整備が論点になっています。

取引先からの提出要求への対応

部品や機器を納める企業の、品質保証担当者が使う場面です。調達側の企業が、取引先にSBOMの提出を求めるケースが増えています。出せないことが、採用の可否に響く場合もあるでしょう。

国内では、経済産業省がSBOMの導入に関する手引を公表しています。企業がSBOMをどう整備・活用するかの考え方を示した資料です。国内メーカーが自社の取り組みを設計する際の出発点として参照されています。海外規制の対象外でも、この手引から始めると進めやすいでしょう。

SBOMの作成・管理にかかる費用は、ツールの解析方式や対象の製品数、利用規模によって変わります。多くのツールは個別見積で、価格を公開している製品は一部です。導入支援やコンサルティングを含むサービスもあります。ツール代に加え、検出結果を判断する人員の工数も見込んでおきましょう。

料金体系の違いはSBOMツールの費用の解説記事で整理しています。製品ごとの価格は、ITトレンドの組込みセキュリティ（SBOM/SCA）カテゴリで比較できます。

SBOMとあわせてよく出てくるのが、SCA（ソフトウェア構成分析）です。どちらもOSSや部品の把握に関わりますが、SCAは手段、SBOMは成果物という関係にあります。

SCAで部品を検出し、その結果をSPDXやCycloneDXの形式で出力したものがSBOMです。SCAツールを使えば、SBOMの作成を自動化できます。

ただしSBOMの価値は、作った後の運用と結びついて初めて発揮されます。新しい脆弱性が出たときに影響範囲を照合し、出荷済み製品も含めて管理し続けることが欠かせません。ツールの違いはSBOM管理ツールの比較記事で確認できます。

SBOMが要るかは、企業規模ではなく、製品に組み込むソフトウェアと出荷先の市場で決まります。規制や取引先の要求を受けるかが分かれ目です。自社がどちらに当てはまるかを確かめてください。

SBOMの導入が向いている企業

組込み機器・IoT・車載・医療機器を開発し、OSSや外部部品を多く組み込んでいる企業です。EU向けの出荷や、取引先からのSBOM提出の要求を受けている企業は、早めの着手が欠かせません。ソースが手元にない部品を多く使うなら、バイナリ解析に対応したツールから検討してください。

製品が長く使われる企業ほど、効果は大きくなります。何年も前の出荷製品まで遡って、影響を照合できるためです。ツールの選び方はSBOMツールの選び方の記事で解説しています。

SBOMの導入が向いていない企業

製品にソフトウェアを組み込んでいない企業では、SBOMで管理する対象がそもそもありません。規制や取引先の要求を受けていない場合も、急いで全面導入する必要は薄いでしょう。

検出結果を判断する人員がいないまま、全製品を一度に対象にする進め方も向いていません。誤検知に振り回され、現場が疲弊しがちです。社内にノウハウが乏しいなら、国産や国内SIerの導入支援から始める方法があります。日本語での情報提供や、運用に乗せるまでの伴走を受けられます。

SBOMとは、製品に含まれるOSSなどの部品を、バージョンや依存関係まで一覧化した部品表です。脆弱性が公表されたとき、影響範囲をすぐに照合するために使われます。

最初に確かめるのは、ソースが手元にない部品の比率です。比率が高ければ、バイナリ・ファームウェア解析型のツールが候補になります。ソースを管理する部品が中心なら、SCA型のツールで対応できます。形式は、提出先の要件に合わせて選ぶのが基本です。

検出結果には誤検知が混じるため、判断する体制が要ります。影響の大きい1製品から始めてください。製品は組込みセキュリティ（SBOM/SCA）カテゴリで比較できます。