ExploitHunter.app の発表

スコープ、承認、ツール、証跡を1つのプロジェクトで一元管理するオープンソースのセキュリティ作業台。

目次

• このループは意図的に退屈だ
• プロダクトは証拠だ
• 1つのターゲット、8つのモデル
• ベンチマークがベンチマークを捕まえた
• タスクごとにモデルをルーティングする
• deepsec、VulnHunterなどとの位置づけ
• ローカルで実行する。責任を持って使う。
• 次にやること

セキュリティツールには、書類仕事の問題がある。

怪しい行を見つけ、深刻度のバッジを付け、そしてそれが本当に重要なのかを証明する作業を、ひっそりこちらに押し付けてくる。検出結果は「high」だ。証拠は、トレンチコートを着せた grep 3回分だ。

AIエージェントは、この作業の流れを短縮できる。その一方で、曖昧な指示とブラウザとシェルを、検証されていない活動の山へと、はるかに速く変えてしまうこともある。

ExploitHunter.app は、スキャナーが止まるところから始まる。認可済みのターゲットと目的を与えると、エージェントは到達可能なルートを洗い出し、ブラウザを操作し、ターミナルやセキュリティツールを実行し、仮説を検証し、その検出結果を裏付けるレスポンス、スクリーンショット、トランスクリプトを保存する。そして、その証拠を引用付きのレポートに仕立てる。

オープンソースで、ローカルファーストだ。ターゲット、承認、履歴、証拠を別々のプロジェクトに分断することなく、ホスト型モデルとローカルモデルを切り替えられる。

チャットボットを貼り付けただけのスキャナーではない。エージェントが何を試し、何が返ってきたのかを覚えているワークベンチだ。

セキュリティについて語るだけなら簡単だ。役に立つのは、認可済みのチェックを実行し、証拠を保存し、次の一手を渡すことだ。

このループは意図的に退屈だ

ExploitHunter のプロジェクトは、毎回同じ順序をたどる。

authorize target → plan → request approval → probe → save evidence → prioritize → report

エージェントには実際の到達範囲があるため、この順序が重要になる。

ターゲットの認可は、会話のコンテキストではなくプロジェクトの状態だ。「どうぞ、進めて」といった言葉が、3ターン後には別の意味を持ち得るチャットメッセージの中に置かれるものではない。アクティブスキャン、認証情報のテスト、シェルコマンド、ファイルへの書き込みは、すべて承認ゲートの内側にある。影響の大きいコマンドの承認は、意図、プロジェクト、ターゲットにひも付けられる。デフォルトでは1回限りだ。

承認ゲートは、製品の売り文句の下に置かれた細かい但し書きではない。エージェントを実際のツールにつなぐことを現実的にする仕組みそのものだ。スコープの逸脱を抑え、記憶への依存を減らし、チームに「AIがそう言ったから」よりましなものを残す。

プロダクトは証拠だ

セキュリティ作業で永続的に残る単位は、モデルの最終回答ではない。証拠だ。

アプリを閉じる。モデルを変える。明日戻ってくる。それでも調査には記憶が残っている。

ExploitHunterはプロジェクトとスレッドの履歴を保持するが、永続的に残る記録は証拠パイプラインだ。何を試したのか、どの承認の下で、承認済みのどのターゲットに対して実行し、何が返ってきたのか。プローブ、レスポンス、コマンドのトランスクリプト、スクリーンショット、裏付けとなるアーティファクトは、検出結果とともに保存される。レポートは、モデルの締めくくりの段落を言い換えるのではなく、実際の作業を引用する。

そこから検出結果を、修正対応の追跡、亜種の分析、攻撃経路の調査、そしてレビュー担当者が行単位で確認できるレポートへとつなげられる。

自分本位な利点もある。デバッグが神秘的な作業ではなくなるのだ。エージェントが何かを見落とした、ツールを使いすぎた、結論をでっち上げた、アーティファクトの保存に失敗した。そうした失敗は記録の中で見える。チャットの吹き出しを写したスクリーンショットと口論するのではなく、製品を直せる。

1つのターゲット、8つのモデル

すべての実行に記録が残るから、モデルの比較が雰囲気頼みの作業ではなくなる。

8つのモデルルートに、同じ難度の高いJuice Shopタスクを与え、ExploitHunterの実際のアプリケーション経路で実行した。ターゲットは同じ。ツールも同じ。証拠の契約も同じ。どのモデルが実行されたのかを証明できない実行や、出力を保持できない実行は、表に載せなかった。ベンチマークは曖昧さを楽しめる。請求書はそうはいかない。

