SBOM更新・版管理ルール設計
（3種用途パターン）
SBOMが形骸化する最大原因は、作り方ではなく 「更新」と「版管理」のルールが無いことです。
「いつ更新する？」「どれが最新版？」「提出版はどれ？」が曖昧だと、CVE照会やOEM監査のたびに“その場しのぎ”になります。
このページでは、そのまま使える「SBOM更新・版管理ルール設計テンプレ」を、用途別に3パターンで提示します。
結論：版管理は「製品版数 × SBOMスナップショット」で固定する
SBOM運用が回る最小原則はこれです。
-
製品版数 (Product Version)
出荷/提出の単位。SBOMの大元となるバージョン。 -
SBOMスナップショット (SBOM Snapshot)
その製品版数に対応する“確定版”。社内正本。 -
提出版 (Delivery SBOM)
開示範囲を絞った提出用の出力（正本から必要な部分だけ抽出したもの）。
【テンプレ】SBOM更新・版管理ルール（社内ルール雛形）
使い方： 以下を社内Wiki/手順書に貼り、【 】だけ埋めてください。
※最初は“厳密”より“継続”優先でOKです。
3種用途パターン（どれを採用するかだけ決めればOK）
自社の状況に合わせて、以下のA・B・Cのいずれかを選択して運用に落とし込んでください。
パターンA：提出中心（年数回・要求時に出す）
- 正本： 社内に保持（スナップショットは製品版数ごと）
- 提出： 必要時に 提出版 を生成（開示範囲を固定）
- 向く組織： まず監査・提出をクリアしたい
パターンB：CVE突合運用中心（週次/日次で回す）
- 正本： 更新頻度を上げる（トリガーT2/T4を重視）
- 備考： 到達性/無効化など“影響なし根拠”を残す
- 向く組織： 照会が多く、トリアージ負荷が高い
パターンC：顧客別派生（同一製品の派生が多い）
- 正本： ベースSBOM + 差分（Variant） で管理
- 提出： 顧客/派生ごとに提出版を切る
- 向く組織： カスタムや顧客別仕様が多い
よくあるNG（ここだけ避ける）
- “最新版SBOM”が1つしかなく、どの製品版数のSBOMか分からない
- 正本と提出版が混ざり、監査で矛盾する
- 更新トリガーが無く、更新が止まる
- 証跡が残らず、「影響なし」の根拠が言えない
SBOM整備・運用範囲をどこから始めるか整理したい方はご相談ください。
設計パートナー向け説明を申し込むFAQ：SBOM版管理ルールについて
まずは「製品リリース時（製品版数が変わる時）」にスナップショット作成が最小です。照会が多い場合は、部品更新や供給元通知（T2/T4）も更新トリガーに入れると安定します。
おすすめは 製品版数は製品版数、SBOMはスナップショットIDを別で持つことです。監査・照会で「どの版のSBOMか」が明確になります。
多くのケースで分けた方が安全です。正本は運用のため、提出版は開示範囲を固定して“矛盾しない提出物”に寄せます。
「ベースSBOM＋差分（Variant）」が現実的です。顧客/派生ごとに“どの差分が入ったか”を追える形にします。
デモ版で、自社の実務との適合性を確認しませんか？
Auto PSIRT Cloudは現在デモ版です。既存Excel/SBOMから候補抽出、期限・根拠・承認、OEM回答ドラフトまでの流れを確認できます。製品への影響判断と最終承認は人が行います。初期設計パートナーとして、合う点・足りない点を一緒に検証します。