SBOMとは？意味・規制・作り方とツールをやさしく解説

SBOMとは Software Bill of Materials の略で、日本語では「ソフトウェア部品表」と訳されます。製造業の方には、製品を構成する部品をすべて書き出した「部品表（BOM）」のソフトウェア版、と説明するのが最も分かりやすいでしょう。ハードウェアの部品表が、ネジやコンデンサ、基板といった構成部品を型番や数量とともに列挙するように、SBOMはソフトウェア製品に含まれる構成要素を列挙します。

では、ソフトウェアにおける「部品」とは何か。現代の組込み機器やアプリケーションは、自社でゼロから書いたコードだけで動いているわけではありません。OSS（オープンソースソフトウェア）のライブラリ、サードパーティ製の商用コンポーネント、通信ライブラリ、暗号ライブラリなど、外部から調達した数多くの部品の上に成り立っています。SBOMは、こうした構成部品について、少なくとも次のような情報を記録します。

• 部品の名称：含まれているOSS／サードパーティ製ソフトウェアの名前。
• バージョン：どのバージョンを使っているか。脆弱性は特定バージョンに紐づくため、ここが極めて重要です。
• ライセンス：その部品がどのライセンス（OSSライセンス等）で提供されているか。
• 依存関係：どの部品が、どの部品に依存して動いているかという構造。ある部品が内部でさらに別の部品を呼んでいる、という入れ子の関係を含みます。

つまりSBOMとは、「この製品の中には、どのソフトウェア部品が、どのバージョンで、どんなライセンスで、どう組み合わさって入っているのか」を機械可読な形で表した一覧表です。これがあると、新しい脆弱性が公表されたときに「自社のどの製品の、どのバージョンに、その部品が含まれているか」を一覧から照合して即座に把握できます。逆にSBOMがないと、いざ重大な脆弱性が出たときに、自社製品が影響を受けるかどうかを調べるだけで膨大な手間がかかり、対応の初動が決定的に遅れます。

SBOMという考え方自体は新しいものではありませんが、ここ数年で「あれば望ましいもの」から「整備が前提のもの」へと位置づけが急速に変わりました。背景には大きく三つの流れがあります。

ソフトウェアサプライチェーン攻撃の増加

一つ目は、ソフトウェアサプライチェーンを狙った攻撃の増加です。攻撃者は、防御の固い最終製品を正面から狙うのではなく、その製品が取り込んでいるOSSや外部部品、ビルドの過程といった「上流」を侵害し、そこを経由して多数の製品・利用者に影響を及ぼす手口を取るようになりました。自社製品の中に、知らないうちに改ざんされた部品や、後から脆弱性が見つかった部品が紛れ込むリスクが現実のものになっています。どの部品が入っているかを把握できていなければ、こうした攻撃に対して「自社は影響を受けるのか」すら判断できません。

OSSの脆弱性管理（Log4jの教訓）

二つ目は、OSSの脆弱性管理の難しさです。象徴的だったのが、広く使われていたログ出力ライブラリ Log4j に重大な脆弱性が見つかった事例です。あまりに多くのソフトウェアに組み込まれていたため、世界中の開発組織が「自社の製品やシステムのどこにLog4jが、どのバージョンで含まれているのか」の洗い出しに追われ、その確認作業だけで多大な時間を費やしました。このとき、製品ごとのSBOMが整備されていれば、影響範囲の特定は一覧の照合で済んだはずです。OSSは開発を効率化する一方で、いったん広く使われている部品に脆弱性が出ると影響が連鎖的に広がるため、「何を使っているかを常に把握しておく」ことの価値が改めて認識されました。

規制・取引要件としての要求

三つ目は、規制や取引上の要件としてSBOMが求められ始めたことです。後の章で詳しく触れますが、EUや車載・医療機器などの分野で、製品のサイバーセキュリティを担保する文脈においてソフトウェア構成の透明性が問われるようになり、その手段としてSBOMが位置づけられつつあります。規制だけでなく、調達側の企業が取引先に対してSBOMの提出を求めるケースも増えており、「SBOMを出せないと製品を採用してもらえない」という商談上の現実も生まれています。