| モデルルート | 判定 | コスト | 実行時間 | ツール呼び出し | 読み取れること | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4秒 | 8.0 | 満点を取った2モデルのうち、低い価格で最高品質 | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9秒 | 8.0 | Kimiと同じ品質で、ほぼ2倍速いが、コストは7.4倍 | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5秒 | 32.0 | 満点の2ルートを除けば最高スコア | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2秒 | 3.3 | コストと速度の最良結果 | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5秒 | 6.0 | 同じスコアで、価格と速度の両方でSolを上回る | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6秒 | 10.0 | 能力はあるが、この条件ではTerraに完全に負けている | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9秒 | 16.5 | 最安設定で効率は上がったが、品質はまだ後れを取る | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6秒 | 4.3 | 速くて安いが、デフォルトルートにするには変動が大きすぎる |

これはランキングではなく、ルーティングポリシーとして読むべきだ。

効率のよい出発点はLunaだ。 DeepSeekなら判定スコアをさらに3分の2ポイント上げられるが、コストは約3.6倍、実行時間は7.6倍、ツール呼び出しは9.6倍になる。KimiはOpusの請求額を払わずに10/10へ到達する。Opusはさらに1.41ドル払えば、同じスコアに約108秒早く到達する。GPT OSSは監督下での実験にとどめるべきで、このタスクではTerraのほうがSolより強い根拠を示している。

このフロンティア上にいるのはLuna、DeepSeek、Kimiだけだ。他のルートが役に立たないわけではない。生のスコアとコスト以外の理由が必要になる。Opusは速度を買う。TerraはSolの請求額を払わずに、モデルファミリーの制約を満たせる。GPT OSSは、監督下で試すには十分安い。

方法論、ツール予算、ネガティブコントロール、そしてコマンドのトランスクリプトにすでに答えがあるときにモデルがどう自爆するかまで含めた長い版は、Security Agents Need Model Routers, Not Model Rankingsにまとめている。

ベンチマークがベンチマークを捕まえた

最も重要な結果は、どのモデルが勝ったかではなかった。スコアラーの失敗だった。

最初のアーカイブ復元レポートでは、Kimiが5/10、GLMが9/10だった。タスク自体は成功していた。両方のエージェントがharbor-lantern-47を復元しており、ホスト側で独立に実行したunzip -t -Pチェックによって、そのパスワードが機能し、他の候補は機能しないことも証明されていた。

ジャッジは、証拠の書き込みが必須だったネイティブなExploitHunterタスクに対して、Cybenchの生の禁止ツール監査を適用していた。ハーネスが要求した正確な挙動を、逆に減点していたのだ。同じモデルの出力。同じ保存済みトレース。間違った評価基準。

無関係な監査を取り除くと、Kimiは5/10から10/10に上がる。GLMは9/10のままだ。修正後のスコアは、browser-e2e-llm-judge-correctedとして元のLangfuseトレースに書き戻された。7月17日に行った読み取り専用APIチェックでも、永続化されたトレースID上で両方の値が確認された。

この5点の変動が、ExploitHunterが評価を一つの英雄的な数字に潰してしまわず、トレース、証拠、スコアラーのバージョン、コスト、トークン数、ツール予算、ハーネスの失敗を保存する理由だ。ベンチマークが自分の仕事の過程を示せないなら、それは自信満々に主張する別のモデルにすぎない。

タスクごとにモデルをルーティングする

ExploitHunterは、モデルプロバイダーの長い一覧に対応しているだけではない。それらをベンチとして扱う。

偵察、エクスプロイト検証、ブラウザフロー、証拠の統合、そして修正案の提示。どれもセキュリティ作業だが、同じモデルタスクではない。

Capital OneのVulnHunterは、Claude/Claude Code向けに最適化したソース解析ワークフローに明確に賭けている。ExploitHunterの賭けは別だ。プロジェクトのスコープ、承認、ツール、証拠は固定したまま、作業内容に応じてモデルの経路を切り替える。

広範なWeb偵察では、安価で高速、かつツール予算を絞ったモデルが有利かもしれない。制約のあるローカルラボでは、プライバシーとオフライン推論が優先されるかもしれない。難しい検証や最終レポートなら、遅くても最先端モデルへのルートを選ぶ価値がある。ExploitHunterは、ターゲット、履歴、承認、ツール、成果物をその場に残したまま、作業をそれぞれのレーンに移す。

正しいモデルとは、設定画面に並ぶロゴではなく、ルート選択だ。

ExploitHunterはホスト型プロバイダーだけでなく、OllamaとLM Studioにも対応している。ローカルのNodeサービスとしても、Electronデスクトップアプリとしても実行できる。ホスト型APIキーを空欄にしておけば、互換性のあるローカルモデルによって候補の調査を有料プロバイダーの外で続けられる。速度や難しい問題への対応が必要なら、ホスト型のルートを使えばいい。数秒の短縮よりも境界の維持が重要な機密作業は、ローカルに留めればいい。

