何が変わったのか

VVAHはVisaが6月にGitHubへ公開したオープンソースの脆弱性エージェント基盤です。今回の更新で、パイプラインが「発見・検証・報告・修正」から「発見・検証・修復・検証・反復」へ拡張されました。修正が攻撃を無効化できなかった場合、構造化された自動フィードバックが前回の学習を保持したうえで再試行に回ります。Rajat Taneja氏(Visa president of technology)は「discover, verify, remediate, validate, iterate へ移る」と表現しています。

技術面では、スキャン処理が抽象構文木(AST)ベースのコールグラフに再設計されました。サブルーチン呼び出しと「攻撃者が到達しうる経路」をマップする構造で、Taneja氏はこれによりトークン消費を抑えつつ「推論・コンテキスト・エクスプロイト可能性分析」が改善したとしています。さらにステージ横断のMTTA可観測性とリアルタイム進捗ビューが追加されました。

もう一つの実質的な変更がマルチモデル対応です。ステージごとに使うモデルを、コード変更ではなく設定で選べるようになりました。6月時点では修正適用にAnthropicバックエンドが必須で、OpenAI互換バックエンドはレポート専用でしたが、現在のREADMEでは共通のモデル非依存ランタイムを通じてOpenAI互換モデルやオープンウェイトモデルでも修復・検証が動きます(ただし両ステージの既定ルーティングはAnthropicのまま)。Taneja氏は「Mythosは再現率が非常に高く、Opusは適合率が非常に高い」と述べ、使い分けの発想を示しています。

既定値そのものが論点

最大の争点は「何もオプションを付けずにスキャンすると、11ステージが全部走り、対象リポジトリのソースファイルが書き換わる」という既定の挙動です。検出で止めたければ --stop-after s9 のように運用者側で明示的に上限を切る必要があります。パッチ生成と実ファイル書き込みの間に承認ステップは存在しません。

この既定値が出たのは、Tenet SecurityがDEF CON 34のメインステージでGhostJacking——エージェントがログファイルから攻撃者のペイロードを読み取り、正規の資格情報でDNSを書き換える攻撃チェーン——を実演した18日後でした。さらにリリースの2日前、Exabeam のChief AI and Product Officerであり OWASP Top 10 for LLM Applications のプロジェクト共同リードでもあるSteve Wilson氏が、VentureBeat上で正反対の既定値を主張しています。「まず私がやるのは、モデルの外側に認可ゲートを置くことだ」「エージェントは正確なDNS変更を提案できるが、それを実行する権限を自分に与えることはできない」。Wilson氏は、プロンプト内に書かれたセキュリティルールはモデルへの「提案」であって強制力のある統制ではない、と釘を刺します。

Visa側の反論は運用設計の話です。「VVAHはハーネスであってマージツールではない」「ステージ10は作業コピーに候補修正を書き込み、ステージ11が敵対的検証パネルを走らせて validated / validation failed / needs review の3判定を返す」とし、人間のゲートは①ツールを実行する前②パッチをレビューするとき③マージする前の3か所にあると説明します。実際、ステージ11はREADME上リードオンリーで、VVAHはパッチ適用後のツリーをコンパイルもビルドもテスト実行もしません。

両者の差は、ゲートが「行為の前」にあるか「書き込みの後」にあるか、です。Wilson氏の設計は実行前に許可を判定する。Visaの既定は、実行前と書き込み後に人間を置く。ここが今回のニュースの本質的な分岐点です。

MTTAという新しい物差し

Visaはハーネスと同時にMean Time to Adapt(MTTA)という指標を打ち出しました。Taneja氏はこれを「最も戦略的に重要な指標」と位置づけ、関心をスキャン量から「企業がどれだけ速く適応できるか」へ移すものだと説明します。「見つけることではない。直すことが重要だ」。一部の解決は数週間から数時間に短縮されたとしています。

