SBOM導入ロードマップ
（30日・60日・90日プラン）
SBOMは「作ること」が目的ではありません。
CISAはSBOMをソフトウェアの“ingredients list（成分表）”と位置づけ、ソフトウェア構成を把握し、脆弱性やリスク判断へつなぐ基盤だと説明しています。NTIAもSBOMを、ソフトウェアを構成する各部品とサプライチェーン関係を記録する formal record と整理しています。
つまりSBOM導入は、単なる一覧表作成ではなく、「構成把握・提出・脆弱性対応を回すための運用設計」です。
SBOM導入で失敗しやすいのは、最初から全部をやろうとすることです。
NTIAの minimum elements は、SBOMに必要な要素を「データ項目」「automation support」「practices and processes」の3領域で整理しています。さらに CISA の 2025 draft minimum elements は、SBOM は単なる構造化データではなく、頻度、アクセス、契約や運用ルールまで含めて扱うべきだとしています。
だからこそ、導入は一気通貫ではなく、段階を切って進める方が現実的です。
先に結論：30日・60日・90日で分ける
兼務体制で無理なく進めるなら、SBOM導入は次の3段階のタイムラインで十分です。
最初の30日
対象製品と正本項目を決める
次の60日
更新ルール・提出導線・運用台帳を整える
90日まで
脆弱性管理や自動生成と結びつける
この順番にすると、「表は作ったが運用できない」「自動化ツールは入れたが正本が無い」といった失敗を避けやすくなります。これは、NTIA が示した “データ → 自動化 → 運用” の流れとも整合的です。
Day 1–30：まずは“正本”を作る
最初の30日でやることは、高価なツールの選定ではなく 正本の設計（データの型決め） です。
最小で決めるべきものは次の4つです。
1 対象製品を絞る
最初から全製品を対象にしないことが重要です。OEM照会が多い製品、更新頻度が高い製品、外部接点（通信機能など）が多い製品から始めると運用しやすくなります。
2 正本項目を固定する
最低限、「製品名」「製品版数」「コンポーネント名」「コンポーネント版数」「種別（OSS/商用/自社）」「搭載箇所」「更新日/更新者」があれば始められます。NTIA minimum elements でも、部品を識別し、供給関係や基本属性を記録できることが出発点になっています。
3 正本の置き場を1つに決める
最初は Excel やスプレッドシート等の共有台帳で十分です。大事なのは、「どれが正本か分かること」です。複数人が別ファイルを持ち始めると、導入初期から運用が崩れます。
4 版数の切り方を決める
「製品の版数」と「内部コンポーネントの版数」を分けて持つことが重要です。CVE照会でOEMから一番聞かれるのは、結局「どの製品版まで影響するか」だからです。
- 対象製品一覧
- 正本項目の定義
- Excel/スプレッドシートの正本
- 版数ルール
Day 31–60：提出と更新の運用を作る
次の30日でやることは、更新と提出のルール化 です。
CISAの 2025 draft minimum elements でも、SBOMは machine-processable（機械処理可能）であるだけでなく、frequency（更新頻度）や access（アクセス権）、提供条件を明示的に扱うべきとされています。
1 更新トリガーを決める
最低限、次の3つを更新トリガーにします。
①製品リリース ②修正/パッチ適用 ③部品変更（OSS/商用/自社）
2 提出版と社内版を分ける
この段階で、機密を含む「社内正本」とOEM/顧客に出す「提出版」を分けます。最初は「何を出す/出さない」のマスキング基準を簡単に決めるだけで十分です。
3 提出履歴を残す
提出先、提出日、対象版数、提出版ID を記録します。後で監査や照会があった際に「どの版を出したか」を説明できるようにしておくことが重要です。
4 案件台帳へつなぐ
SBOMは単独では価値が出ません。OEM照会や監査案件の「脆弱性管理台帳」と結びつけ、対象版数と判断根拠（証跡）として連携させます。
- 更新ルール
- 提出版/社内版の切り分け基準
- 提出履歴の管理表
- 案件台帳との紐付けルール
Day 61–90：脆弱性管理と自動化へつなぐ
最後の30日で、SBOMを「使う状態」にします。
CISA と国際共同の “Shared Vision of SBOM” は、SBOMは単に採用するだけでなく、セキュリティワークフロー（脆弱性対応プロセス）へ統合することが重要だとしています。
1 脆弱性突合の入口を決める
NVD、JVN、ベンダからのセキュリティ通知など、何を見て自社のSBOMと突合するかを決めます。全部を見る必要はなく、最初は主要な情報ソースに絞れば十分です。
2 生成を半自動化する
CISA 2025 draft は、広く使われている machine-processable formats として SPDX と CycloneDX を挙げています。いきなり完璧に自動化する必要はありませんが、ビルド環境やパッケージマネージャの依存情報から取れる部分は自動生成へ寄せると、更新負荷が一気に下がります。
3 週次/月次レビューへ組み込む
生成・更新されたSBOMを、定期的な脆弱性レビュー会議や案件台帳と結びつけます。ここまで来ると、SBOMは単なる“提出物”ではなく、自社を守るための生きた 運用データ になります。
- 脆弱性突合の運用ルール
- SPDX/CycloneDX など機械処理可能な出力の試行
- 月次レビューへの組み込み
- 主要製品群の継続更新体制
比較表：30日・60日・90日の違い
各フェーズの目的と成果物を整理すると以下のようになります。
| 期間 | 主目的 | 主な作業 | 成果物 |
|---|---|---|---|
| 30日 | 正本作成 | 対象製品決定、項目固定、版数ルール | 正本台帳（Excel等） |
| 60日 | 運用設計 | 更新ルール、提出版分離、履歴管理 | 提出運用一式 |
| 90日 | 活用開始 | 脆弱性突合、半自動化、レビュー会議接続 | 運用サイクル |
自社に最適なペースで、SBOM整備と提出運用をどこから始めるか整理したい方はご相談ください。
【無料】オンライン相談を予約するよくある失敗（プロジェクトが頓挫するパターン）
-
1. 最初から全社展開しようとする
対象が広すぎると、各部門の調整だけで時間が過ぎ、運用開始前にプロジェクトが止まります。 -
2. 生成だけして終わる
ツールの導入でSBOMファイルができても、それが案件台帳やOEMへの提出運用につながらなければ、ビジネス上の価値が出ません。 -
3. 提出版と正本を混ぜる
マスキングした提出用ファイルを正本として更新してしまうと、後からどれが社内の正式な最新版か分からなくなります。 -
4. 90日目に初めて脆弱性運用へつなぐ
最初から“使う先（トリアージ等）”を見据えて項目を設計しないと、せっかく作ったSBOMが棚に置かれたまま使われなくなります。
FAQ：SBOM導入の進め方
完成させるのはSBOMそのものではなく「正本の型（ルール）」です。対象製品、製品版数、コンポーネント版数の管理ルールと、正本の置き場が決まれば最初のステップとしては十分です。
必須ではありません。CISA 2025 draft は SPDX と CycloneDX を広く使われる machine-processable formats としていますが、まずはExcel等で「自社の製品に何が入っているか」の正本運用を固めてからツール生成へ移行しても遅くありません。
多くの中小サプライヤーでは、90日で目指すべきは「完全自動化」ではなく「半自動 ＋ 運用（脆弱性管理）への接続」です。そこまで行けば、実務上の負担軽減と監査への対応力としてかなり前進したと言えます。
SBOMを「運用データ」に変える仕組みを見てみませんか？
Excelで作ったSBOMや、ツールで生成したCycloneDX/SPDXデータをシステムに取り込み、日々発表される脆弱性情報と自動で突合。Auto PSIRT Cloud を使った、SBOM管理から脆弱性の影響判定（トリアージ）までのスムーズな流れをデモでご案内します。