編集部コメント：SBOMは「セキュリティ部門が片手間でやる管理表」ではなく、開発・品質・調達・法務（ライセンス）が横断して関わる経営課題になりつつあります。特に組込み・車載・医療機器のように製品ライフサイクルが長く、出荷後も長期にわたって脆弱性対応が必要な分野では、「作って終わり」ではなく「出荷後も更新し続ける」前提で体制を考える必要があります。最初に小さく始めても、運用を回し続けられる座組みかどうかを早めに見極めてください。

SBOMへの注目を一気に高めたのが、各国・各分野の規制やガイドラインの動きです。自社の製品分野がどれに該当するかを意識しながら読んでください。なお、ここでは各規制の位置づけの概要を示すにとどめ、具体的な適合判断は必ず一次情報や専門家の確認を前提としてください。

EU：CRA（サイバーレジリエンス法）

EUのCRA（Cyber Resilience Act、サイバーレジリエンス法）は、デジタル要素を含む製品のサイバーセキュリティを包括的に規律しようとする規制です。EU市場に製品を出すメーカーにとって、製品に含まれるソフトウェア構成の把握や脆弱性対応がより明確に求められる方向にあり、その文脈でSBOMの整備が重要な論点になっています。EU向けに組込み機器やIoT製品を展開する企業は、避けて通れないテーマです。

車載：UNECE WP.29（R155／R156）・ISO/SAE 21434

自動車分野では、国連の枠組みであるUNECE WP.29のもとで、サイバーセキュリティに関するR155、ソフトウェアアップデートに関するR156といった規則が定められています。あわせて、車載システムのサイバーセキュリティに関する国際規格 ISO/SAE 21434 が、開発から運用までのサイバーセキュリティ活動の枠組みを示しています。車載部品・ECU・車載ソフトウェアを手がけるサプライヤーにとって、製品に含まれるソフトウェアの構成管理と脆弱性対応は、こうした枠組みのもとで求められる取り組みの一部となります。

産業・OT：IEC 62443

工場の制御システムや産業用機器（OT領域）では、IEC 62443 が産業用オートメーション・制御システムのサイバーセキュリティに関する国際規格として広く参照されています。産業機器メーカーや制御システムを提供する事業者にとって、製品やシステムを構成するソフトウェアの把握は、この規格が求めるセキュリティ対策を進めるうえでの基盤になります。

医療機器：米FDA等のサイバーセキュリティ要求

医療機器の分野では、米FDA（米国食品医薬品局）をはじめとする規制当局が、医療機器のサイバーセキュリティに関する要求を強めています。患者の安全に直結する医療機器では、製品に含まれるソフトウェア構成の透明性と、出荷後を含む脆弱性管理が重視されており、その手段としてSBOMの提出・整備が論点になっています。医療機器メーカーにとっては、製品の承認・市販後対応の双方に関わるテーマです。

日本：経済産業省のSBOM導入手引

日本国内では、経済産業省がSBOMの導入に関する手引を公表し、企業がSBOMをどのように整備・活用していくかの考え方を示しています。海外規制への対応を迫られる輸出企業だけでなく、国内のソフトウェアサプライチェーン全体でSBOMの活用を進めようという流れの中で、国内メーカーが自社の取り組みを設計する際の出発点として参照されています。

編集部コメント：規制名が多くて圧倒されるかもしれませんが、自社にとって関係するものは製品分野でほぼ絞り込めます。EU向け製品ならCRA、車載ならWP.29／ISO21434、産業機器ならIEC62443、医療機器ならFDA等、というように「自社製品がどの市場・分野に出るか」から逆算するのが現実的です。共通して言えるのは、どの規制も突き詰めると「製品の中身（ソフトウェア構成）を把握し、脆弱性が出たら対応できる体制があるか」を問うており、その土台がSBOMだ、という点です。

SBOMは「自由なフォーマットのメモ書き」では意味がありません。ツール間でやり取りしたり、取引先に提出して機械的に処理してもらったりするには、標準化された形式である必要があります。現在、代表的な形式として広く使われているのが SPDX と CycloneDX の二つです。

