SBOM の継続的管理・生成 AI を活用した初期アセスメント

SBOM の継続的管理・生成 AI を活用した初期アセスメント【前編: OWASP Dependency-Track による SBOM の継続的管理】

Posted by Junpei Ito 2026/03/13

本記事は前編・後編のシリーズ記事「SBOM の継続的管理・生成 AI を活用した初期アセスメント」の前編記事です。

前編: OWASP Dependency-Track による SBOM の継続的管理 後編: 生成 AI による脆弱性の初期アセスメント

脆弱性対応を効率化するうえで、多くの組織が直面するこの課題に対し、私たちは「SBOM の継続的管理」と「生成 AI による初期アセスメント」を組み合わせたワークフローを構築した。本記事はそのうちの 前編 となる。 前編では、SBOM を最新状態に保ち続けるために、OWASP Dependency-Track を使って「検知」「管理」「通知」を自動化する仕組みを紹介する。 後編では、検知された脆弱性に対してどのように“効率的に初期判断を行うか”を AI 活用の観点から説明する。

概要

SBOM（Software Bill of Materials）は、ソフトウェアに含まれるコンポーネント（名称・バージョン・依存関係・ライセンス等）の一覧であり、セキュリティ対策や法的リスク対策の基盤となる。SBOM は一度作って終わりではなく、運用フェーズで継続的に更新・監視することが重要である。

一般的に、脆弱性が検出された際に開発者が行う手続きは、次の二つに大別される。

  1. 各脆弱性についての対応方針の判断
    （例：即時修正／次回アップデートで修正／影響なしとして対応見送り など）
  2. 修正が必要なものの実装・試験とリリース反映

今回の取り組みでは、このうち 1. の「対応方針の判断」に着目した。
Dependency-Track による継続監視で脆弱性の「検出」までは自動化されるが、「どう対応すべきか判断する」工程は依然として開発者の負担が大きい。

そこで、生成AIを活用した「CVE 要約 → コード文脈の初期アセスメント → 人の最終判断」という流れを構築し、対応判断に必要な材料を短時間で得られる仕組みを整備した。

具体的には、以下を実施した。

  • SBOM の作成：Trivy によりアプリ／コンテナ／OS などレイヤ別に SBOM を生成
  • SBOM の継続管理：OWASP Dependency-Trackで SBOM を管理し、新規・更新された CVE を自動照合
  • 生成AIによる要約：Dify＋OpenAI API により、CVE メタ情報を定型フォーマットで要約（概要／発生条件／推奨対応／パッチ状況）
  • コード文脈の初期アセスメント：VS Code＋Cline＋OpenAI API により、要約結果とリポジトリのコード文脈を突き合わせ、影響可能性を“仮判定”として提示
  • 責任分界：AI 出力はあくまで初期アセスメント（仮判定）までで、最終判断はセキュリティ担当者が実施

この仕組みにより、全パッケージの一律アップデートではなく、リスクベースの優先順位付けが可能になり、修正・試験の工数を大幅に削減しつつ高リスク領域へリソースを集中できる体制を構築した。

ワークフロー

上図は本取り組み全体のワークフローを示している。 前編となる本記事では、このワークフローの前半にあたる「OWASP Dependency-Track による SBOM の継続的管理」について紹介する。

SBOM とは

現在のソフトウェア開発において、OSS（オープンソースソフトウェア）の利用は一般化されている。
しかし、OSS の利活用に伴い、「自社のアプリケーションには、コンポーネントとしてどのようなソフトウェアが含まれるのか？」を認識することは困難となっている。

例えば、開発者が直接利用している上位コンポーネントについては認識されていても、その上位コンポーネントが内包する下位コンポーネントについては認識されにくい。
そのため、仮に下位コンポーネントで脆弱性が発覚した際に、それを検知できない、もしくは対応が遅れる場合が想定される。
例えば 2021 年 12 月に発覚した Log4j の脆弱性では、開発者が直接利用するコンポーネントの中に Log4j が見えない形で埋め込まれている場合が多かった。そのために、組織が「自らのソフトウェアの中に Log4j が組み込まれているか」を即座に判定することができず、被害が広まったという背景がある。

また、コンポーネントの認識の問題は、セキュリティ対策だけでなく、法的リスク対策の問題にも直結する。
OSS には、MIT、Apache-2.0、GPL 等、それぞれ異なるライセンスで提供されている。特に GPL（GNU General Public License）では、GPL が適用されたソフトウェアをコンポーネントとして利用していた場合でも GPL が適用され、ソースコードの開示が求められるという特徴がある。
そのため、意図せずコンポーネントに GPL のソフトウェアが含まれていた場合、ライセンス違反となる可能性が非常に高い。

このような問題に対応する上でとるべき対策の 1 つが「SBOM の作成・管理」である。
SBOM とは、ソフトウェアを構成するコンポーネントの名称やバージョン情報、依存関係、開発者情報などを含むソフトウェアの部品表である。
2021 年 5 月に、アメリカのバイデン大統領が署名した大統領令「Improving the Nation’s Cybersecurity」では、ソフトウェアの構成要素に関する詳細の開示手段として SBOM が言及されている。
現に、アメリカではソフトウェアを政府調達する場合、SBOM の提出を必須化する動きが取られており、日本国内でも、医療機器用ソフトウェアを中心に SBOM の活用が推奨されている。
その点で、SBOM は大いに注目を集める技術要素であると言える。

SBOM の作成

SBOM の作成には「Trivy」という OSS ツールを使用した。このツールは、コンテナイメージやソースコードなどを解析し、その構成要素を特定して SBOM を生成できる。
また、生成した情報をもとに既知の脆弱性データベースと照合し、脆弱性を検出することも可能である。

