SBOM完全ガイド｜SPDX / CycloneDX / Excel運用・提出と機密の現実解

SBOMとは何か

提出書類ではなく、運用資産として理解する

SBOMは Software Bill of Materials の略で、ソフトウェアを構成するコンポーネントの一覧です。分かりやすく言えば、ソフトウェアの部品表です。

ただし、ここで重要なのは「部品表だから一覧にして終わり」ではないという点です。SBOMが本当に価値を持つのは、脆弱性管理や製品説明とつながったときです。たとえばCVEが公開されたとき、SBOMがあれば「その部品が自社製品に入っているか」「どのバージョンに入っているか」をすぐ確認できます。逆にSBOMがないと、そのたびに設計担当・ソフト担当・品質保証が個別に調査し、回答が遅れます。

自動車サプライヤーの実務では、SBOMは次の3つの役割を持ちます。

1. 構成の可視化：何が入っているかを一覧で把握する
2. 脆弱性対応の初動短縮：CVEが出たときに対象製品を早く絞る
3. OEM・監査への説明責任：「なぜ影響あり / なしなのか」を根拠付きで返す

この3つを満たすなら、SBOMは単なる資料ではなく、運用資産になっています。

なぜ自動車サプライヤーにSBOMが必要なのか

規制対応だけでなく、OEM照会と監査対応のため

SBOMが必要になる理由を「規制だから」とだけ言うと、現場では腹落ちしません。本当に重要なのは、OEMや監査対応の現場で、SBOMがないと何も答えられなくなることです。

たとえば、あるOSSライブラリに重大な脆弱性が見つかったとします。OEMから「あなたの部品に影響はありますか」と聞かれたとき、SBOMがなければ次のような状況になりがちです。

• そもそも対象ライブラリを使っているか分からない
• 使っていても、どの製品バージョンまで入っているか分からない
• 同じライブラリでも機能や設定が違い、影響の有無が判断できない
• OEMに返すまで数日〜数週間かかる

これでは、規制以前に取引上の信頼を失います。だからこそSBOMは、法規対応のためだけではなく、日々の照会・監査・是正計画に答えるための基盤として必要です。

特にTier2〜Tier4サプライヤーでは、PSIRT専任者がいないことも多く、脆弱性対応が兼務で回っています。その場合、SBOMがあるかないかで、初動速度が大きく変わります。つまりSBOMは、人が足りない現場ほど効く仕組みです。

SPDX と CycloneDX の違い

どちらが正しいかではなく、何に使うかで選ぶ

SBOMを始めようとすると、ほぼ必ず「SPDX と CycloneDX のどちらを選ぶべきか」という話になります。結論から言うと、どちらが上かではなく、自社の用途にどちらが合うかで考えるべきです。

実務では次のように考えると分かりやすいです。

• 提出や標準性を優先 → SPDX寄り
• 脆弱性管理や自動化を優先 → CycloneDX寄り
• まだ運用が固まっていない → Excelから始めて後で標準化

最初からフォーマットだけを決めると、運用が追いつかずに形骸化しやすいです。大切なのは、「誰が、どの情報を、何のために使うか」を決めることです。

Excelから始めてよい

最初から完璧な標準対応を目指さない

ここが、多くの現場で一番安心してよいポイントです。最初はExcelで始めて構いません。

特に中小サプライヤーでは、いきなりSPDXやCycloneDXの完全運用へ入ると、整備より先に運用が止まります。理由は単純で、部品表そのものがまだ整理されていないからです。その状態で標準フォーマットだけ導入しても、ファイルはできても更新されません。

現実的なやり方はこうです。

1. まずExcelで主要製品の構成を棚卸しする
2. 製品バージョンとコンポーネントバージョンをひも付ける
3. 更新タイミングと責任者を決める
4. 運用が回り始めてからSPDX / CycloneDXへ寄せる

この順番にすると、「SBOMを作ったのに誰も使わない」を避けやすくなります。

SBOMに最低限入れるべき項目

まずは“答えられる状態”を作る

MVPとして始めるなら、最低限以下の項目を入れてください。

この中で特に重要なのは、製品バージョン と コンポーネントバージョン を分けて持つことです。ここが分かれていないと、CVEが出たときに「どの製品まで影響するか」が追えません。

また、搭載箇所 と 備考 も重要です。同じライブラリでも、ある製品では外部から到達可能で、別の製品では内部利用だけということがあります。後でVEXや影響判定に進むと、この差が大きく効いてきます。

SBOMの更新頻度と版管理

作った瞬間から古くなる前提で設計する

SBOMの失敗は、作成よりも更新で起きます。一覧を一度作っても、更新ルールがないとすぐに使えなくなります。最低でも、次のタイミングでは更新対象にすべきです。

