SBOMの更新頻度と版管理
（リリース/修正/部品変更で迷わない）
SBOMは「作ったら終わり」ではありません。
現場で本当に効いてくるのは、「いつ更新するか」と「どの版が最新版か」を説明できることです。
実際、OEM照会や監査で詰まりやすいのは次のような場面です。
- CVE照会が来たが、どの製品版のSBOMを見ればいいか分からない
- 提出したSBOMと社内で持っているSBOMが食い違っている
- 修正版を出したのに、SBOMの更新が追いついていない
- 部品変更はしたが、製品版数は変えておらず、どこに反映されたか説明できない
つまりSBOM運用の本質は、一覧表を作ること ではなく、変化を追い続けることです。
まず結論：更新トリガーは「3つ」に絞る
SBOM運用が止まる原因は、更新ルールを細かくしすぎることです。
最初は、次の3つだけを更新トリガーにすると回りやすくなります。
リリース
製品版数が変わる時。最も基本の更新タイミングです。
修正
バグ修正、セキュリティパッチ、設定変更、恒久対策の反映時。
部品変更
OSS/商用部品/自社モジュールの版数や供給元が変わる時。
この3つに反応できれば、最低限のSBOM運用は成立します。
リリース時に更新する理由
リリースは、SBOM更新の最も分かりやすい起点です。
理由は単純で、製品版数が変わる＝説明責任の単位が変わるからです。
たとえば OEM から
「v2.3.1 はこのCVEの影響を受けますか？」
と聞かれた時、必要なのは “v2.3.1 のSBOM” です。
最新版だけを上書き保存していると、過去版数の構成が追えず、毎回ゼロから調査することになります。
このため、リリース時は必ず
- 製品版数
- SBOMスナップショット
- 更新日
- 更新者
をセットで残すのが基本です。
修正時に更新する理由
修正は「製品版数が変わらないのに、SBOMが変わる」ことがあるため厄介です。
たとえば次のようなケースです。
- セキュリティパッチを当てた
- ライブラリだけ差し替えた
- 設定変更で機能を無効化した
- バックポートを入れた
この時、製品側の表向きの版数は変わっていなくても、実質的には構成が変わっている ことがあります。
ここをSBOMに残さないと、「うちのv2.3.1は対策済み」を説明できません。
実務では、製品版数を変えない場合でも
SBOMスナップショットID ／ 内部リビジョン ／ 修正チケットID
などで差分を追えるようにしておくと強いです。
部品変更時に更新する理由
部品変更は、意外と見落とされやすい更新トリガーです。しかも自社変更でなくても起きます。
- ベンダー提供ライブラリの更新
- BSP/SDK差し替え
- 商用ミドルウェアの版上げ
- OSS依存の更新
- 供給元変更
この場合、製品版数が変わっていなくても、脆弱性照会の前提が変わるため、SBOMの更新対象です。
特に供給元変更は、後から問い合わせ先や影響範囲の説明に効いてきます。
版管理は「3層」で持つと分かりやすい
SBOMの版管理が崩れる理由は、1つの番号に全部を押し込めようとすることです。
おすすめは、次の3層に分けるやり方です。
ユーザーやOEMに見せる製品の版数
例：v2.3.1
その製品版数に対応するSBOMの確定版（社内正本）
例：SBOM-ProductA-v2.3.1-20260929
提出先向けに抜粋・マスキングした提出物の識別子
例：DELIVERY-SBOM-OEMX-v2.3.1-20260929
こう分けておくと、「社内正本」「提出版」「過去版の履歴」が混ざらず、監査で説明しやすくなります。
兼務でも破綻しない運用手順（5ステップ）
正本を1つに決める
Excelでもよいので、「これが正本」という1ファイル/1台帳を決めます。複数人が別々に持つと、どれが正しいか分からなくなります。
更新トリガーを3つに固定する
リリース ／ 修正 ／ 部品変更
この3つ以外では原則更新しない、と決めるだけでも運用が軽くなります。
更新時に残す項目を固定する
最低限残すべき項目：対象製品 ／ 対象版数 ／ 変更理由（リリース/修正/部品変更）／ 更新日 ／ 更新者 ／ 証跡（チケット/承認/構成表など）
提出版は正本から切り出す
提出用に正本を書き換えないこと。社内正本から必要範囲を抜き出して提出版を作ると、矛盾が減ります。
月1回だけ棚卸しする
毎週の細かい見直しより、まずは月1回「更新漏れがないか」「提出版と正本がずれていないか」「古い版数が追えるか」を確認するだけで十分です。
そのまま使える：更新ログの最小テンプレ（TSV）
以下の列をSBOM管理の別シート（更新履歴タブなど）に1枚追加するだけでも、運用がかなり安定します。
下の枠内をコピーして、ExcelのA1セルに貼り付けてください。
このログがあると、「いつ変わったか」「なぜ変わったか」「どのSBOMを見ればいいか」がすぐ追えます。
SBOM整備・提出運用をどこから始めるか（更新体制やツール選定など）整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（更新運用が崩れるパターン）
- NG1：最新版だけ上書き保存
過去版数の説明ができず、照会時に毎回調査し直すことになります。 - NG2：製品版数は同じだから更新しない
修正や部品変更が反映されず、「対策済み」や「供給元変更」が説明できません。 - NG3：提出版を正本として扱う
マスキングや抜粋が混ざり、社内正本と提出版で矛盾が出ます。 - NG4：変更理由が残っていない
監査で「なぜこの版が変わったのか」が説明できません。
FAQ：SBOMの更新・版管理について
最低限、リリース・修正・部品変更 の3つです。これだけ固定すれば、最小の運用は回せます。
必要です。特にセキュリティパッチやライブラリ差し替えは、構成が変わるためSBOM更新対象です。内部リビジョンやスナップショットIDで差分を管理します。
はい。正本（社内版）と提出版を分けると、監査や照会で「どの版を誰に出したか」を説明しやすくなり、機密情報漏洩のリスクも減ります。
版管理と履歴追跡をシステムで自動化しませんか？
Auto PSIRT Cloudなら、製品バージョンとSBOMの紐づけがシステム上で管理され、過去のスナップショットや変更履歴も一元的に追跡できます。