SBOM更新・版管理ルール設計（テンプレ）｜3つの用途パターンで迷わない

結論：版管理は「製品版数 × SBOMスナップショット」で固定する

SBOM運用が回る最小原則はこれです。

製品版数 (Product Version)
出荷/提出の単位。SBOMの大元となるバージョン。
SBOMスナップショット (SBOM Snapshot)
その製品版数に対応する“確定版”。社内正本。
提出版 (Delivery SBOM)
開示範囲を絞った提出用の出力（正本から必要な部分だけ抽出したもの）。

【テンプレ】SBOM更新・版管理ルール（社内ルール雛形）

使い方： 以下を社内Wiki/手順書に貼り、【】だけ埋めてください。
※最初は“厳密”より“継続”優先でOKです。

0. 文書情報

文書名：SBOM更新・版管理ルール適用開始日：【YYYY-MM-DD】／版数：【v1.0】

1. 対象範囲

対象製品：【製品群/プロジェクト名】対象データ：SBOM（社内正本）／提出版SBOM（必要時）

2. 役割（最小3役）

SBOMオーナー（責任者）：【部署/氏名】更新担当（実務）：【部署/氏名】承認者（監査用）：【役職/氏名】 ※兼務可。ただし「承認」は別に置く。

3. 版番号のルール（これだけ固定）

製品版数：例）v【2.3.1】（既存の製品版数ルールに従う） SBOMスナップショットID：例）SBOM-【製品名】-【製品版数】-【YYYYMMDD】提出版ID：例）DELIVERY-SBOM-【顧客名】-【製品版数】-【YYYYMMDD】

4. 更新トリガー（更新の“きっかけ”を固定）

T1：製品リリース（版数が変わる） → 必ずSBOMスナップショット作成 T2：OSS/部品の更新（依存が変わる） → 影響する製品版数に紐づけて更新 T3：CVE照会/監査（期限あり） → まず“対象版数の確定”を優先し、必要に応じて備考・証跡を追記 T4：供給元からSBOM更新通知 → 正本へ反映、差分を記録

5. 証跡（監査で効く最低限）

保管場所：【共有フォルダ/チケットURL】必須：・依頼原本（照会/監査/通知）・対象製品版数の確定メモ・参照したSBOMスナップショットID ・提出履歴（いつ、何を、どこへ）

3種用途パターン（どれを採用するかだけ決めればOK）

自社の状況に合わせて、以下のA・B・Cのいずれかを選択して運用に落とし込んでください。

パターンA：提出中心（年数回・要求時に出す）

正本： 社内に保持（スナップショットは製品版数ごと）
提出： 必要時に 提出版 を生成（開示範囲を固定）
向く組織： まず監査・提出をクリアしたい

パターンB：CVE突合運用中心（週次/日次で回す）

正本： 更新頻度を上げる（トリガーT2/T4を重視）
備考： 到達性/無効化など“影響なし根拠”を残す
向く組織： 照会が多く、トリアージ負荷が高い

パターンC：顧客別派生（同一製品の派生が多い）

正本： ベースSBOM + 差分（Variant） で管理
提出： 顧客/派生ごとに提出版を切る
向く組織： カスタムや顧客別仕様が多い

よくあるNG（ここだけ避ける）

“最新版SBOM”が1つしかなく、どの製品版数のSBOMか分からない
正本と提出版が混ざり、監査で矛盾する
更新トリガーが無く、更新が止まる
証跡が残らず、「影響なし」の根拠が言えない

SBOM整備・運用範囲をどこから始めるか整理したい方はご相談ください。

【無料】オンライン相談を予約する

FAQ：SBOM版管理ルールについて

Q1. SBOMはどの頻度で更新すべきですか？

まずは「製品リリース時（製品版数が変わる時）」にスナップショット作成が最小です。照会が多い場合は、部品更新や供給元通知（T2/T4）も更新トリガーに入れると安定します。

Q2. SBOMの版番号は、製品版数と同じにしていいですか？

おすすめは製品版数は製品版数、SBOMはスナップショットIDを別で持つことです。監査・照会で「どの版のSBOMか」が明確になります。

Q3. 正本（社内版）と提出版は分けるべきですか？

多くのケースで分けた方が安全です。正本は運用のため、提出版は開示範囲を固定して“矛盾しない提出物”に寄せます。

Q4. 顧客別仕様がある場合、SBOMはどう管理しますか？

「ベースSBOM＋差分（Variant）」が現実的です。顧客/派生ごとに“どの差分が入ったか”を追える形にします。

SBOM更新・版管理ルール設計
（3種用途パターン）