SBOM PoCの始め方
概念図
この記事の位置づけ
この記事では、SBOM PoCを計画するときの考え方を整理します。
特定製品の構成や実行例は扱いません。Black DuckとSynopsys Detectを使う場合の具体的な構成メモは、Black Duck/Synopsys Detect PoCメモ に分けます。
SBOM PoCで確認すること
SBOM（Software Bill of Materials）は、ソフトウェアを構成するコンポーネント一覧です。脆弱性管理、ライセンス確認、インシデント時の影響調査に使われます。1
PoCで確認するのは、単にSBOMを生成できるかではありません。自社の開発、運用、監査の流れに接続できるかを見ます。
| 確認対象 | 見ること |
|---|---|
| 生成可否 | 対象リポジトリや成果物からSBOMを作れるか |
| 精度 | 直接依存、間接依存、private dependencyを拾えるか |
| 形式 | SPDX、CycloneDXなど必要な形式で出力できるか |
| 脆弱性運用 | CVE検知後に影響調査と是正へつながるか |
| ライセンス運用 | 法務や監査が確認できる粒度か |
| 開発影響 | CI/CD、ビルド時間、開発者作業へ与える影響 |
| 証跡 | 監査や説明に使える結果を保管できるか |
PoCの目的を先に決める
SBOM PoCは目的が曖昧だと、ツールの画面確認だけで終わります。最初に、どの運用課題を解きたいのかを決めます。
代表的な目的は次の通りです。
| 目的 | 確認すること |
|---|---|
| 脆弱性影響調査を早くする | 特定ライブラリを含むシステムを検索できるか |
| ライセンス確認を標準化する | ライセンス種別、義務、例外を確認できるか |
| 監査証跡を作る | いつ、どの成果物を、どの条件で確認したか残せるか |
| CI/CDへ組み込む | 開発者の負荷とビルド影響が許容範囲か |
| 取引先要求に備える | 提出形式、粒度、更新頻度に対応できるか |
対象選定
PoC対象は、小さすぎても大きすぎても評価しにくくなります。
| 対象 | 向くケース | 注意点 |
|---|---|---|
| 小規模リポジトリ | 接続性、基本操作、出力形式の確認 | 実運用の課題が出にくい |
| 標準的な業務アプリ | PoCの中心対象 | 依存関係、CI、責任者が確認しやすいものを選ぶ |
| 大規模・複雑なアプリ | 性能、精度、運用負荷の確認 | 初回PoCには重すぎる場合がある |
| コンテナイメージ | 成果物ベースの確認 | ソース解析との違いを明確にする |
| private dependencyあり | 社内依存の検出確認 | 認証設定や除外ルールが必要 |
最初は、標準的な業務アプリを1つ選び、次に言語や構成の異なる対象を追加する方が評価しやすいです。
フォーマット確認
SBOMの代表的なフォーマットにはSPDXとCycloneDXがあります。23
| フォーマット | 向く用途 |
|---|---|
| SPDX | ライセンス、著作権、法務・監査文脈 |
| CycloneDX | 脆弱性管理、依存関係、DevSecOps連携 |
PoC段階では、どちらか一方に固定する前に、連携先が受け入れる形式を確認します。社内標準を1つ決める場合でも、外部提出やツール更改に備えて変換可否を見ておくと移行しやすくなります。
実行サイクル
PoCは一度だけ実行して終わらせない方がよいです。
推奨は最低3サイクルです。
| 回 | 目的 |
|---|---|
| 1回目 | 接続性、生成可否、基本的な結果を確認する |
| 2回目 | 除外設定、認証設定、検知ルールを調整して再測定する |
| 3回目 | 別システムまたは別ブランチで再現性を確認する |
1回目の結果だけで判断すると、初期設定ミスや偶然の成功を見落とします。複数回の結果で、再現性、運用負荷、開発者影響を見ます。
評価観点
PoCでは、評価項目、目標値、結果、判定、次アクションを同じ表で管理します。
| 評価項目 | 目標例 | 見ること |
|---|---|---|
| SBOM生成成功率 | 95%以上 | 対象のうち何件で生成できたか |
| 依存関係検出精度 | 主要依存100% | 直接依存、間接依存、private dependency |
| 脆弱性検出の妥当性 | High以上の妥当率80%以上 | 誤検知、優先度、既知CVEの検出 |
| ライセンス確認 | 法務確認可能率90%以上 | ライセンス種別、例外、根拠 |
| スキャン時間 | CI許容範囲内 | 平均、最大、上振れ条件 |
| 開発者負荷 | 追加作業15分以内/週など | 手動作業、問い合わせ、設定変更 |
| 証跡性 | 監査説明可能 | 実行時刻、対象、結果、承認履歴 |
定量記録がないと、PoC後に導入可否を判断できません。
失敗しやすい点
| 失敗 | 起きる問題 |
|---|---|
| 評価目的が曖昧 | PoC後に導入判断できない |
| 対象が小さすぎる | 実運用の課題が見えない |
| 対象が大きすぎる | 初期設定で詰まり、評価前に疲弊する |
| private dependencyを見ない | 依存関係解析が不完全になる |
| CI統合を急ぐ | 開発者影響やビルド停止リスクが出る |
| 誤検知対応が未定義 | 検出結果が放置される |
| 責任分担が曖昧 | 誰が判断し、誰が修正するか決まらない |
| PoC撤収計画がない | 不要な権限、トークン、設定が残る |
運用接続
SBOMを作るだけでは、運用価値は出ません。PoCでは、次の接続先まで確認します。
| 接続先 | 確認すること |
|---|---|
| 脆弱性管理 | CVE通知後に対象システムを検索できるか |
| チケット管理 | 是正担当、期限、例外を管理できるか |
| CI/CD | いつ生成し、失敗時に止めるか通知に留めるか |
| 法務確認 | ライセンス例外や確認履歴を残せるか |
| 監査証跡 | 実行結果、承認、例外、再評価を説明できるか |
まとめ
SBOM PoCは、ツール評価だけでなく、開発プロセス、脆弱性管理、ライセンス確認、監査証跡へ接続できるかを確認する活動です。
最初に目的を決め、対象を絞り、複数サイクルで再現性と運用負荷を測る必要があります。1回の実行結果だけでは、初期設定の偶然や対象選定の偏りを切り分けにくいためです。