SPDX

SPDX（Software Package Data Exchange）は、ソフトウェアの構成情報やライセンス情報を記述・交換するための標準形式です。もともとライセンスの管理・開示を重視する文脈で発展してきた経緯があり、OSSライセンスのコンプライアンス（ライセンス順守）の用途でも広く使われています。SBOMの国際的な標準形式の一つとして、多くのツールが対応しています。

CycloneDX

CycloneDX は、セキュリティ用途を強く意識して設計されたSBOMの標準形式です。脆弱性管理やソフトウェアサプライチェーンのセキュリティとの親和性が高く、こちらも多くのSCA／SBOMツールが対応しています。SPDXと並ぶ代表的な形式として、どちらを採用・受け入れるかは、提出先の要件や利用するツールの対応状況を踏まえて選ぶことになります。

実務上は、SPDXとCycloneDXのどちらか一方だけ知っていれば足りるというより、「提出先がどちらの形式を求めるか」によって対応が変わります。そのため、利用するツールが両形式の出力に対応しているかは、製品選定時の確認ポイントの一つになります。

SBOMをどうやって作るのか。手作業ですべての部品とバージョン、依存関係を書き出すのは、現代の複雑なソフトウェアでは現実的ではありません。ここで中核となる技術が SCA です。

SCA（ソフトウェア構成分析）とは

SCA（Software Composition Analysis、ソフトウェア構成分析）とは、ソフトウェアのソースコードや依存関係を解析して、その中に含まれるOSSやサードパーティ製部品を特定し、さらにそれらに既知の脆弱性やライセンス上の問題がないかを洗い出す手法です。どの部品が、どのバージョンで含まれているかを自動的に検出してくれるため、SCAはSBOM生成の中核を担います。検出した構成情報をSPDXやCycloneDXの形式で出力することで、SBOMが生成できます。

SBOM作成の基本的な流れ

一般的な進め方を整理すると、おおむね次のような流れになります。

1. 対象範囲を決める：どの製品・どのリリースについてSBOMを作るのかを定めます。
2. SCAで構成を解析する：ソースコードや依存関係（場合によってはバイナリ）をSCAツールで解析し、含まれるOSS・サードパーティ部品とバージョンを検出します。
3. SBOM形式で出力する：検出した構成情報を、SPDXやCycloneDXといった標準形式で出力します。
4. 脆弱性・ライセンスを評価する：検出された部品に既知の脆弱性や問題のあるライセンスがないかを確認し、対応の要否を判断します。
5. 更新し続ける：部品の追加・更新や新たな脆弱性の公表に応じて、SBOMと脆弱性評価を継続的に見直します。

ここで強調しておきたいのは、SBOMは「一度作れば終わり」ではない、という点です。製品のソフトウェアは更新されますし、昨日まで安全だった部品に今日新しい脆弱性が見つかることもあります。SBOMの本当の価値は、作った後に「新しい脆弱性が出たとき、影響範囲をすぐ照合できる」「出荷済み製品も含めて継続的に管理できる」運用と結びついて初めて発揮されます。

編集部コメント：SCAツールを入れれば自動でSBOMが出る、という期待は半分正しく、半分は注意が必要です。自動検出は強力ですが、検出結果には誤検知（実際には使っていない、あるいは影響しない部品を脆弱性ありと判定する等）が一定割合で混じります。すべての検出をそのまま鵜呑みにすると、本来対応不要なものに振り回され、現場が疲弊します。検出結果を「自社製品にとって本当に影響があるか」を判断・トリアージする人と体制が、ツールとセットで必要になる点を見込んでおいてください。

ここまではソフトウェア全般に共通する話ですが、組込み機器・IoT・車載・医療機器には、Webアプリやクラウドのソフトウェアにはない固有の難しさがあります。

ソースコードが手元にない部品がある