あらゆるセキュリティタスクを、利用可能な中で最も高価なモデルに送れば道徳的な勝利になるわけではない。残るのは請求書だけだ。

deepsec、VulnHunterなどとの位置づけ

ExploitHunterは、コードスキャナーのハーネスより意図的に広い。実行中のターゲットに候補を持ち込み、ブラウザとターミナルのツールで調査し、証拠を保存したうえで、検証済みの検出結果を、それを修正すべきシステムに渡す。

現在、複数のプロジェクトがこのワークフローの異なる部分をカバーしている。それでいい。セキュリティチームに必要なのは、作業を相互に引き渡せるツールであって、また一つの総取りカテゴリーで勝者を決めることではない。

| ツール | 強い領域 | ExploitHunterとの違い | |---|---|---| | Vercel deepsec | コードベースを中心としたハーネス。静的な候補検出、コーディングエージェントによる調査、再検証、情報拡充、そして任意の大規模サンドボックス分散実行。 | deepsecはリポジトリ解析とPR中心のフォローアップに適している。ExploitHunterは、実行中のアプリ、ブラウザ、ネットワークラボ、ターミナル、永続的な証拠、明示的なオペレーター承認を含み得る、承認済みの調査プロジェクトを中心に据える。 | | Capital One VulnHunter | 攻撃者視点のソース解析、検出結果の構造化された反証、コード修正案への集中。 | 重なりは実際にある。証拠の提示と誤検知の削減は、最低限必要な要件であるべきだ。ExploitHunterはコーディングハーネスや単一のモデル経路への依存が薄く、コード変更を提案する前の調査の調整に重点を置く。 | | GitHub Security Lab Taskflow Agent | 宣言的でMCP対応のタスクフロー。特にCodeQLアラートのトリアージとバリアント解析。GitHubによれば、実環境の脆弱性をおよそ30件発見するのに役立っている。 | 入力が反復可能なコードスキャンワークフローなら、これが適切な基盤になる。ExploitHunterは、より長い調査の中でもスコープ、承認、証拠を維持する必要がある、探索的でツールを使う調査のためのワークベンチだ。 | | OpenHands Vulnerability Fixer | Trivyなどのスキャナー出力を、優先順位付きの修正、テスト、プルリクエストに変換する。 | 修正を生産する工場だ。ExploitHunterはその前段にある。検出結果が本物であることを確認し、その理由を記録し、十分な裏付けのある問題を修正システムに渡す。 | | Assay | エージェントのツール呼び出しに対するオフラインのポリシー適用、決定論的なリプレイ、暗号学的な証拠バンドル。 | 競合ではなく補完関係にある。エージェントによる調査ワークスペースが、自身の承認レイヤーの下で利用できるべき、デフォルト拒否型のランタイム制御の好例だ。 |

実用的なスタックには、おそらくこれらのうち一つ以上が含まれる。ソーススキャナーが候補を挙げ、タスクフローが繰り返し現れるパターンをトリアージし、調査ワークスペースが危険なケースを検証し、修正エージェントが検証済みの作業をレビュー可能なパッチに変える。重要なのは引き継ぎであって、セキュリティのマスコットを決めることではない。

ローカルで実行する。責任を持って使う。

ExploitHunterはMITライセンスで提供されるオープンソースであり、自分に実施権限のある作業を想定して構築されている。リポジトリには、強化済みのローカルJuice Shopターゲットと複数サービスのネットワークラボが同梱されている。そのため、自分が所有していない対象にエージェントを向けることなく、ワークフロー全体を試せる。

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

次に、http://localhost:3210 を開く。

モデルルートを選び、自分が所有している、またはテストする明示的な許可を得ている対象を認可し、エージェントに目標を与える。エージェントに作業をマッピングさせ、自分が本当に実行するつもりのアクションだけを承認し、証拠がチャット履歴の中へ消えていくのではなく、積み上がっていく様子を確認する。

それが、エージェント型セキュリティの退屈なほうの姿だ。

そして、面白い局面が始まったときに自分の側に置きたいのも、こちらの姿だ。

次にやること

次の仕事は、自律型ハッキングについてさらに大きな主張をすることではない。研究ループの信頼性を高めることだ。再実行結果のレポートを改善し、証拠の検証を厳格にし、ローカルモデルの対応範囲を広げ、承認状況をより明確にし、検証済みの発見から人間がマージしたいパッチへ、より速く到達できるようにする。

セキュリティエージェントに必要なのは、無制限に即興できる余地ではない。こちらを驚かせるのに十分な到達範囲と、その範囲を囲う明確な境界、そして成功したと主張するときの証拠だ。

それがExploitHunterだ。モデル、ツール、ラボ、承認、証拠、そしてフォローアップを、同じ問題に向けるための一つの場所である。

さあ、自分に壊す許可があるものへ向けてみよう。