SBOM生成の自動化
（ビルド情報から作る段階導入）
SBOMを作り始めると、かなり早い段階で「これを毎回手で更新するのは無理だ」と気づきます。
一方で、最初から完璧な自動化を目指すと、今度は導入プロジェクトそのものが止まりがちです。
CISAはSBOMを、ソフトウェアを構成する部品の“ingredients list（成分表）”と位置づけており、ソフトウェアサプライチェーンの透明性と脆弱性管理の基盤だとしています。さらにCISAと各国パートナーの共同ガイダンスは、SBOMの生成・分析・共有をセキュリティ実務へ統合することを勧めています。
つまり、SBOMは「作って保存するファイル」ではなく、運用に組み込むべきデータです。
この前提で考えると、SBOM生成の自動化は「一気に完成させる」より、段階導入の方が現実的です。最初はExcelや簡易台帳で始め、次にビルド情報から取れるところだけ自動化し、最後にCI/CDへ組み込む。この順番にすると、兼務体制の現場でも破綻しにくくなります。
先に結論：段階導入は3ステップで考える
SBOM生成の自動化は、次の3段階のステップで考えると整理しやすいです。
Step 1 手作業の正本を持つ
最初はExcelやスプレッドシートで、製品名、製品版数、主要コンポーネント、版数を固定します。
この段階では完全自動を狙わず、「何を追うべきか」を社内で定義することが目的です。CISAはSBOMを使うにはデータだけでなく運用とプロセスが重要だとしており、2025年のSBOM minimum elements draft でも、SBOMは単なるデータではなく組織の実務やプロセスと一緒に扱うべきだとしています。
Step 2 ビルド情報から“取れるものだけ”自動化する
依存関係や生成物のメタデータなど、ビルド時に取得できる情報を使ってSBOMを半自動化します。ここでは「全部を自動で入れる」より、確実に取れるものを増やすのが目的です。
CycloneDX Tool Center には、.NET、Gradle、Maven、Go modules、npm、Python など多くのエコシステム向けに、Build / Post Build でSBOMを生成するツールが多数掲載されています。
Step 3 CI/CDや成果物生成に組み込む
最終的には、ビルドやリリースのたびにSBOMが自動生成され、成果物と一緒に残る状態を目指します。
たとえば SPDX Maven Plugin は Maven の POM に基づいて SPDX 文書を生成できますし、CISA が紹介する Syft はコンテナイメージやファイルシステムから SBOM を生成し、CycloneDX / SPDX の両方をサポートします。つまり、ビルド情報→SBOM→成果物保管 の流れを自動化できる手段は、すでにかなり揃っています。
まず理解：ビルド情報から“取れる項目”と“取れない項目”は違う
自動化でよく失敗するのは、「ツールを入れればビルド情報から全部の項目が取れる」と思ってしまうことです。
実際には、ビルド情報で取りやすいものと、そうでないものが明確に分かれます。
- OSSやパッケージの依存関係
- コンポーネント名
- コンポーネント版数
- ビルド成果物（バイナリ等）との紐付け
- 生成日時や実行環境の一部
※Maven / Gradle / npm / Python / Go などで公式・普及ツールが多数存在します。
- 製品版数との最終対応関係（どの車種向けか等）
- 顧客別派生や地域別差分
- 商用部品や手動管理の外部供給物の詳細
- “なぜ影響なしと言えるか” の文脈（VEX情報）
- 承認や提出履歴
※ここは結局、人手での補完や社内台帳との紐付けが必要です。
だから、SBOM自動化は ビルド情報だけで完結させるものではなく、ビルド情報を“正本台帳へ流し込む”設計 が必要になります。
CISAのSBOM guidance でも、SBOMはソフトウェアリスク管理のための運用に統合されるべきだとされており、単なる生成だけでは不十分です。
比較：どの段階まで自動化すべきか
| 段階 | 何をするか | 向いている状況 | 主なメリット | 主な注意点 |
|---|---|---|---|---|
| 1. 手作業中心 | Excel台帳を正本にする | 立ち上げ期、対象製品が少ない | すぐ始められる | 更新漏れが起きやすい |
| 2. 半自動 | ビルド情報を取り込み、台帳へ反映 | 依存関係が多い、件数が増え始めた | 手入力を減らせる | 製品版数との紐付けが必要 |
| 3. 自動 | CI/CDでSBOM生成、成果物と一緒に保存 | リリース運用が整っている | 再現性が高い | 社内ルールが未整備だと逆に混乱する |
この比較表から分かる通り、最初から段階3を目指すより、段階2までを早く安定させる方が現実的です。CISAの guidance でも、機械処理可能なフォーマットと自動化支援の重要性が強調される一方で、運用・プロセスが伴うことが前提になっています。
生成したSBOMを台帳に取り込み、脆弱性と突合する一連の流れを見てみませんか？
SBOM登録から突合までの流れをデモで確認する手順：兼務でも破綻しない導入ステップ
1まず“正本項目”を固定する
自動化より先に、何を正本として持つかを決めます。最低限、「製品名」「製品版数」「コンポーネント名」「コンポーネント版数」「種別（OSS/商用/自社）」「更新日/更新者」が必要です。
この時点ではExcelで十分です。まず必要なのは、ビルドで取れた情報を入れる箱 を作ることです。
2ビルドから取れる項目を1つずつ増やす
次に、利用中の言語やビルドツールごとに「自動生成できるか」を確認します。SPDX Tools や CycloneDX Tool Center は、エコシステムごとのツール群を一覧化しているので、どこから手を付けるかの確認に向いています。
3生成結果を成果物と紐付ける
SBOMをただ出力・別保存するだけでなく、どの製品版数・どのビルド成果物のSBOMか が追えるようにします。ここで版管理が弱いと、後で脆弱性の照会が来た時に検索できず意味を失います。
4商用部品や手入力項目を残す
自動化できる部分が増えても、人手で管理すべき項目（商用ライブラリなど）は残ります。社内正本に“自動項目”と“手動補完項目”の両方を入れる設計が安全です。
5提出版を別に切る
最終的にOEMへ出す時は、正本から「提出版」を切り出します（マスキングなど）。正本と提出版を分ける原則は、自動化の段階が進んでも変わりません。
よくあるNG例
-
NG1：ツールを入れたら自動化完了だと思う
SBOMが出力できても、それが製品版数に紐付き、提出運用につながらなければ実務上の意味がありません。 -
NG2：ビルド情報だけで完結させようとする
商用部品、派生構成、顧客別差分などはビルドツールから取れないことが多く、これを無理に自動化しようとすると破綻します。 -
NG3：正本を持たず、出力ファイルをそのまま提出する
提出先ごとの機密要求が違うため、社内正本と提出版を分けないと運用が崩れます。 -
NG4：いきなりCI/CDに入れる
最初の段階で管理項目や版管理のルールが決まっていないままCIに組み込むと、使えないSBOMが大量に自動生成され、混乱が増えます。
FAQ：SBOMの自動化
A. いいえ。まずは手作業の正本を作り、ビルド情報から取れる項目だけ半自動化し、最後にCI/CDへ入れるという「段階導入」の順番が最も現実的です。
A. 完成しません。依存関係やコンポーネントの版数は取りやすいですが、製品版数との紐付け、商用部品の追加、監査の証跡や提出のための運用プロセスは別途必要です。
A. 実務では SPDX と CycloneDX が広く使われています。CISA の 2025 draft minimum elements でも、広く使われている機械処理可能フォーマットとして両者が挙げられており、どちらを選んでも問題ありません。
自社のビルド環境に合わせたSBOM運用を相談しませんか？
手作業のExcel管理からどうやって半自動化へ移行するか。どのツールを使い、どうやって製品版数と紐付けるか。自社の開発環境に合わせた、無理のないSBOM整備と提出運用のスタート方法を整理したい方はご相談ください。