ただし現時点でMTTAの定義は出典によって3種類あります。今回のリリースの短い定義(攻撃経路の発見から解決までの時間)、6月のProject Glasswing白書の3次元構成(インベントリの鮮度、リリースあたりのエクスプロイト可能経路、検証サイクルタイム)、そしてリポジトリ版(AIが発見したエクスプロイト可能性から本番での検証済み修正までの経過時間)。指標を採用する側は、どの定義で語られた数字なのかを毎回確認する必要があります。なお、精度・再現率の数値はREADME上「未公開」と明記されています。

出自と生態系

VVAHはAnthropicのProject GlasswingにVisaが参加した中から生まれました。日々数十億件の取引を支えるネットワークにClaude Mythosを向け、モデルが小さな弱点を連鎖させて実際に動くエクスプロイトを組み上げる様子を観察した経験が起点です。Taneja氏いわく、VVAHは当初Mythosのみを使っていました。「我々が設計し、自分たちで使っていた。クライアントゼロだった」。VVAHは現在もVisaのコードに対して稼働しています。

公開の広がりも早く、GitHubのスターは7月20日の595・フォーク97から、8月25日時点で2,300超・300超へ。クローン対訪問者比はTaneja氏によれば9%近く、実際に手を動かして試している層が厚いことを示唆します。一方でリポジトリは現在、外部からのコード貢献を受け付けていません。オープンソースではあるものの、貢献の流れは一方通行です。Visaは同日、VVAHをNvidiaのOpen Secure AI Allianceにモデル非依存フレームワークとして寄贈すること、IBMとRed Hatによる50億ドル規模のProject Lightwellに協力することも発表しました。加えて、Visa Consulting & Analytics のアドバイザリー実務を拡張し、経営層向けワークショップ、VVAHの知見を反映したNIST 1〜5段階の成熟度アセスメント、サイバーリスク優先順位付けの提供を追加します。

出典: VentureBeat

💼 事業会社視点:これは自社にどう効くか

日本企業でまず影響を受けるのは、受託開発とSaaSの2業態です。受託開発は「顧客のコードを預かって直す」立場上、VVAHの既定値が最も危険に働きます。11ステージがそのまま走れば顧客リポジトリの作業コピーに未承認のパッチが書き込まれ、契約上の変更管理を素通りします。導入するなら社内標準を「--stop-after s9 で検出まで、SARIF出力を読んでから書き込みを伴う実行を判断」に固定し、実行環境はエフェメラル・スコープ付き資格情報・本番シークレットなし・通信先は対象リポジトリとモデルエンドポイントのみ、と明文化すべきです。READMEはツールが昇格権限で動くこと、SDK・OpenAI・DeepAgentsバックエンド経由のロールはプロンプトデータを各社エンドポイントへ送ることを警告しています。顧客コードの外部送信は、機能検討ではなく契約とNDAの問題です。

SaaSとECは別の使い方が効きます。VVAHはCMDB・脅威モデル・事業リスクを取り込んで「どれから直すか」を優先順位付けする設計で、findingsで止まる既存ツールとの差はここにあります。決済や個人情報を扱う導線から順に潰す運用に落とせれば、少人数のセキュリティ体制でも効きます。

役員が今週やるべきことは3つです。第一に、Visaが言う3つの人間ゲート(実行前・パッチレビュー・マージ前)に実名の責任者を割り当てる。第二に、マージ前のエクスプロイト再テストを必須にする——ステージ11はリードオンリーで、ビルドもテストも走りません。第三に、MTTAをKPIに入れるなら3つある定義のどれを採るかを先に決める。VentureBeatのQ2 2026 Pulseでは59%の企業が1年以内にエージェントセキュリティツールの導入・乗り換えを計画し、82%は依然プロバイダ標準の統制を主軸にしています。多数派の82%側にいる企業ほど、既定値の意味を理解しないまま試すリスクが高い状況です。

関連リンク