• 新規リリース時
• マイナー更新時
• パッチ適用時
• 外部ライブラリ更新時
• 機能追加や構成変更時
• OEM提出前

ここでおすすめなのは、製品版数 と SBOM版数 を分けることです。たとえば製品が 2.1.0 でも、SBOMは 2.1.0-a / 2.1.0-b のように改訂される場合があります。これを分けておくと、「製品は同じだが部品表の記述を更新した」「脆弱性情報の追記をした」といった変更履歴を残しやすくなります。

機密情報と提出範囲

“全部出す”と“何も出せない”の間を設計する

SBOMで現場が止まりやすいのが、機密の扱いです。「部品表を出すと設計情報まで見えてしまうのではないか」という不安はもっともです。ここで重要なのは、SBOMを作ること と 全情報を開示すること を分けることです。

現実的には、次の3層で考えると整理しやすくなります。

1. 社内完全版：搭載箇所、備考、ビルド条件、設定差分まで含む
2. OEM提出版：必要なコンポーネントと版数を中心にする。設計の詳細や内部事情は必要最低限にする
3. 照会回答版：対象CVEに関係する部分だけを抜粋する。影響有無と根拠に絞る

このように分けておくと、社内での精密運用と、外部への適切な開示を両立しやすくなります。SBOMは「全部を見せるための資料」ではなく、「必要な範囲を説明するための基盤」です。

SBOMと脆弱性管理をどうつなぐか

NVD / CPE / PURL / VEX の基本動線

SBOMの価値が最も発揮されるのは、脆弱性管理と接続したときです。たとえばNVDやJVNでCVEが公開されたとき、次の流れで判断できるようになります。

1. SBOMで対象コンポーネントが存在するか確認する
2. バージョン一致を確認する
3. 搭載箇所や利用条件を確認する
4. 影響あり / なし / 要確認を判断する
5. OEMへ説明する

ここで重要なのが識別子です。OSS系では PURL が扱いやすく、NVD照合や説明では CPE の理解も必要になります。識別子が曖昧だと、誤検知も見落としも増えます。つまりSBOM整備は、一覧表づくりであると同時に、脆弱性照合のための識別子設計 でもあります。

さらに、SBOMだけでは「入っているか」は分かっても、「その脆弱性が実際に影響するか」は分かりません。そこで必要になるのが VEX です。VEXの考え方を使うと、同じCVEでも次のような説明が可能になります。

• コンポーネントが存在しない
• 脆弱コードが含まれない
• 実行経路に乗らない
• 攻撃者が制御できない
• 緩和策がすでにある

この説明ができると、「影響なし」の回答品質が大きく上がります。つまり、SBOMは入口、VEXは説明の型 です。

30 / 60 / 90日で立ち上げる現実解

最初の30日

• トップ3製品に絞ってSBOMを作る
• Excelで最低限の項目をそろえる
• 更新担当者を決める

次の60日

• 脆弱性情報との突合運用を始める
• 影響あり / なし / 要確認の3段階で判断する
• OEM照会を想定した説明文の型を作る

90日まで

• SPDX または CycloneDX への移行方針を決める
• 提出版と社内版の粒度差を整理する
• VEX的な説明ルールを整える

この順番なら、最初から完璧を目指さずに、現場で使える運用へ進めやすくなります。

よくある失敗

SBOM運用が止まる典型パターン

1. 作ること自体が目的になる：提出できたことで満足し、脆弱性対応に使われない。
2. 製品版数と部品版数が分かれていない：CVEが出ても、どの製品まで影響するか追えない。
3. 更新責任者が決まっていない：最初の1回だけで終わる。
4. 機密の扱いが曖昧：社内で「出してよい範囲」が決まらず、毎回止まる。
5. VEXやOEM回答とつながっていない：一覧表はあるが、説明責任を果たせない。

SBOMの失敗は、フォーマットの選択よりも、運用設計の不足 で起きることがほとんどです。

---

FAQ：自動車サプライヤーのSBOMでよくある質問

まとめ

SBOMは、フォーマットを選ぶことが目的ではありません。

本質は、自社製品に何が入っているかを把握し、脆弱性が出たときに素早く影響確認できる状態を作ることです。SPDXかCycloneDXか、Excelから始めるか、どこまで開示するか。これらはすべて大事ですが、最終的に問われるのは1つです。

そのSBOMが、OEM照会・監査・脆弱性対応で本当に使われるか。

その問いに答えられるなら、そのSBOMは生きています。答えられないなら、どれだけ立派な形式でも、まだ実務資産にはなっていません。自動車サプライヤーにとってのSBOMは、提出物ではなく、説明責任を回すための基盤です。