メインコンテンツまでスキップ

【メモ】SBOM PoCの始め方

はじめに​

ソフトウェアのライフサイクル長期化とOSS利用の一般化により、アプリケーション内部の構成部品を可視化する重要性が高まっています。

この課題に対応する仕組みが**SBOM（Software Bill of Materials）**です。SBOMはソフトウェアを構成するコンポーネント一覧であり、脆弱性管理やライセンス管理に活用されます。1

ただし、SBOM生成ツールは導入すれば即運用できるものではありません。実際には、PoC（試験導入）で自社環境に適合するかを検証することが重要です。

本記事では、SBOM PoCをどう計画・実施するかを整理します。具体例として、Black Duck（SCAツール）とSynopsys Detectを題材にします。

SBOMとは何か​

SBOMは、ソフトウェアに含まれるコンポーネント一覧です。

SCA（Software Composition Analysis）ツールは、次の対象を解析します。

  • ソースコード
  • バイナリ
  • コンテナイメージ

その結果として、次の情報を抽出します。

  • 利用OSS部品
  • バージョン
  • 脆弱性情報
  • ライセンス情報

SBOMの主な目的は次の3点です。

透明性の確保​

どのサードパーティコンポーネントが含まれるかを把握し、脆弱性発覚時に影響範囲を迅速に特定します。

脆弱性管理​

既知の脆弱性に該当するライブラリを検出し、更新・パッチ・代替ライブラリ選定などの判断に活用します。

ライセンスコンプライアンス​

GPLなどのライセンス条件順守を確認し、ライセンス違反リスクを低減します。

SBOMフォーマット​

SBOMには複数の標準フォーマットがあります。代表例は次の2つです。

フォーマット特徴
SPDXLinux Foundation主導。ライセンス情報の表現が厚く、法務・監査文脈で使われやすい。2
CycloneDXOWASP主導。脆弱性・依存関係・サービス情報など運用連携を意識した設計。3

複数フォーマットを扱えるメリット​

「最終的に組織で1つに統一する」方針でも、PoC段階で複数フォーマットを扱えるかを確認するメリットはあります。

  • 取引先や監査先の要求差（SPDX指定/CycloneDX指定）に対応できる
  • 利用ツール（脆弱性管理、GRC、資産管理）が受け入れる形式が異なる
  • 将来のツール更改時に移行コストを下げられる

組織でフォーマットを統一するなら​

運用の簡素化のため、社内標準を1つ決めるのは有効です。選定基準は次のとおりです。

基準SPDXが向くケースCycloneDXが向くケース
主目的ライセンス順守・監査報告脆弱性運用・DevSecOps連携
連携先法務/GRCツール中心SCA/CI/CD/SOAR連携中心
表現したい情報パッケージ著作権やライセンス関係の厳密性依存関係グラフ、運用メタデータの実装しやすさ

実務上は、社内標準を1つ（例: CycloneDX）に定め、外部提出時のみ変換して併用という設計が扱いやすいです。

SBOM PoC前に整理すべきこと​

PoCは単なるツール検証ではなく、何を評価するかを先に明確化する必要があります。

主な評価観点は次のとおりです。

SBOM生成の可否と精度​

  • SBOMを安定生成できるか
  • 依存関係の漏れがないか
  • 重複検出は適切か

脆弱性・ライセンス情報の有用性​

  • 実務で使える粒度か
  • 社内ポリシー判断に使えるか

スキャン時間と運用負荷​

  • スキャン時間は許容範囲か
  • 開発者が受け入れ可能な運用負荷か

導入の影響範囲​

  • CI/CD変更が必要か
  • リポジトリ設定変更が必要か

PoC段階では、環境変更を最小化することが重要です。

Black DuckとSynopsys Detectの前提理解​

Black DuckはOSSコンポーネント検出とリスク分析を行うSCA製品です。

その中核となるのがSynopsys Detectです。Detectは次を担います。

  • プロジェクトフォルダを解析
  • OSS依存関係を検出
  • 結果をBlack Duckサーバーへ送信
  • SBOM生成