Trivy には、以下に挙げるような強みが存在する。

  • 完全に無料で使用可能
  • Java や Node.js、Python 等、現代のソフトウェア開発において用いられる多くの言語に対応している
  • yum 等のパッケージ管理ツールが持つパッケージ情報を用いることで、OS の SBOM 生成／脆弱性診断も

そこで、今回は Trivy を用いて SBOM を作成した。
Trivy を用いて SBOM を作成する上で重要な点が 2 つある。

１つは「システムが複数のレイヤを持つ場合の考え方」である。
例えば、オンプレのシステムの場合、OS 自体が SBOM として管理すべき対象に含まれる。
もしくは、一部の機能が Docker により構成される、というパターンも多い。
このような場合、レイヤ毎に SBOM を管理するのが効率的であると考える。レイヤ毎に SBOM を分割することには、以下のようなメリットが存在する。

  • OS・ソースコード・Docker イメージで担当チームが異なる場合に、責任の分離ができる
  • レイヤ毎の更新頻度が異なる場合でも、更新が入ったレイヤのみ SBOM を更新すればよい

もう１つが、SBOM の内容は開発・保守を通じて日々変化するものである。
例えば新しい機能を追加した際は、その機能を実現するために用いた OSS ライブラリが追加される場合がある。
もしくは、脆弱性を含むパッケージをバージョンアップする場合も考えられる。
そのため、SBOM は一度作って終わりではなく、日々更新していく必要がある。
継続的な管理を実現する方法としては CI/CD との連携が有力な策である。

OWASP Dependency-Track による継続的管理

SBOM 管理ツールの役割は、各種アプリケーション・バージョンで作成された SBOM を一元管理することにある。
SBOM 管理ツールを用いて SBOM を管理することには次のようなメリットが存在する。

  • 「どの時点で、どのバージョンの OSS を使っていたか」という証拠を分かりやすい形で保持できる。そのため、仮に取引先より SBOM の提出を要求された際に迅速に対応可能である。
  • SBOM に含まれるライセンス情報を自動抽出し、コンプライアンス上のリスクを迅速に検知できる。
  • 多くの SBOM 管理ツールは脆弱性データベースと照合する機能を持つ。そのため、ソフトウェアの OSS に脆弱性が含まれた場合にそれをアラート可能である。また、これを継続的にモニタリングすることも可能である。

今回は「OWASP Dependency-Track」という OSS の SBOM 管理ツールを使用した。
この管理ツールは完全無料でありながら「ライセンス情報抽出」「脆弱性データベースとの照合」「継続的モニタリング」といった、必要となる機能を十分に備えている。
加え、脆弱性検出の部分は Trivy のエンジンと連携させることもできる。これにより、より高精度の脆弱性検知を実現できる。

Dependency-Track の構築は、以下のように Docker Compose を用いて行った。環境に合わせてポート番号・URL を編集する必要はあるが、それを含めても非常に容易である。

  1. https://dependencytrack.org/ から Docker Compose ファイルをダウンロード
  2. ダウンロードした Docker Compose ファイルのポート番号・URL を環境に合わせて編集
  3. Docker Compose を実行

初回ログイン時はパスワードの変更が要求される。パスワードの変更後に再度ログインすると、以下のようなメインページが表示される。

メインページ

Dependency-Track で SBOM を管理するには、まず「プロジェクト」を作成する必要がある。1 つの「プロジェクト」には 1 つの SBOM が紐づく。
「プロジェクト」の作成には、画面左の「プロジェクト」メニューを選択し、「プロジェクトを作成」ボタンを押下する。

プロジェクトページ

プロジェクト作成画面は次のようになっている。
「プロジェクト名」と「分類器」の記載が必須である。

プロジェクト作成画面

プロジェクトを作成すると元の画面に戻るが、先ほど作成したプロジェクトが追加されているのが確認できる。それをクリックすると、次のような画面が表示される。

ページ画像

このページの「コンポーネント」タブを選択し、「BOM をアップロード」から SBOM をアップロードできる。
実際に SBOM をアップロードした結果の例が、以下の通りである。アプリケーションに含まれるコンポーネント・そのバージョン等の情報が一覧で表示される。

表示例

また「監査の脆弱性」タブから、アプリケーション内のコンポーネントに含まれる脆弱性の一覧を確認することができる。
脆弱性の重大度・脆弱性の説明等の情報も表示されるので、脆弱性対策の判断に役立てることが可能である。
なお、Dependency-Track が持つ脆弱性情報は日々更新される。そのため、新たに脆弱性が出た場合でも迅速な対応が可能である。

表示例

また、Dependency-Track では次のような機能も含まれている。これらを活用することで、脆弱性対策の迅速化・コンプライアンス向上につなげることが可能である。

  • Copyleft ライセンス検出の警告：SBOM を解析し、GPL などの Copyleft ライセンスを検出した場合に警告
  • 外部通知：Teams／メール等での通知

次の画像は、実際に脆弱性が新たに検出された際、それが Teams で通知されている様子である。

メッセージサンプル

本記事のまとめ

本記事では、OWASP Dependency-Track を中心とした SBOM の継続的管理について紹介した。 SBOM を「作る」だけでなく「最新の状態で管理し続ける」ことが、脆弱性対応やコンプライアンス維持の基盤になることを確認した。 しかし、実際の現場では、“脆弱性が検出されてから、どう対応方針を決めるか” の部分に多くの時間が費やされる。 本取り組みでは、この初期判断を効率化するために生成 AI を活用し、脆弱性の要約・影響可能性の仮判定を短時間で得る仕組みを構築した。 次回の後編では、 「生成 AI による脆弱性の初期アセスメント」 について詳しく解説する。

参考文献

Tags: