SBOMの生成方式とは、SBOMを作る際に「何を入力データとして部品を洗い出すか」による分類で、ソース解析・パッケージ解析・バイナリ解析の3つに整理できます。
バイナリ解析は、ビルド済みの成果物(実行ファイルやファームウェアイメージなど)を直接解析してコンポーネントを特定する方式です。
【結論】
3つの方式は入力データや得意分野が異なり、単純な優劣はつけられない。手元にある成果物と目的によって向き不向きが決まる
バイナリ解析は、ソースコードや依存関係ファイルがなくても出荷物そのものを対象にでき、調達品や出荷済み製品の棚卸しで役立つ。一方で、成果物から推定する方式のため、結果の確認は欠かせない
自社でソースを持つ部分はソース・パッケージ解析、調達品や出荷済み製品はバイナリ解析、というように、方式を使い分ける・併用するのが現実的である
本記事では、3つの生成方式の違いと、バイナリ解析が必要になる場面、自社に合う方式の選び方を整理して解説します。
1. SBOMの生成方式には、どんな種類があるのか？
SBOMの生成方法は、解析の入力にするデータに着目すると、ソース解析・パッケージ解析・バイナリ解析の3つに整理できます。
なお、SBOMには生成時点や生成方法に応じた別の分類もあり、この3つが唯一の分類ではありません。
SBOM(ソフトウェア部品表)とは、製品に含まれるソフトウェアの構成部品を一覧にしたものです。
SBOMそのものの基本は、以下の記事で解説しています。
SBOMの導入メリットや活用手順は、経済産業省の手引(ver2.0)で整理されています。
（出典：経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引ver2.0」公表ページ）
同じSBOMでも、「何を材料に部品を洗い出すか」はツールによって異なります。
この違いが、得意な対象や結果の見え方の違いにつながります。
ソース解析とは、ソースコードやビルド定義を読み取り、利用しているライブラリやOSSを洗い出す方式です。
自社で開発したコードに加え、取り込んだOSSのコードも対象にできます。
解析対象のソースコードにアクセスできることが基本的な前提です。
ただし、取得できる範囲に限って解析することも可能で、製品全体のソースコードを保有している必要があるとは限りません。
パッケージ解析とは、パッケージマネージャーの依存関係ファイルやロックファイルから、利用しているコンポーネントとバージョンを取得する方式です。
依存関係が宣言されている言語・開発環境と相性がよく、CI/CDに組み込んで継続的にSBOMを更新する用途で使われます。
一方で、依存関係ファイルなどに記録されていない部品や、手動で取り込まれたライブラリなどは検出できない場合があります。
バイナリ解析とは、ビルド済みの成果物そのものを入力にして、含まれるコンポーネントを推定する方式です。
成果物に含まれる文字列やファイルの特徴などから、どのOSSのどのバージョンが使われているかを判定します。
具体的な判定の仕組みはツールごとに異なります。
ソースコードや依存関係ファイルが手元になくても、出荷物や調達した成果物だけで部品を洗い出せる点が、他の2方式との大きな違いです。
ただし、すべての部品を検出できるわけではなく、検出できる範囲はファイル形式や部品の組み込み方、ツールの解析能力によって異なります。
生成時点による分類の一例として、米国CISAが各国機関と共同で2026年7月に公表した「2026 Minimum Elements for a Software Bill of Materials (SBOM)」では、SBOMの生成時点をビルド前・ビルド・ビルド後などで区別しています。
また、ソースコードから生成したSBOMはビルド前、バイナリ解析ツールで生成したSBOMはビルド後の例として示されています。
（出典：CISA「2026 Minimum Elements for a Software Bill of Materials (SBOM)」）
3つの方式の違いは、入力データ・得意な対象・注意点の3つの観点で整理できます。
|
観点 |
ソース解析 |
パッケージ解析 |
バイナリ解析 |
|
入力データ |
ソースコード、ビルド定義 |
依存関係ファイル、ロックファイル、パッケージ情報 |
ビルド済みの実行ファイル、ファームウェアイメージなど |
|
前提条件 |
解析対象のソースコードにアクセスできること |
依存関係が宣言・管理されていること |
解析対象の成果物を入手できること |
|
得意な対象 |
自社開発コードの構成把握 |
依存関係が明示された言語・開発環境 |
調達品・出荷済み製品・ソースのない組み込みソフト |
|
注意点 |
ソースを取得できない第三者製部品は、コード自体の解析ができない |
依存関係情報に記録されていない部品は検出しにくい |
成果物からの推定のため、誤検知や未検出の確認が必要 |
|
主な利用場面 |
自社開発時の部品管理 |
CI/CDでの継続的な更新 |
調達品の確認、出荷前・出荷後の棚卸し |
要点は、ソース解析は開発中のコード、パッケージ解析は管理された依存関係、バイナリ解析はビルド済みの成果物を主な情報源とする点にあります。
実際の出荷物の構成を確認したい場合は、バイナリ解析が有力な候補になります。
どの方式にも向き不向きがあり、「ソース解析が正確でバイナリ解析が簡易」といった単純な優劣は成り立ちません。
方式によって主な情報源や検出できる範囲が異なるためです。
各方式とも、SPDXやCycloneDXといった標準フォーマットで出力できるツールがあります。
ただし、対応する形式やバージョンはツールごとに異なります。
フォーマットの違いは、以下の記事で解説しています。
バイナリ解析が特に役立つのは、解析したい対象のソースコードや依存関係ファイルを入手できない場面です。
代表的には、次のようなケースがあります。
外部から調達したモジュールやファームウェアに、どのOSSが含まれているかを確認したい場合
出荷済みの製品について、ソースコードの管理状況にかかわらず、実際に出荷した成果物の構成を棚卸ししたい場合
複数のベンダーの成果物を統合した製品で、最終成果物に含まれる部品をまとめて調査したい場合
取引先や顧客から、出荷物ベースのSBOMの提出を求められた場合
たとえば、外部ベンダーからファームウェアだけを提供された場合、ソースコードや依存関係ファイルがなくても、対応するバイナリ解析ツールでファームウェア内のOSSコンポーネントを調査できる場合があります。
IoT機器・組み込み機器は、複数の外部ベンダーのソフトウェアを組み合わせて開発されることが多く、すべての部品のソースコードを自社で保有しているとは限りません。
こうした事情から、組み込み機器の分野でバイナリ解析が使われる場面が多くなっています。
「ソースコードを入手できない状況で、具体的にどのような手順で進めるか」といった実務の進め方は、別の記事で整理する予定です。
本記事では、方式そのものの違いに絞って解説しています。
バイナリ解析は成果物から部品を推定する方式のため、検出結果を鵜呑みにせず、確認する工程を設けることが重要です。
注意したい点は次のとおりです。
誤検知と未検出: 実際には使っていない部品を検出したり、改変された部品や小さな部品を見落としたりする可能性がある。ライブラリが実行ファイルに組み込まれていたり、コンパイル時の最適化で特徴的な情報が失われていたりすると、部品の特定が難しくなる場合がある
バージョンの判定: 同じOSSでも、バージョンを特定できず幅を持った判定になる場合がある
依存関係の表現: 部品同士の親子関係や、どの機能がどの部品を使っているかといった情報は、ソース側の方が得やすい
対応するファイル形式: ファームウェアのファイルシステム形式や圧縮形式に対応していないと、中身を展開できない場合がある
これらは、バイナリ解析に限った欠点というより、「成果物しか見えない状態で部品を推定する」という方式の性質に由来するものです。
生成後に、開発担当者が把握している構成と突き合わせて確認する運用が望まれます。
方式は、手元にある成果物と、SBOMを何に使うかで選びます。
判断の目安を、次の表に整理しました。
|
自社の状況 |
向いている方式 |
理由 |
|
自社でソースコードを管理し、継続的にビルドしている |
ソース解析・パッケージ解析 |
開発の過程でSBOMを更新でき、依存関係も把握しやすい |
|
外部ベンダーの部品や、出荷済みの成果物が多い |
バイナリ解析 |
ソースがなくても、出荷物ベースで構成を確認できる |
|
自社開発部分と調達部分が混在している |
併用 |
自社部分は開発時に、調達部分・最終成果物はバイナリで確認する |
特に、自社開発部分と調達部分が混在する製品では、「どれか1つの方式に統一する」よりも、役割を分けて併用する方が、抜け漏れを減らしやすくなります。
SBOMツール全般の選び方(自社構築・外部委託の比較を含む)は、以下の記事で解説しています。
生成方式の違いを踏まえてツールを選ぶ際は、解析対象への対応状況、SBOMの出力形式、生成後の活用機能について、次の3点を確認することが重要です。
対応するSBOMフォーマット: SPDX・CycloneDXなど、取引先や規制対応で求められる形式で出力できるか
対応する成果物の形式: 解析対象のファームウェアのファイルシステム形式や、圧縮形式を展開できるか
脆弱性情報との照合: 検出した部品を、脆弱性データベースと照合して一覧にできるか。更新の頻度はどうか
ツール選定そのものの観点(自社構築か外部委託か、運用体制、費用など)は、5章で紹介した記事で整理しています。
本記事では、方式の違いという切り口に絞っています。
解析の入力としては不要ですが、結果の確認にはソース側の情報が役立ちます。
検出された部品が実際に使われているかどうかは、開発担当者が把握している構成や、ビルド定義と突き合わせることで確認しやすくなります。
併用は可能です。
たとえば、自社開発の部分はソース・パッケージ解析で開発の過程で管理し、出荷前の成果物や調達品はバイナリ解析で確認するといった使い分けがあります。
ただし、方式ごとに検出範囲や出力の粒度が異なるため、結果を統合する際は重複する部品を整理し、検出結果に差がある場合はビルド情報などと照合して確認することが重要です。
一概にはいえません。
バイナリ解析は成果物から推定する方式のため、確認が必要な場面はあります。
一方で、ソース・パッケージ解析は、実際に出荷された成果物とは異なる構成を表す可能性があります。
どちらの方式にも見えるものと見えないものがあり、目的に応じた使い分けが現実的です。
SBOMの生成方式は、入力データの違いによって、ソース解析・パッケージ解析・バイナリ解析に分けられます。
バイナリ解析は、ソースコードや依存関係ファイルがなくても、出荷物そのものから部品を洗い出せる点が特徴です。
ただし、成果物から推定する方式のため、誤検知や未検出を確認する運用は欠かせません。
自社の開発体制と手元の成果物に合わせて、方式を使い分ける、あるいは併用することが、SBOMの精度と運用負荷のバランスをとるうえでの基本になります。
「SBOMスキャナ」は、監視カメラ・ネットワーク機器・IoTデバイスなどの組み込みソフトウェアのバイナリを解析し、SBOMの生成と脆弱性情報の照合を行うツールです。
スタンドアロンのPCで実行でき、解析対象のバイナリを社外に出さずに運用できます。
オフライン環境でも解析できる構成で、SBOMはSPDX・CycloneDX形式に対応しています。
「ソースコードがない製品のSBOMをどう作ればよいか」「自社の成果物が解析対象になるか」といった段階でも、ご相談だけでお気軽にご連絡ください。
弊社、サイエンスパーク株式会社は1994年の創業より、ソフトウェア・ハードウェアのセキュリティ対策を30年以上に渡り続けてまいりました。
セキュリティリスクの診断から対策導入・運用までのお手伝いが可能ですので、お気軽にお問い合わせくださいませ。
ご相談だけでも大歓迎です。
参考情報・出典
・経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引ver2.0」(2024年8月29日公表)
・CISA「2026 Minimum Elements for a Software Bill of Materials (SBOM)」(2026年7月29日公開)