AIに脆弱性チェックの作成を任せて信頼できるのか？私たちの調査結果

脆弱性管理は常に競争です。攻撃者は素早く動き、スキャンには時間がかかります。スキャナーが追いつけなければ、あなたは危険にさらされます。

そこで、Intruderのセキュリティチームはリサーチプロジェクトを開始しました。AIを活用して、高品質を維持しつつ新しい脆弱性チェックをより速く作成できるのか、というものです。

結局のところ、検出の精度が高くなければスピードは意味がありません。誤検知を出す（あるいは本当の問題を見逃す）チェックでは、誰の役にも立たないのです。

本記事では、私たちがAIでどのような実験を行ってきたか、うまくいっている点と課題についてご紹介します。

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

まずはシンプルに、プロンプトをLLMチャットボットに入力し、Nucleiテンプレートを書けるか試しました。結果は散々でした。存在しない機能を参照したり、無効な構文を出力したり、弱いマッチャーやエクストラクターを使ったりしました。これはChatGPT、Claude、Geminiすべてで一貫していました。

そこで、エージェント型アプローチを試しました。チャットボットと違い、エージェントはツールを使い、参考資料を検索し、ルールに従うことができます。最近の「バイブコーディング」の失敗例もあり半信半疑でしたが、改善はすぐに見られました。

Cursorのエージェントを使ったところ、最小限のプロンプトでも初期出力の品質がはるかに有望であることがすぐに分かりました。

そこから、ルールを重ね、厳選したNucleiテンプレートのリポジトリをインデックス化しました。これにより、エージェントは良い例から学び、一貫性が向上し、適切な機能を使うようになりました。テンプレートの品質は目に見えて向上し、エンジニアが作成するものに近づきました。

しかし、完全に放置できるわけではありません。エージェントはまだ軌道修正が必要です。ただし、明確なプロンプトを与えれば、手書きのようなチェックを生成できます。

この時点で私たちの目標は「完全自動化」から、「品質を落とさずにチェック作成を加速する生産性ツール」へとシフトしました。

現在のワークフロー

現時点で私たちが採用しているプロセスは、標準的なプロンプトとルールのセットを使っています。エンジニアが以下のような主要な入力を提供します：

• アクセスするページ

• 使用するマッチャーの種類（必要な場合）

• 脆弱性スキャン結果として抽出すべき主要データ

これらが揃えば、エージェントがテンプレートを作成します。完全な「バイブコーディング」ではありませんが、はるかに速く、エンジニアがより深い調査に時間を割けるようになります。

成功事例

アタックサーフェスチェック

エージェント型AIは、公開テンプレートが存在しないチェックの作成に特に役立ちました。特に効果的だったのは、インターネットに公開された管理画面の検出です。原理はシンプルですが、大量に書くのは時間がかかります。自動化により、これらをより多く、より速く作成できるようになりました。

主要なスキャナーがカバーしていない製品が意外と多いことに驚かされます。このプロセスにより、そのギャップを埋め、お客様により包括的なアタックサーフェスの可視化を提供できます。VMスキャナーが管理画面の公開を検知できず、資産が多い場合、存在に気づかない可能性が高いのです。

無防備なElasticsearch

エージェント型ワークフローの「手軽な成功例」として、無防備なElasticsearchチェックを作成しました。公開Nuclei検出テンプレートは存在していましたが、最悪のケース（誰でもデータを読めてしまう状態）には対応していませんでした。私たちが確実に検出したかったのはこのケースです。

エージェントに与えた情報：

• 2～3文でタスクを説明（例：Elasticsearchインスタンスを検出し、Xエンドポイントにリクエスト、その後Yエンドポイントにリクエストして本当にデータが公開されているか確認）

• Elasticsearchサーバーをホストしているテスト対象リスト

• 今回検証したい手法で脆弱だった例のターゲット

• 脆弱でなかった例のターゲット

エージェントは、私たちが設定したカスタムルールに従ってプロセスを繰り返しました。

最終的に、データソースをリストアップし、有望なエンドポイントをたどって認証なしでデータが読めるか確認するNucleiテンプレートが完成しました。複数リクエスト対応で、マッチャーやエクストラクターも実用的な自動スキャン向けのものです。

セキュリティエンジニアリングチームによる手動の判断や入力は残りましたが、繰り返し作業はエージェントが担いました。

課題

ここまでの取り組みでも、行き詰まりや方針転換は避けられませんでした。

現状の出力の限界

ルールを設けても、エージェントが逸脱することがあります。例えば、公開管理画面のチェックを作成した際、マッチャーが弱く誤検知のリスクがありました。追加プロンプトで修正できましたが（その製品固有のファビコンマッチャーを追加）、エージェントにはまだガードレールが必要だと再認識しました。最強のマッチャーを確実に選び、検証できるようになるまでは、人間の監督が不可欠です。

curl出力の切り捨て

Cursorはトークン節約のために‘curl’のレスポンスを‘head’でパイプ処理することが多いです。これにより、理想的なマッチャーとなるユニークな識別子を見逃すことがあります。効率化のための機能ですが、私たちには不都合で、まだ完全な解決には至っていません。

基本の見落とし

CursorがNucleiのフラグ（例：-lでホストリストを指定）を見落とし、手動ループをスクリプト化してしまうことがあります。Nucleiの主要機能を思い出させ、非効率を排除する新たなルールを作成中です。

今後の展望

AIはあらゆる分野で「万能薬」として宣伝されていますが、私たちの視点では多くがマーケティングの誇張です。AIエージェントにセキュリティエンジニアリングを完全に任せるには、まだまだ道のりは長いと考えています。

不可能だとは言いませんが、現時点で完全自動化を謳う人には慎重な姿勢を取っています。今後もAIを生産性向上ツールとして、また可能な範囲で安全な自動化に向けて活用していきます。

しかし、現時点での結論は明確です。脆弱性を見逃さず、誤検知も出さない高品質なカスタムチェックを提供するには、専門エンジニアが不可欠です。
 

著者プロフィール：Benjamin Marr、Intruder セキュリティエンジニア

BenはIntruderのセキュリティエンジニアで、攻撃的セキュリティスキャンの自動化やセキュリティリサーチを担当しています。OSWE認定ペネトレーションテスターおよびPHPソフトウェアエンジニアの経歴を持ちます。

Intruderによるスポンサー記事・執筆。