AIエージェントが守るセキュリティ--少人数チームの脆弱性対策の常識を変えた話 (3/3)

第3回：AIエージェント防御パターンの応用可能性

第1回・第2回で紹介したCVE自動トリアージシステムを運用してわかったこと、そしてこのパターンの応用先を考えます。

LLMの判定精度——「使える場面」と「信用してはいけない場面」

スクリーニングLLMの偶陰性（影響ありを「なし」と誤判定）は、運用開始以降まだ確認されていません。ただし、これは「LLMが完璧」という意味ではありません。LLMが得意な場面と苦手な場面を正確に把握した上で、「得意な部分だけ任せている」結果です。

LLMが得意なこと：

明らかに無関係なCVEの除外は非常に正確です。D-Linkルータ、Cisco IOS、WordPressプラグイン、Android SDK固有の問題など、descriptionを読めば「自社に無関係」と明白なCVEは、LLMはSBOMと照合して正確に弾きます。これは全体の80〜90%を占めるため、この層だけでも自動化の価値は大きいです。

また、「この脆弱性はサーバーサイドで外部入力を処理するコンポーネントに影響するが、当該エンドポイントは認証必須のため攻撃条件を満たさない」といった、サービス仕様書と組み合わせた文脈判断も得意です。これは人間がやっても同じ結論に至る判断ですが、毎日数十件のたびに手作業でやるのは非現実的です。

LLMが苦手なこと：

一方で、「影響はあるが、実際に攻撃が成立するか」という最終判断は人間に残しています。たとえば、「この脆弱性はNext.jsのMiddlewareで特定のヘッダを検査している場合にのみ悪用可能」といった、自社の実装の細部に踏み込んだ判断はLLMには難しい。サービス仕様書にそこまで書かれていないからです。まだ検証していませんが上位フェーズで作成したドキュメント（要件定義書、設計書、運用設計書など）を読み込ませることでこの部分については精度の向上が見込まれるのではないかと思っております。

また、バージョン比較にも注意が必要です。「15.0未満に影響」のような明快なケースは正確ですが、ディストリビューション固有のバージョン文字列やプレリリースバージョンの前後関係では誤判断のリスクがあります。そのため、最近の改善としてSBOMからバージョン情報をプロンプトに含めるようにしました。LLMがバージョン照合の「材料」を持つことで、判断精度は上がります。ただし、これでも完璧ではないため、影響度「高」のCVEは必ず人間が二次確認するルールにしています。

要は、完全な自動化ではなく「人間の判断を支援する自動化」です。「100件のCVEを目視で確認する」から「5件だけ人間が確認する」に変わるだけで、少人数チームのセキュリティ運用は劇的に変わります。

キーワードマッチのチューニングは終わらない

SBOMから自動生成されるキーワードリストは、そのままでは使えません。

Node.jsのエコシステムを例に取ると、buffer、events、string_decoder、pathといったパッケージ名が大量に含まれます。これらはCVEのdescriptionに普通の英単語としても頻出するため、誤検知が大量に発生します。実際に、除外リストなしで回すとキーワードマッチのヒット率が跳ね上がり、その分だけスクリーニングLLMのAPIコストが増えます。

対策として、以下の3層でノイズを制御しています。

1. 生成時フィルタ: OSパッケージ（deb/rpm）を2文字以下のパッケージ名を自動除外
2. 除外リスト: api, auth, core, util, buffer, link, send等の汎用語を手動で追加
3. 単語境界マッチ: 5文字未満のキーワードには\bws\bのような正規表現を適用し、部分一致を防止

このチューニングは一度やって終わりではありません。依存パッケージが変わればキーワードリストも変わり、新しいノイズが生まれます。ただ、ノイズが多少残ってもスクリーニングLLMが弾くので、実害はAPIコストが微增するだけです。「100点を目指さない」という割り切りが、少人数チームでの運用には重要です。

「LLMエージェント×防御」のパターン——CVEトリアージの先へ

今回構築したシステムの本質は、CVEトリアージという個別のタスクではなく、「大量の非構造化情報を読み、自社のコンテキストに照らして判断する」というパターンです。このパターンを構成する3つの要素を抽象化すると、他の領域への応用が見えてきます。

情報ソース（何を監視するか）
  × 自社コンテキスト（何と照合するか）
  × 判断基準（何を出力するか）
  → LLMが判断

CVEトリアージでは「情報ソース=NVD、コンテキスト=SBOM+仕様書、判断基準=影響あり/なし」ですが、この3つを差し替えるだけで別の監視システムが作れます。

セキュリティ領域の応用：

WAFログの異常検知トリアージ CloudflareやAWS WAFのログは1日数万件になることがありますが、その大半はボットによるスキャンや誤検知です。情報ソース=WAFログ、コンテキスト=自社の正常トラフィックパターン+エンドポイント一覧、判断基準=実際の攻撃/ノイズ、という構造で、「毎日数万件のログから本当に危険な5件を抽出する」システムが作れます。

依存パッケージのライセンス監査 OSSのライセンス違反は、気づかないうちに蓄積するリスクです。特にGPL汚染は、推移的依存経由で意図せず混入することがあります。SBOM+ライセンスDBをLLMに渡し、「この依存関係はGPLライセンスを含むが、自社製品のライセンスと互換性があるか」を自動判定できます。

インシデント対応の初動自動化 監視アラートが発火したとき、「アラート内容+ランブック（対応手順書）」をLLMに渡し、初動手順をSlackに投稿するシステムです。深夜のアラートで「まず何をすればいいか」が自動で届くだけで、初動対応の速度と精度が変わります。

ビジネス領域の応用：

法改正・規制変更の影響判定 個人情報保護法、電帳法、景品表示法など、Webサービスに影響する法規制は多岐にわたります。情報ソース=官報・パブコメ、コンテキスト=自社サービス仕様、判断基準=対応要/不要、という構造で、「この改正は自社の○○機能に影響する可能性がある」と自動でアラートできます。

競合プロダクトの変更検知 競合のリリースノートやchangelogを定期取得し、自社の製品ロードマップと照合して「この機能追加は自社の○○と競合する」と通知する。少人数チームでは競合監視に専任を置けませんが、AIなら隈なく見張れます。

共通するのは、どれも「専任がいればやってもらえるが、少人数では後回しになりがちなタスク」だということです。まさにLLMエージェントが埋めるべきギャップです。

まとめ

React2Shellは世界中のエンジニアにとって、AI時代のセキュリティ対策を意識させるインパクトのある脆弱性でした。CVSS 10.0の脆弱性が公開され、数時間で実際の攻撃が始まる。しかもAIエージェントの活用でエクスプロイト開発コストは急速に下がっています。

攻撃者には倫理的制約がありません。世界中の本番環境を「練習台」にし、成功すれば手法が磨かれ、失敗してもコストはほぼゼロ。その上、AIが攻撃コードの生成まで自動化する。防御側が常に後手に回るという構造的な非対称性の上に、AIによる速度の非対称性まで加わったのが現在の状況です。

この非対称性に対抗するには、防御側もAIを使うしかありません。「専任がいないからできない」ではなく、「自動化すればできる」。人がいないはもう理由になりません。それが今回の実践で得られた最大の知見です。