脆弱性管理における AI の役割を調査：セキュリティ・エンジニアリングにおける人間の不可欠性

Can We Trust AI To Write Vulnerability Checks? Here’s What We Found

2025/09/29 BleepingComputer — 脆弱性の管理は常に競争である。攻撃者は素早く動き、スキャンには時間がかかる。スキャナが追いつかなければ、システムは無防備な状態に陥る。そのような中、 Intruder のセキュリティ・チームが立ち上げた検証プロジェクトは、AI を活用して高い品質基準を維持しながら、新しい脆弱性チェックを迅速に構築するためのものである。結局のところ、検出が確実でなければ、スピードは意味を持たない。また、実際の問題を見逃すチェックは役に立たないが、誤検知は効率を著しく悪化させる。この記事では、AI を用いて行った実験の方法と、上手く機能している点と、問題が残る点を紹介する。

ワンショット・アプローチ vs. エージェント・アプローチ

まず単純な手法から試した。LLM チャットボットにプロンプトを投入し、Nuclei テンプレートを生成できるかどうかを検証したが、結果は散々だった。その出力には、存在しない機能への参照や、無効な構文、脆弱なマッチャーやエクストラクタが含まれており、ChatGPT／Claude／Gemini でも同様の問題が確認された。

そこで、エージェント型アプローチを試した。チャットボットとは異なり、エージェントはツールの使用／参考資料の検索／ルールの遵守が可能である。バイブコーディングの失敗もあり、当初は懐疑的だったが、すぐに改善が見られた。

Cursor のエージェントを使用すると、最小限のプロンプトでも初期の実行時の出力品質が大幅に向上した。さらにルールを重ね、Nuclei テンプレートの厳選されたリポジトリをインデックス化することで、このエージェントは確かな学習例を得て、不整合が減り、適切な機能の使用が促された。結果として、テンプレートの品質は顕著に向上し、エンジニアが作成するものに比肩するようになった。

しかし、エージェントを設定して放置すると、依然として軌道修正が必要な状況に陥った。しかし、明確なプロンプトを与えれば、手作業で作成したかのようなチェックを生成できた。この結果により目標が変化した。つまり、完全な自動化ではなく、高品質チェックを迅速にリリースする、生産性向上ツールを目指すことにした。

現在のワークフロー

現時点で採用しているプロセスでは、標準的なプロンプトとルールセットを使用する。エンジニアは以下の主要な情報を入力する：

• 対象ページ
• 使用するマッチャーの種類 (必要な場合) 
• 脆弱性スキャン結果から抽出する重要データ

これらの入力が完了すると、エージェントがテンプレートを生成する。完全な自動化ではないが、従来より高速であり、エンジニアの本来の役割である、より深い調査のための時間が確保できるようになった。

成功事例

攻撃対象領域のチェック

公開テンプレートが存在しない環境のチェック作成において、Agentic AI は特に有用である。特に効果的なのは、インターネットに公開された管理パネルの検出である。原理的には単純なチェックだが、大規模に作成するには時間を要する。したがって自動化により、はるかに多くのチェックを迅速に生成できる。

さらに、内部で使用する主要スキャナがカバーしていない製品の数には、我々も驚かされた。試行したプロセスは、そうした隙間を埋め、攻撃対象領域のより完全な把握を、顧客に対して提供する。仮想マシン・スキャナが露出パネルを検知せず、かつ環境が広範である場合には、その存在に気付かない可能性が高い。

保護されていない Elasticsearch

エージェント・ワークフローの即効性のある成果として、保護されていない Elasticsearch チェックを作成した。オープンな Nuclei 検出テンプレートは存在していたが、誰もがデータを読み取れる状態で放置されるインスタンスという、最悪のケースがカバーされていなかった。我々が確実に検出したいのは、まさに、このケースであった。

エージェントに与えた情報は以下の通りである：

• タスクの概要 (2～3文で簡潔に)
  例：Elasticsearch インスタンスを検知し、X エンドポイントにリクエストを送信後、Y エンドポイントに追跡リクエストを送信して、データの露出を検証する。
• Elasticsearch サーバをホストするテスト対象リスト
• 検証手法に対して脆弱な対象の例
• 脆弱性のない対象の例

その後にエージェントは、設定されたカスタム・ルールに基づき、このプロセスを反復実行した。最終的な成果物は Nuclei テンプレートであり、それによりデータソースがリストされ、未認証ユーザーによるデータ閲覧の可否が、有望なエンドポイントを追跡することで確認される。それは、自動スキャンに適した動作を可能にする、マッチャーとエクストラクタを備えたマルチ・リクエスト・テンプレートである。

セキュリティ・エンジニアリング・チームによる、手動での入力と判断は依然として必要であるが、反復的な重労働はエージェントが担うことになる。

現時点における問題点

現在の出力の限界

どれだけルールを設定／整備しても、エージェントが逸脱する場合がある。たとえば、公開された管理パネルのチェックを構築した際に、十分な強度のマッチャーが含まれていなかったことで、誤検知のリスクが生じた。そこで、追加プロンプトで製品固有のファビコン・マッチャーを導入して修正したが、依然としてエージェントにはガードレールが必要なことが明らかになった。最も強力なマッチャーを確実に選択し、検証できるようになるまでは、人間の監視が不可欠である。

Curl 出力の切り捨て

Cursor はトークンを節約するために、”curl” レスポンスを “head” へとパイプすることが多々ある。しかし、それにより理想的なマッチャーとなるべき、固有の識別子を見逃す可能性がある。この機能は効率化のためのものだが、意図した結果を妨げる弊害があるため、完全な解決には至っていない。

基本を忘れる

Cursor は Nuclei 独自のフラグ (例：ホストリスト実行用の -l) を無視し、その代わりに手動ループのスクリプトを生成する場合がある。そのため、主要な Nuclei 機能を再認識させ、この非効率性を排除するための、新しいルールの開発に取り組んでいる。

今後の展望

AI は複雑な作業を完全に代替する万能薬として、いたる所で宣伝されている。しかし、我々の見解では、その多くはマーケティングによる誇大宣伝である。実際のところ、AI エージェントにセキュリティ・エンジニアリングを、手放しで任せられる段階には程遠い。

不可能とは言わないが、現時点において完全な自動化を主張する声に対しては、警戒が必要である。その一方で、脆弱性の管理における AI 活用は、生産性向上ツールとして機能するため、安全な自動化に向けて可能な範囲で推進させ続けるべきである。

結論として、脆弱性を見逃さず誤検知も発生させない、高品質なカスタム・チェックを提供するには、専門のエンジニアが依然として不可欠である。

脆弱性スキャンにおける AI 活用の試みが、Intruder により推進されているようです。そこで発見された大きな問題は、単純な LLM チャットボットでは生成結果が不安定となり、存在しない機能参照や誤った構文が取り込まれてしまう点です。その一方で、エージェント型のアプローチを導入すると、ルールや既存テンプレートを参照しながら生成が行われるため、精度が大きく改善したと説明されています。ただし完全な自動化は難しく、誤検知を防ぐためには人間の監視や補正が不可欠であると、この記事は指摘しています。よろしければ、カテゴリ AI/ML と、LLM で検索を、ご参照ください。