DetectはJavaアプリケーションとして提供されます。4

Detect実行の前提条件​

Detect実行にはネットワーク前提の整理が必要です。

ここでいうDetectの実行場所は、Gitサーバー本体ではなく、対象リポジトリをチェックアウトした実行ホストです。

  • 例: 開発端末、検証用VM、CIランナー（Jenkins agent / GitHub Actions runner）
  • Detectはその実行ホスト上の「チェックアウト済みソースコードのルートディレクトリ」で起動
  • Detectの実行ファイル（detect.shやsynopsys-detect-*.jar）はGitへコミットしない（.gitignore対象として管理）

接続要件（最重要）​

最低限、次の通信経路が必要です。

接続元接続先用途
Detect実行ホストBlack Duckサーバー（HTTPS）スキャン結果アップロード、ポリシー評価
Detect実行ホストDetect配布元（初回取得時）detect.shまたはDetect Jarの入手

インターネット直接接続がない環境では、次の代替案を使います。

  • インターネット接続可能な踏み台でDetect実体を取得し、社内リポジトリへ配置
  • Detect実行ホストからは社内リポジトリ経由で取得
  • Black Duckサーバーへの経路はプロキシ経由または閉域接続で確保

「PoCに必要な線」を先に定義する​

PoC失敗の多くはツールではなく経路不足です。事前に次をチェックリスト化します。

  • DNS解決
  • HTTPS疎通
  • プロキシ要否
  • サーバー証明書の信頼設定
  • APIトークン払い出し手順

Detectの特徴​

Detectをどこに置いて、どこで実行するか​

Detectは「アプリに組み込むライブラリ」ではなく、スキャン時だけ使う外部実行ツールです。

  • 配置先: 対象コードを置いた作業ディレクトリ（例: repo-root/tools/detect/）または一時ディレクトリ
  • 実行位置: 通常はリポジトリルート（例: repo-root/）
  • Git管理: tools/detect/配下の実体ファイルや実行ログは原則コミットしない

言語やフレームワークが違っても考え方は共通です。

  • Java（Maven/Gradle）: repo-root/ で実行
  • Node.js: repo-root/（package.jsonがある階層）で実行
  • Python: repo-root/（requirements.txt / pyproject.tomlがある階層）で実行

重要なのは、Detect実行時に依存関係定義ファイルへ到達できるディレクトリから起動することです。

エージェント型ではない​

Detectは常駐エージェント不要で、必要時のみ実行する方式です。

スクリプト1本で実行可能​

Linux/Macでは次のように実行できます。

