実務テンプレ

組込み・車載ソフトのSBOM作成で起きるポイント10選
(差し戻し防止チェックリスト)

組込み・車載ソフトのSBOMは、一般ITよりも「差し戻し」が起きやすいです。

理由は単純で、製品の版数(派生モデル/構成違い)が多いことと、ベンダー提供バイナリ・独自改変・ビルド条件などが複雑に絡み、SBOMが“現物”とズレやすいからです。

このページでは、OEM照会・監査でよく刺さる「SBOMあるある」を 10項目のチェックリスト にしました。提出前・照会回答前の最終確認に使ってください。

まずはテンプレを先に入手(列を固定しないと必ず崩れます)

SBOM品質の差は、ツールより 「列が固定されているか」 で決まります。
最初にテンプレ(社内の正本)を作って、表記ゆれ・入力漏れを潰すのが先です。

チェックリスト:SBOM作成で起きるポイント10選(原因と直し方)

Excelで回す場合は、あらかじめチェック欄つきのテンプレに寄せておくと修正が早いです。

1) 対象スコープ(製品名×製品版数×派生)が曖昧

なぜNG? 「どの版のSBOM?」で照会が止まるため。
直し方 製品名・製品版数・派生条件(顧客向け/機能ON/OFF)を1行で固定して明記する。

2) 直接依存だけで、間接依存(transitive)が抜ける

なぜNG? CVE突合で、裏側で使われている脆弱なライブラリの“見逃し”が出るため。
直し方 主要OSSはパッケージマネージャやSCAツールで依存ツリーまで拾う(拾えない場合は“対象外の理由/限界”を備考に残す)。

3) ベンダー提供バイナリ(SDK/ドライバ)を「自社製」扱いにしている

なぜNG? インシデント時に問い合わせ先が不明になり、対策責任が宙に浮くため。
直し方 供給元(ベンダー名/型番/版数)を別列で明示し、ブラックボックスであることを明確にする。

4) フォーク/バックポートがあるのに、上流版数だけで記載

なぜNG? 「上流は脆弱だが当社は独自に対策済み」であることを証明できず、OEMから差し戻し(パッチ適用要求)を受けるため。
直し方 独自パッチの有無・根拠(チケットID等)を備考に残し、必要なら識別子(コミットハッシュ等)を併記する。

5) コンポーネント名の表記ゆれ(OpenSSL/openssl等)

なぜNG? 機械的な突合で同一コンポーネントが別物扱いになり、検知漏れや二重管理が起きるため。
直し方 PURLやCPE等の標準フォーマットか、社内の正規名辞書(表記ルール)を決め、登録時に必ず寄せる。

6) ビルド条件(機能ON/OFF)でSBOMが版数と一致していない

なぜNG? 製品版数と“実際に入っているもの”が一致せず、監査で再現できなくなるため。
直し方 「このSBOMが対応する構成条件」を1行で残す(例:Bluetoothモジュール=OFF 版 等)。

7) 版数が曖昧(latest/range/空欄)

なぜNG? CVEは特定バージョンにヒットするため、版数が曖昧だと影響有無の判断が不能になるため。
直し方 比較可能な識別子に統一する(OSS固定版数/商用リビジョン/自社ビルド番号等)。

8) 生成時点・更新日・更新者が分からない

なぜNG? “継続的に運用している”証拠にならず、監査で最新版管理の説明ができないため。
直し方 SBOMスナップショットID、更新日/更新者、参照した成果物(ソース/バイナリ等)をヘッダ等に残す。

9) 提出版と社内正本が混ざる(マスキングルールなし)

なぜNG? IP観点で情報を出しすぎる、あるいは逆に出さなすぎてOEM照会に答えられなくなるため。
直し方 「社内正本(フルデータ)」と「提出版(抜粋)」を分け、マスキングルールを固定する。

10) 提出前の“最低限の検証”をしていない

なぜNG? OEM指定フォーマットのエラーや必須列の不足で、一発で差し戻されるため。
直し方 提出先の必須列チェック+サンプル照会(直近のCVEを1件当てて対象を検索できるか)を事前に実施する。

最後に:差し戻しを減らす「最小3点」

チェックリストを回したら、提出・回答前にこの3点だけ再確認してください。これだけで致命的な事故は防げます。

  • 対象版数が言い切れる(暫定/確定も明記)
  • 根拠が残っている(SBOM行・構成表・チケットIDなど)
  • いつ時点のSBOMか説明できる(更新日/スナップショット)

FAQ:車載ソフトのSBOM作成について

Q1. 組込み・車載ソフトのSBOMで差し戻しが多いのはなぜ?

派生構成が多く、ベンダー提供バイナリや独自改変が混ざり、「現物とSBOMのズレ」 が起きやすいからです。まず対象版数と構成条件を固定すると事故が減ります。

Q2. ExcelでSBOMを作っても大丈夫ですか?

MVP段階は問題ありません。重要なのは形式より、列の固定・表記ゆれ防止・更新運用です。まずはテンプレに寄せて運用を回してください。

Q3. フォーク/バックポートがある場合、どう書けばいい?

上流版数の表記だけで断定せず、独自パッチの有無と根拠(チケットID等)を残してください。「上流は脆弱だが当社は対策済み」を説明できる形にするのがポイントです。

Q4. 提出版はどこまで出せばいいですか?

目的(照会回答/契約/監査)で変わります。社内正本と混ぜず、抜粋区分とマスキングルールを決めて再現可能にしておくのが安全です。

SBOMの作成と提出、AIで効率化しませんか?

SBOMの整備方針やOEM提出範囲でつまずいている方は、無料のオンライン相談をご利用ください。

Auto PSIRT Cloudなら、既存のExcel部品表をアップロードするだけで、表記ゆれの吸収から脆弱性チェック、OEM指定フォーマットへの自動出力までを一気通貫でサポートします。