組込み開発では、自社でソースコードを管理している部分だけでなく、サプライヤーから提供されたバイナリ、チップベンダーが提供するSDKやドライバ、過去のプロジェクトから引き継いだファームウェアなど、ソースコードが手元にない構成要素が珍しくありません。SCAの多くはソースコードや依存関係の定義（パッケージのマニフェストなど）を起点に解析しますが、ソースが手元にない部品については、その手法だけでは中身を把握できないことがあります。

バイナリ／ファームウェアの解析が必要になる

そこで組込み分野では、ソースコードがなくても、製品に書き込まれるバイナリやファームウェアそのものを解析して、中に含まれるOSSやコンポーネントを特定する必要が出てきます。最終的に製品へ焼き込まれるイメージを解析対象にできれば、「実際に出荷される製品の中に何が入っているか」をより実態に即して把握できます。これは、ソースベースの解析だけを前提としたツールでは対応しきれない領域であり、組込み向けのSBOM／SCA対応を考えるうえで決定的な分かれ目になります。

長い製品ライフサイクルと出荷後の管理

さらに組込み・車載・医療機器は、出荷してから何年も、製品によっては十年以上使われ続けます。その間に新しい脆弱性は次々と公表されます。つまり、開発時点のSBOMを作るだけでなく、出荷後の長期にわたって構成情報を保持し、新たな脆弱性が出るたびに過去の出荷製品まで遡って影響を照合できる仕組みが求められます。製品ライフサイクルの長さは、組込み分野でSBOM運用が一段と重くなる理由です。

SBOMやSCAに対応するツール・サービスは数多くありますが、組込み・製造業の視点で整理すると、大きく次の三つのタイプに分けて捉えると見通しが良くなります。SBOM／SCAツールは【SCA（ソース／依存）型・バイナリ／ファームウェア解析型・国産／導入支援型】で整理できる、と覚えておくと選定の軸になります。

SCA（ソース／依存）型・開発フロー統合型

ソースコードや依存関係の解析を中心に、開発フロー（DevSecOps）の中で脆弱性・ライセンスを継続的にチェックするタイプです。開発者が日々のビルドやパイプラインの中で使うことを想定したものが多く、この領域には Snyk（開発者ファーストを掲げるタイプ）、JFrog（Xray）、Sonatype、Mend などがあります。開発の早い段階から脆弱性を検出し、継続的に管理したいニーズに向きます。また、ライセンスの開示・管理の用途では Revenera のような製品もこの周辺に位置づけられます。なお、SCA最大手の Black Duck は、ソースに加えてバイナリの解析にも対応する点で、次のバイナリ解析型ともまたがる位置づけです。

バイナリ／ファームウェア解析型

ソースコードが手元にない部品や、製品に焼き込まれるバイナリ・ファームウェアそのものを解析して構成を特定するタイプです。前章で述べた組込み特有の課題に正面から対応する領域で、車載・医療機器など規制対応の文脈で使われます。バイナリ／ファームウェア解析を強みとし、車載・医療機器向けの規制対応を意識した Cybellum や、ソースに加えバイナリ解析にも対応する Black Duck が、この領域の代表例です。ソース非保有部品の比率が高い組込み製品では、このタイプの対応可否が選定の決め手になります。

国産・導入支援型

日本語での情報提供やサポートを重視するなら、国産のサービスや、国内SIerによる導入支援という選択肢があります。国産で日本語に対応した yamory のようなサービスや、テクマトリックス、日立ソリューションズといった国内SIerによる導入支援は、社内にSBOM／SCAのノウハウが乏しい段階での立ち上げや、日本語でのやり取り・体制づくりを重視する企業に向きます。ツール単体ではなく、運用設計や体制づくりまで含めて支援してほしい場合に検討する領域です。

ここまでの内容を、現場でよくある目的別に整理します。自社の優先順位がどこにあるかで、検討すべきツールのタイプが変わります。なお、いずれの製品も最終的な機能や対応範囲は自社の条件での確認が前提です。

開発フローに組み込みたい

ソースコードや依存関係を管理しており、開発・ビルドのパイプライン（DevSecOps）の中で継続的に脆弱性・ライセンスをチェックしたいなら、SCA（ソース／依存）型・開発フロー統合型が向きます。開発者ファーストを掲げる Snyk や、JFrog（Xray）、Sonatype、Mend などがこの領域の候補です。早い段階から検出して直す運用を回したいケースに合います。