bash <(curl -s -L https://detect.blackduck.com/detect.sh)

WindowsではPowerShellスクリプトで実行できます。

Black Duckサーバー連携​

実行時には、最低限次を指定します。

  • --blackduck.url
  • --blackduck.api.token

解析対象​

Black Duckは次の対象を解析できます。

  • ソースコード
  • バイナリ
  • コンテナイメージ
  • ファームウェア

さらに、SPDXとCycloneDX形式のSBOMを生成できます。

リポジトリ構成とPoCへの影響​

SBOMスキャン自体はソース管理システムに依存しません。ただし運用方法はリポジトリ構造の影響を受けます。

Git​

特徴PoCの注意点
分散型VCSローカルクローンでスキャン可能
ブランチが軽量リポジトリ変更を最小化しやすい
CI連携が容易GitHub Actionsなどに接続しやすい

SVN​

特徴PoCの注意点
集中型リポジトリ中央サーバーが単一障害点になり得る
チェックアウト方式ワークスペースでスキャンする運用と相性が良い

TFVC​

特徴PoCの注意点
Microsoft系の集中型VCSエンタープライズ運用に多い
バイナリ管理を扱いやすいロック機構を考慮した運用設計が必要

いずれの場合も、チェックアウト済みフォルダをDetectでスキャンするだけでPoC実施は可能です。5

PoC対象システムの選定基準（モダン/レガシー混在向け）​

「何をPoC対象にするか」で結果の価値が大きく変わります。モダンとレガシーが混在する組織では、次の基準で2〜3システムを選ぶとバランスが良いです。

基準見るポイント目安
ビジネス重要度障害時の業務影響、顧客影響高1件は必ず含める
技術代表性言語、ビルド方式、配布形態モダン1件+レガシー1件
依存関係の複雑度依存数、private dependency有無中〜高を1件含める
運用実現性担当チーム協力、スキャン実行時間PoC期間内に3回以上検証可能

選定のNGパターン​

  • 小さすぎて実運用課題が出ない
  • 巨大すぎてPoC期間で検証が終わらない
  • 協力体制がなく、結果を改善に回せない

SBOM PoCの接続パターン​

PoCでは複数の実行パターンを試せます。

Detect実行ホストでの手動スキャン​

  • Detect実行ホストでDetect実行（対象リポジトリのルートディレクトリで実行）
  • SBOM生成
  • Black Duckへアップロード

PoC初期に最適な方式です。

CIジョブとして実行​

例: Jenkins、GitHub Actions。

ビルド後にDetect実行を組み込みます。ただしPoC初期は次の懸念があります。

  • CI時間増加
  • 開発者負荷増加

SCM連携​

Black Duck Connectorなどを用いてGitHubなどのSCMと連携する方式です。

ただし、PoC段階では過剰構成になりやすいため、本番導入時に検討するのが現実的です。

なぜPoC初期でCI/CD統合しないのか​

SBOMをCI/CDへ組み込むのは理想ですが、PoC初期は次の問題が起きやすくなります。

ビルド時間の増加​

スキャンには数分、規模によっては数十分かかる場合があります。

false positive対応の未整備​

PoC初期では誤検知率や対応方法が未確立で、運用判断が詰まりやすくなります。

開発者の抵抗​

CI変更はビルド停止や開発フロー変更につながり、現場の合意形成コストが高くなります。

手動スキャンPoCの進め方​

PoC初期は手動スキャンから始めるのが推奨です。

手順​

1. Black Duckサーバー準備​

  • オンプレミスまたはクラウド環境を準備
  • APIトークンを発行

2. スキャン対象コード準備​

Git/SVN/TFVCからチェックアウト済みコードを用意します。

3. Detect実行​

./detect.sh \
  --blackduck.url="https://your-blackduck-server" \
  --blackduck.api.token="YOUR_TOKEN" \
  --detect.project.name="my-app" \
  --detect.project.version.name="v1.0"

4. 結果確認​

Black Duckダッシュボードで次を確認します。

  • SBOM
  • 脆弱性
  • ライセンス

SBOMはCycloneDXとSPDX形式でエクスポート可能です。

5. 評価指標に基づく検証​

例:

  • 生成成功率
  • 検出精度
  • スキャン時間

6. PoC後の撤収​

  • 発行したPoC用APIトークンを無効化
  • PoC用プロジェクト/バージョンをBlack Duck側で削除
  • Detect実行ホスト上のDetect実行物とログを削除

Linux例:

rm -f ./detect.sh
rm -rf ./blackduck ./synopsys-detect* ~/.synopsys

PowerShell例:

Remove-Item .\detect.ps1 -Force -ErrorAction SilentlyContinue
Remove-Item .\blackduck -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:USERPROFILE\.synopsys" -Recurse -Force -ErrorAction SilentlyContinue

手動スキャンは一度きりでよいか​

結論として、一度きりでは不十分です。PoCでは最低3サイクルを推奨します。

  • 1回目: 初回実行で接続性と生成可否を確認
  • 2回目: 除外設定や検知ルール調整後に再測定
  • 3回目: 別システムまたは別ブランチで再現性確認

この3サイクルで、再現性と運用負荷を判断しやすくなります。

PoC評価観点​

PoCでは以下を定量評価します。

  • SBOM生成率
  • 依存関係検出精度
  • 脆弱性検出能力
  • ライセンス検出精度
  • スキャン性能
  • 誤検知率
  • 導入負担

定量記録がないと、PoC後に導入可否を判断できません。

PoC検証結果の報告例（サンプル）​

実際の報告では「評価項目」「結果」「判定」「次アクション」を同時に示すと、意思決定が速くなります。

評価項目目標値結果（例）判定次アクション（例）
SBOM生成成功率95%以上97%（29/30）○失敗1件のビルド条件を標準化
スキャン時間10分以内平均8分40秒○対象拡大時の上振れを追加測定
依存関係検出精度主要依存100%直接依存100%、間接依存92%△private registry認証設定を改善
脆弱性有効性Critical/Highの妥当率80%以上85%○誤検知の除外ルールを文書化
ライセンス検出精度法務判定可能率90%以上88%△SPDX出力を追加し法務レビュー再実施
運用負荷開発者追加作業15分以内/週約25分/週×CI統合前に自動化スクリプトを作成

まとめコメントの例​

  • 導入可否: 条件付きで導入可能
  • 条件: private dependency対応、除外ルール整備、運用手順書の完成
  • 次フェーズ: 1チーム限定でCIジョブに組み込み、4週間で再評価

SBOM PoCで失敗しやすいポイント​

評価目的が曖昧​

評価軸がないと、PoC終了後に意思決定できません。

対象システムの選定ミス​

小さすぎる対象では実運用の課題が見えず、大きすぎる対象ではPoCが過負荷になります。

ネットワーク前提の未整理​

Detect取得経路やBlack Duck接続経路が未整理だと、技術評価以前で停止します。

CI統合を急ぐ​

開発者の反発やビルド停止リスクにつながります。

private dependencyの見落とし​

社内パッケージやprivate registryを考慮しないと、依存関係解析が不完全になります。

false positive対応未定義​

誤検知をどう扱うかを事前定義しないと、運用が停滞します。

SBOM用途が未定義​

SBOMを脆弱性管理とライセンス管理のどのプロセスで使うかを明確化する必要があります。

責任分担が不明確​

脆弱性への対応で、誰が判断し誰が修正するかを定義する必要があります。

PoC撤収計画なし​

PoC設定が残ると、本番境界やセキュリティ責任が曖昧になります。

まとめ​

SBOM PoCは、

ツール評価に加えて、開発プロセスとの適合性を確認する活動

です。

Black Duck+Synopsys Detectでは、CLI実行を中心に次を検証できます。

  • SBOM生成
  • OSS依存関係分析
  • 脆弱性検出

また、Git/SVN/TFVCなどリポジトリ種別に依存せず、チェックアウト済みコードをスキャンできます。

導入は次の段階的アプローチが有効です。

  1. 手動スキャン（3サイクル以上）
  2. CI/CD統合

ソフトウェアサプライチェーン透明性は必須要件です。PoC知見をもとに運用体制とセキュリティポリシーを整備し、SBOMを継続的な管理プロセスへ組み込むことが重要です。

参考資料（出典）​

Footnotes​

  1. SBOM PoC資料, SBOM PoCはどう始めるべきか — Black Duckを題材にした計画整理（PDF）。SBOMの概念、PoCの進め方、Black Duckを用いた検証手順を整理。 ↩

  2. SPDX, SPDX Specification。SPDXの公式仕様。https://spdx.github.io/spdx-spec/ ↩

  3. CycloneDX, CycloneDX Specification。CycloneDXの公式仕様。https://cyclonedx.org/specification/ ↩

  4. GitHub, blackducksoftware/detect。Synopsys Detect CLIの公式リポジトリ。https://github.com/blackducksoftware/detect ↩

  5. Nulab, Git vs. SVN: Which version control system is right for you?。GitとSVNの構造比較。https://nulab.com/learn/software-development/git-vs-svn-version-control-system/ ↩

に最終更新