SBOMとは？ソフトウェア部品表の見方と脆弱性管理への活かし方
「この脆弱性、うちのシステムにも関係ある？」と聞かれたとき、製品名だけでは答えられないことがあります。
その確認を助けるのが、ソフトウェアの中身を記録したSBOMです。
この記事では、部品表の読み方から依存関係のたどり方、導入後の運用までを、架空の受注アプリの例で整理します。
この記事は以下のような人におすすめ！
- SBOMを求められたけれど、何を渡せばよいか分からない人
- 脆弱性情報から、自社製品への影響を確認したい人
- 部品表を作った後の管理方法まで知りたい人
SBOMはソフトウェアの「中身」をたどるための部品表
1-1. 製品名だけでは分からないことがある
SBOMはSoftware Bill of Materialsの略で、日本語では「ソフトウェア部品表」と呼ばれます。
アプリに含まれる部品の名前やバージョン、提供元、部品どうしの関係などを、機械でも処理できる形で記録します。
例えば、ある受注アプリが画面表示用のライブラリと、外部サービスへの通信に使うライブラリを組み込んでいるとします。
利用者に見えるのは受注画面でも、裏側では複数のソフトウェアが働いています。
そのうち一つに問題が見つかっても、受注アプリの商品名だけを探していたら、調査対象から漏れてしまうかもしれません。
SBOMがあると、「この製品には、この部品のこの版が含まれる」という確認の入口を作れます。（参考1、参考2）
1-2. 一覧があることと、安全であることは別
ここは、最初に押さえておきたいポイントです。
SBOMは中身を示すための情報であり、それ自体が攻撃を防いだり、修正プログラムを適用したりするわけではありません。
食品の原材料表示があっても、それだけで保存状態まで分からないのと似ています。
部品表を脆弱性情報や製品の利用状況と組み合わせ、対応が必要かを判断して初めて、日々の管理に活かせます。
SBOMで分かるのは、主に「何が含まれているか」です。
「自社で影響を受けるか」「いつ直すか」は、その先の確認で判断します。
部品名だけでなく、バージョンと依存関係を見る
2-1. 読むときは製品の対象版から確認する
部品の一覧を開いたら、いきなり件数を数えるよりも、まず「何の製品について作られたものか」を確認しましょう。
同じ受注アプリでも、バージョン2.3と2.4では、含まれる部品が変わることがあります。
開発中の構成と、実際に配布した構成が違うこともあります。
製品の版、生成日時、作成者、対象としたビルドや配布物をひも付けておくと、「最新のファイルだから正しいはず」という取り違えを避けやすくなります。
項目の名称や必須条件は、採用する形式・バージョン・提出先の要件で変わります。
次の表は、最初に確認する観点を整理したもので、特定規格の必須項目をすべて列挙したものではありません。（参考1、参考3、参考4）
| 見る項目 | 確認したいこと | 取り違えの例 |
|---|---|---|
| 対象製品・版 | 調べたい配布物と対応しているか | 本番2.3に開発中2.4の表を使う |
| 部品名・提供元 | 同名の別部品と区別できるか | 名前が似た別プロジェクトを照合する |
| バージョン・識別子 | 脆弱性情報の対象と結び付くか | 版が空欄のまま安全と判断する |
| 依存関係 | どの部品を通じて含まれるか | 直接使っていないので無関係と判断する |
| 作成日時・範囲 | いつの何を把握したものか | 古い表を更新後も使い続ける |
2-2. 間接的に入っている部品もたどる
依存関係とは、あるソフトウェアが動くために、別のソフトウェアを必要とする関係です。
受注アプリが通信部品を使い、その通信部品がさらに解析部品を使っているとしましょう。
開発者が解析部品を直接追加していなくても、結果として製品に含まれる場合があります。
このような間接依存を確認するには、平らな部品名の一覧だけでなく、どこからつながっているのかを見ることが大切です。
ただし、どこまで検出できるかは、作成方法や調査対象にも左右されます。
ソースコード、依存関係の管理ファイル、配布物、コンテナーなど、何を調べた結果なのかも合わせて確認してください。
「一覧にない」と「含まれていない」を、すぐに同じ意味にしないことが重要です。（参考1、参考2）
脆弱性が公表されたら、部品表から影響範囲を絞る
3-1. 最初は部品と対象バージョンを照合する
ここからは、部品表を使う場面を具体的に見てみましょう。
説明用の解析部品「Parser C」に脆弱性情報が出たと仮定します。
まず公表元の情報を読み、対象の製品・部品、影響するバージョン、修正版、回避策の有無を確認します。
次に、自社で管理するSBOMから、該当する可能性がある部品を探します。
同じ名前が見つかっても、それだけで影響ありと確定するのは早計です。
提供元や識別子、バージョンの表し方、製品側での組み込み方まで確認する必要があります。
判断に使う脆弱性識別子の基本は、関連記事のCVE解説も参考にしてください。
3-2. 「含まれる」と「悪用される」を分ける
該当する部品が見つかったら、今度は実際の利用状況を調べます。
問題のある機能を使っているか、外部から入力が届くか、製品の設定によって条件が変わるか、といった確認です。
この段階では、製品ベンダーのアドバイザリーや、開発担当者からの説明も役立ちます。
VEXは、製品に対する脆弱性の影響について、状態や根拠を伝えるための情報です。
SBOMを部品の情報、VEXを影響に関する説明、と分けると位置付けをつかみやすくなります。
ただし、「影響なし」という記載も、対象製品や版、評価時点、示された理由を確かめて利用します。（参考2）
3-3. 調査した結果と対応を残す
最後は、「調べました」で終わらせず、誰が何を判断したかを残します。
例えば、対象の製品版、確認したSBOM、参照したアドバイザリー、判断理由、担当者、次に見直す条件を一つの記録にまとめます。
修正が必要なら、適用時期や事前確認、切り戻しの方法も別途検討します。
更新後は、配布物と対応する新しい部品表を用意し、古い版との対応も追えるようにしておくと、後日の問い合わせに答えやすくなります。
この記事の部品名・バージョンは説明用です。
特定の製品に実在する脆弱性や、検証済みの修正手順を示したものではありません。
導入は「一つの製品を、継続して追えるか」から始める
4-1. 作成する側と、受け取る側を決める
最初から全システムの部品表を集めようとすると、途中で管理しきれなくなるかもしれません。
まずは、重要な製品を一つ選び、作成から受領、保管、更新までを通せるか確かめる方法が考えられます。
自社開発なら開発担当、購入製品なら供給元に、どの範囲の部品表を用意できるか確認します。
受け取る側も、セキュリティ担当だけで抱えず、製品の管理者や調達担当と役割を分けておきましょう。
ここで重要なのは、作成担当の名前よりも「問題が見つかったとき、誰へ確認できるか」が明らかになっていることです。
4-2. SPDXとCycloneDXは、受け渡し先との互換性で選ぶ
SBOMの代表的な表現形式には、SPDXとCycloneDXがあります。
どちらもソフトウェアの構成情報を扱えますが、形式の名前が同じでも、バージョンや出力する情報によって、受け手が処理できるかは変わります。
「有名な方を選ぶ」よりも、提出先が受け入れる形式と版、使うツールが読み込める情報、必要な識別子や依存関係を先に確認する方が現実的です。
実際のファイルでは、採用した仕様のスキーマや検証ツールも使って確認してください。
表の列を同じ名前で並べただけのファイルを、仕様に適合したSBOMと呼ばないようにしましょう。（参考3、参考4）
4-3. 更新のきっかけを決めておく
初回の部品表がきれいでも、製品の更新後に置き去りになれば、調査の頼りにはしにくくなります。
リリース、依存部品の変更、配布物の再作成など、どのタイミングで生成・受領するかを決めておくことが大切です。
ファイル名だけで管理するのが難しい場合は、製品版、作成日時、保管先、対応する配布物の識別情報をまとめた管理台帳を用意します。
古い版の記録を残すのは、過去の製品について問い合わせを受ける場面があるからです。
最新版を残すことと、旧版との対応をたどれることは、両方が必要になります。
4-4. 共有範囲と扱い方も確認する
部品表を渡す相手が増えるほど、共有のルールも重要になります。
内部向けの名称や構成情報、配布物の場所など、外部へ渡してよいか確認が必要な情報を含む場合があります。
公開範囲、契約、提出先の要件を確認し、認証情報や秘密鍵を部品表へ混ぜないようにしてください。
不足する項目があれば、不明のまま明示して供給元へ確認します。
名前やバージョンを推測して埋めると、見かけは整っても、調査を誤る原因になります。
例えば、小規模な開発チームなら、次のような表を最初の運用確認に使えます。
| 場面 | 確認すること | 残しておくもの |
|---|---|---|
| 受領時 | 対象版・形式・読み込み結果 | 原本と受領日、問い合わせ先 |
| 脆弱性公表時 | 部品と版の一致、製品での影響 | 根拠URL、判断日、担当者 |
| 修正時 | 変更対象と事前確認、適用結果 | 対応記録と新しい部品表 |
| 定期見直し | 管理対象の漏れ、更新停止 | 見直し結果と未解決事項 |
これは運用を始めるための整理例であり、各社に一律で適用される規格の必須手順ではありません。
SBOMについてよくある質問
5-1. 導入前に確認したい五つの疑問
Q1. SBOMがあれば、脆弱性診断は不要ですか？
不要にはなりません。
SBOMは構成情報を把握する助けになりますが、設定不備やアクセス制御の問題など、部品一覧だけでは確認できないこともあります。
部品の管理と、アプリや環境の検査を、異なる役割として組み合わせます。
Q2. SCAとSBOMは同じものですか？
同じではありません。
SCAはソフトウェアの構成を分析する取り組みやツールを指し、その結果としてSBOMを出力できる場合があります。
SBOMという成果物と、それを作成・分析する機能を区別すると理解しやすくなります。（参考5）
Q3. OSSだけを書けばよいのでしょうか？
対象をOSSだけに限定するとは限りません。
自社製や購入した部品も含め、製品と提出要件に応じて、何を記録するかを確認します。
対象外にした範囲がある場合は、後で受け手が分かるようにしておきましょう。（参考1、参考2）
Q4. ファイルを一度作れば完了ですか？
継続して使うなら、製品の変更に合わせた管理が必要です。
作成したときの製品版と、現在運用している版が違う場合、そのファイルだけで現在の影響を判断できるとは限りません。
Q5. 最初に供給元へ何を聞けばよいですか？
対象製品と版、提供可能な形式、部品の把握範囲、更新のタイミング、問い合わせ先を確認すると、受領後の運用を考えやすくなります。
そのうえで、自社の受け入れ要件と合うかを確かめましょう。
まとめ：部品表を、影響確認と次の対応につなげる
SBOMの役割は、ソフトウェアの中身を確認しやすくすることです。
まず製品版と部品表の対応を確かめ、部品名・バージョン・依存関係を読みます。
脆弱性情報と一致する候補があれば、実際の製品で影響するかを調べ、判断と対応を残します。
いきなり大きな仕組みを作らなくても、一つの製品で「受け取る・確認する・更新する」を通してみると、足りない情報や担当の曖昧な部分が見えてきます。
SBOMを集めることだけを目的にせず、問い合わせや脆弱性対応で実際に使える状態を目指しましょう。