車載・医療機器の規制対応をしたい

WP.29／ISO21434（車載）やFDA等（医療機器）といった規制対応が主目的で、製品に焼き込まれるバイナリ・ファームウェアの解析や規制を意識した運用が必要なら、バイナリ／ファームウェア解析型が中心になります。車載・医療機器向けの規制対応を意識した Cybellum や、ソース＋バイナリの解析に対応する Black Duck が候補です。規制側が求める形式・運用に合わせられるかを確認してください。

ソースを持たないバイナリを解析したい

サプライヤー提供のバイナリやファームウェアなど、ソースコードが手元にない部品の比率が高い場合は、ソースベースだけのツールでは不十分です。バイナリ／ファームウェアそのものを解析できる Cybellum や、バイナリ解析に対応する Black Duck のような、バイナリ解析型の対応可否を最優先で見てください。「実際に出荷されるイメージの中身を把握できるか」が判断軸になります。

日本語サポートを重視したい

社内にノウハウが乏しく、日本語での情報提供・サポートや、立ち上げ・体制づくりの支援まで求めるなら、国産・導入支援型が向きます。国産で日本語対応の yamory や、テクマトリックス・日立ソリューションズといった国内SIerの導入支援が候補です。ツールの導入そのものより、運用に乗せるまでの伴走を重視する場合に有効です。

最後に、SBOM対応をどう進めるかと、要点の整理です。

進め方としては、いきなり全製品・全工程を完璧に対応しようとせず、影響の大きい一製品・一ラインから小さく始めるのが現実的です。まずは対象を絞ってSCAで構成を可視化し、検出された脆弱性・ライセンスをトリアージしてみる。そこで「誤検知がどの程度出るか」「誰が判断するのか」「出荷後の更新を誰が担うのか」といった運用上の論点を洗い出し、体制とルールを育ててから対象を広げていきます。ツール選定と同じかそれ以上に、検出結果を製品にとっての意味へ翻訳し、対応を回し続ける体制づくりが成否を分けます。

SBOMのメリットは、脆弱性が公表されたときに影響範囲を即座に照合できること、ソフトウェア構成の透明性によって規制・取引要件に応えられること、ライセンスの問題を早期に把握できることなどです。一方で、誤検知への対応負荷、出荷後の長期運用を支える体制づくりの難しさ、組込み特有のバイナリ・ソース非保有部品への対応といった現実的なハードルも小さくありません。メリットだけを見て導入すると、検出結果の山に現場が疲弊する、という典型的な失敗に陥りがちです。

要点を整理すると、SBOM（ソフトウェア部品表）とは製品に含むOSS・サードパーティ部品をバージョン・ライセンス・依存関係まで一覧化したものであり、その作成の中核を担うのがSCA（ソフトウェア構成分析）です。形式はSPDXとCycloneDXが代表的で、提出先の要件に応じて使い分けます。規制は分野ごとに——EUのCRA、車載のWP.29／ISO21434、産業のIEC62443、医療機器のFDA等、国内では経済産業省の手引——存在し、いずれも「中身を把握し脆弱性に対応できる体制」を問うています。組込み機器ではバイナリ・ファームウェアの解析やソース非保有部品への対応、長い製品ライフサイクルが固有の課題となり、ツールは【SCA（ソース／依存）型・バイナリ／ファームウェア解析型・国産／導入支援型】で整理して、自社の目的に合わせて選ぶのが要点です。

具体的なツールの比較検討にあたっては、各製品の解析方式（ソース／バイナリ）、対応する規制分野、SBOM形式（SPDX／CycloneDX）の対応、日本語サポートの有無などを横並びで確認すると違いがつかみやすくなります。カテゴリ全体の製品は組込みセキュリティ（SBOM/SCA）の製品一覧から確認できます。また、SBOMで管理する対象であるソフトウェア本体については、組み込みソフトウェア（RTOS）のカテゴリもあわせて参照すると、製品全体のソフトウェア構成を理解しやすくなります。