本記事は前編・後編のシリーズ記事「SBOM の継続的管理・生成 AI を活用した初期アセスメント」の後編記事です。
前編: OWASP Dependency-Track による SBOM の継続的管理 後編: 生成 AI による脆弱性の初期アセスメント
前編の振り返りと、後編で扱う内容
現代のソフトウェアは多くの OSS コンポーネントを組み合わせて構築されており、 「自社アプリケーションがどのソフトウェアに依存しているのか？」を正確に把握することは容易ではない。 そのため、SBOM（Software Bill of Materials）を生成・更新し続ける運用の重要性が高まっている。 前編では、弊社にて構築した SBOM 管理フローとして以下のポイントを紹介した。
- SBOM の作成：Trivy によるアプリ・コンテナ・OS などレイヤ別の SBOM 生成
- SBOM の継続管理：OWASP Dependency-Track による一元管理と自動モニタリング
特に Dependency-Track を活用することで、脆弱性やライセンスリスクの検知を自動化でき、 「SBOM を最新状態で維持し続ける」ための基盤が整うことを確認した。 本後編では、その次のフェーズとなる“検出された脆弱性をどのように初期判断するか”に焦点を当て、生成 AI を用いた初期アセスメント手法を紹介する。
生成AI による脆弱性の初期アセスメント（スクリーニング）
Dependency-Track を含む多くの脆弱性管理ツールは、「脆弱性の検出・報告」までを主眼に置いている。
しかし実務では、その先に「報告された脆弱性に対し、どの程度緊急か／どの対応をいつ行うかを判断する」タスクが残される。
本セクションでは、Dependency-Track で検出された脆弱性（CVE）に対し、生成AI（OpenAI API）を用いて CVE 情報の要約と影響の初期アセスメント（スクリーニング）を行い、担当者の判断を支援するワークフローを紹介する。
出力は 定型フォーマット（概要／発生条件／推奨対応／パッチ状況＋該当コードの根拠）で提示し、初期トリアージの材料として活用する。
使ったツールと役割の明確化
- OpenAI API（生成AI本体）
- CVE メタ情報（NVD 等）を要約し、発生条件／推奨対策／パッチ状況を整形
- 該当リポジトリのソースコード断片や依存情報を合わせて入力し、影響の“初期アセスメント（仮判定）”を生成
- Dify（CVE 情報のサマライズ用アプリ基盤）
- CVE 情報の取得 → 要約 → 定型フォーマット出力をノーコードでワークフロー化
- Cline（VS Code 上の橋渡し役）
- 人間の意図を生成AIへ正確に渡す橋渡し
- 関連ファイル抽出／依存や設定の文脈束ね／根拠箇所提示を必須化するプロンプト指示を自動化
- Cline 自体が判定するわけではなく、AI の仮評価実行を支援
ワークフロー
- Dependency-Track が新規／更新の CVE を検出（SBOM と照合）
- Dify が NVD 等から CVE メタ情報を取得 → OpenAI API で要約
- 出力：概要／発生条件／推奨対応／パッチ状況（定型フォーマット）
- Cline が該当リポジトリから関連コードを抽出し、要約と合わせて OpenAI API に入力
- 指示例：発生条件の一致／不一致、根拠コード（ファイル・関数・行周辺）、推奨対応
- AI が“初期アセスメント（仮判定）”を出力
- AI が“初期アセスメント（仮判定）”を出力
- 担当者が最終判断し、対応計画へ反映
Dify による CVE 情報の収集・要約
本セクションでは、Dify を用いて CVE 名を起点に脆弱性情報を収集し、生成AI（OpenAI API）で定型フォーマットに要約する仕組みを紹介する。目的は、担当者が初期トリアージに必要な情報（概要／発生条件／推奨対応／パッチ状況）を短時間で得られるようにすることにある。なお、この段階は収集・要約までであり、コード文脈を踏まえた初期アセスメントは次節（VS Code＋Cline＋OpenAI API）で実施する。
フロー概要
- CVE 情報の取得
- NVD 等の API を用いて、対象 CVE のメタ情報を JSON で取得する。
- 生成AIによる要約（OpenAI API を Dify のワークフローから呼び出し）
- 取得した JSON を入力として、以下の項目を定型フォーマットで出力する。
- 脆弱性の概要
- 発生条件
- 推奨される対策
- セキュリティパッチの有無（公開状況・参照 URL）
- 取得した JSON を入力として、以下の項目を定型フォーマットで出力する。
精度向上のためのプロンプト設計
- 有意情報の存在チェックを先行
- 処理冒頭で、入力 JSON に脆弱性に関する有意な情報が含まれているかを検査。情報が不足している場合は推測で補完せず、その旨を明示して終了することで、情報欠落時の「それらしい誤要約」を抑止する。
- 出力テンプレートの明示
- 期待する見出し・項目例（概要／発生条件／推奨対応／パッチ状況）を提示し、フォーマットと用語の揺れを低減する。
- 実行環境に依存する注意の明記
- 本アプリケーションは AWS Lambda 上で動作するため、ローカル権限昇格系など一部の脆弱性は影響が限定され得る。こうした環境前提をプロンプトに明記し、要約に反映させる。
実行例
入力として「CVE-2024-12905」を与えた場合の Dify の出力例の一部を示す。
これは tar-fs パッケージに関し、悪意のある .tar ファイルを解凍することで、意図せぬ不正なファイルアクセスを発生させ得る脆弱性である。
0. cve_request.body の精査
リクエストで与えられた body 内には、CVE-2024-12905 に関する詳細な脆弱性情報が含まれています（説明文、CVSS、影響バージョン、パッチ URL 等）。したがって、以降のリスク評価を実施します。
---
1. 脆弱性の概要
- CVSS スコア: 7.5 (HIGH)
- 脆弱性内容:
tar-fs パッケージの index.js における「シンボリックリンク解決の不備 (CWE-59)」および「制限されたディレクトリへのパス名制限不備 (CWE-22)」により、攻撃者が細工した tar ファイルを展開することで、想定外のディレクトリにファイルの書き込みや上書きが可能となる。
- 主な攻撃手法:
Path Traversal / Symlink Attack
(中略)
---
4. 影響有無を確認する方法
- 使用している Lambda 関数で tar-fs パッケージが対象バージョン（1.16.3 以前、2.1.1 以前、3.0.7 以前）で依存しているか確認。
- 具体的には、Lambda のコードや package.json、依存ツリーで tar-fs のバージョンをチェックする。
- Lambda 関数内で「外部／ユーザーからアップロードされた tar ファイル」などを受け取り、tar-fs を使って展開している処理が存在するか調査する。
- 別ユーザーや非信頼なデータからの tar 展開、または self-extracting のような挙動を設計上許容していないかを確認する。
Lambda 固有の影響について
- Lambda は関数実行ごとに isolated な temporary なファイルシステムを用いるため、恒久的なファイル改ざんは発生しにくい。
- ただし実行中の関数コンテナの /tmp 以下などに意図しないファイル作成や既存ファイル上書きが（セキュリティ設計次第で）成立する恐れがある。
- マルチユーザー／多インスタンス間で共有リソースがないことが多いため、影響範囲は原則関数の実行インスタンス内に限定される。
(以後略)Cline と生成AIを用いたソースコード脆弱性の初期アセスメント
前セクションで作成した CVE 要約（概要／発生条件／推奨対応／パッチ状況）は、初期トリアージに有用だが、「特定の関数・設定・呼び出し経路でのみ成立する脆弱性」など、コード実装の文脈を見ないと判断できないケースがある。
そこで本セクションでは、VS Code 上の Cline（橋渡し役）と生成AI（OpenAI API）を組み合わせ、リポジトリの実装を踏まえた“初期アセスメント（仮判定）”を行う。
目的
- SBOM／CVE 要約だけでは判断が難しい脆弱性について、該当コード・設定・依存関係の有無を確認し、影響可能性・根拠・推奨対応を定型フォーマットで素早く提示する。
入力（AI に渡す材料）
- CVE 要約（前セクションの Dify 出力：概要／発生条件／推奨対応／パッチ状況）
- コード文脈（Cline が収集）
- 該当パッケージの直接／間接依存、関連ファイル群
- 設定値・フラグ・モード（例：オプション有効／無効）
- 呼び出し経路／関数使用箇所、実行環境の制約（例：AWS Lambda の /tmp 限定 など）
役割分担
- Cline（VS Code 拡張／オーケストレーター）
- 人の意図を基に、関連ファイルの抽出、依存や設定の文脈の束ね、プロンプトへの安全な受け渡しを自動化
- 出力に根拠コード（ファイル・関数・行周辺）を必須化するプロンプト指示を付与
- ※Cline 自身が判定するわけではない（橋渡し役）
- 生成AI（OpenAI API）
- CVE 要約＋コード文脈を入力として、影響可能性（仮）／根拠コード／推奨対応を定型フォーマットで出力
プロンプト設計（精度確保の工夫）
- 発生条件の照合を明示：CVE の成立条件を箇条書き化し、コード上で一致／不一致を根拠付きで判定
- 根拠の必須化：ファイルパス、関数名、行周辺、設定値、呼び出し経路などの具体的根拠を必ず提示
- 環境前提の反映：例として AWS Lambda のファイルシステム制約等、環境により影響が緩和される点を前提条件として提示
- 曖昧回答の抑制：該当箇所が見当たらない場合は「見つからず」と明示し、推測で補完しない
出力（初期アセスメントの体裁）
- 影響可能性（仮）：なし／低／要注意 など
- 根拠コード：ファイル／関数／行周辺、設定・フラグ、呼び出し経路
- 推奨対応：アップデート計画、設定変更、ガード追加、将来の実装時の注意点 など
以下は、入力として CVE-2024-12905（tar-fs のパス・トラバーサル）を与えた際の、Cline 経由で実行した初期アセスメント出力の例である。
* tar-fs のパス・トラバーサル脆弱性）影響調査結果
1. 依存関係・バージョン
- amplify/backend/function/FacilityQueries のみ、間接依存として tar-fs@3.0.6（脆弱性対象バージョン）がインストールされています。
- 依存元は @puppeteer/browsers および @sparticuz/chromium であり、いずれも Lambda 本番コードで直接利用されるものではありません。
2. Lambda 関数の実装・ファイル構成
- FacilityQueries を含む全 Lambda 関数で、tar-fs や tar ファイル展開処理（外部から受け取った tar ファイルを展開する等）は一切実装されていません。
- 他の Lambda 関数（AdminQueries, MailQueries, RdsQueries 等）にも tar-fs 依存や tar ファイル展開処理はありません。
3. 影響評価
- Lambda 本番コードで tar-fs の脆弱なバージョンを直接利用していないため、CVE-2024-12905 の実質的な影響はありません。
- puppeteer/chromium 系の依存は主に E2E テストや PDF 生成等の用途であり、外部 tar ファイル展開用途では使われていません。
4. 注意点・推奨
- 将来的に tar-fs の直接利用や、外部 tar ファイル展開処理を Lambda に追加する場合は、必ず安全なバージョン（3.0.8 以降）を利用してください。
- セキュリティ観点から、依存パッケージのアップデートは推奨されますが、現状の Lambda 構成・運用では本脆弱性のリスクはありません。
【結論】
現時点のプロジェクト構成・Lambda 実装・依存関係において、CVE-2024-12905 の影響はありません。まとめ（成果・改善点）
本取り組みでは、Dify（CVE 要約）とCline＋生成AI（コード文脈を踏まえた初期アセスメント）の出力を、セキュリティ担当者が最終判断する運用に組み込んだ。
とくに、Cline 経由の初期アセスメントで「要注意」となった項目については、担当者が再評価を行い、対応の優先度と方針を確定した。
例えば、DoS 系の脆弱性でも「常駐プロセスではない」「外部到達経路が無い」等の条件に該当するものは、現行運用では影響限定と判断し対象外とした。
結果として、検出された脆弱性の相当数が実装や運用形態上の条件不一致で“非影響”と判定され、全面的な一括アップデート方針から、リスクベースでの優先順位付けに切り替えることができた。これにより、修正・試験の工数を大幅に削減しつつ、高リスク領域へリソースを集中できた点が大きな成果である。
なお、本取り組みの出力はあくまで初期アセスメント（仮判定）であり、AI の要約やコード解析には誤要約・コンテキスト不足のリスクがある。そのため、入力 JSON の有意情報チェックや出力テンプレートの厳格化、根拠コードの提示必須化といった抑制策を講じつつも、最終判断は必ず人が行う前提で運用している。また、ゼロデイ直後やベンダ依存で公開情報が不足する局面では、追加の人手調査を前提とする。
今後は、日次レポートの差分ハイライト（新規・重大度上昇・パッチ公開の検知）を強化し、“却下理由”のテンプレート化で判断の再現性・透明性を高める。あわせて、重大度×到達可能性×業務影響に基づく優先度ポリシーの明文化と、CI/CD による変更差分の自動再アセスメントを進め、継続運用の精度とスピードをさらに向上させていく。