※本ブログは、米国時間 5 月 12 日に公開された “Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark” の抄訳を基に掲載しています。
この記事の内容
- AI を活用した脆弱性検出をハイパースケールで実現
- コードネーム: MDASH — Microsoft Security の新たなマルチモデル エージェント型スキャン ハーネス
- セキュリティ研究におけるコードネーム「MDASH」の活用
- 2026 年 5 月 12 日の Patch Tuesday コホート
- 2 点の詳細解説
- コードネーム「MDASH」の性能はどの程度か?
- 本内容の意味するところ
- 結論
本日、マイクロソフトは AI を活用したサイバー防御における大きな前進を発表しました。当社の新たなエージェント型セキュリティ システムにより、Windows ネットワークおよび認証スタックにおいて、16 件の新たな脆弱性を発見しました。その中には、Windows カーネル の TCP/IP スタックや、IKEv2 サービスなどのコンポーネントにおける、4 件の Critical Remote Code 実行における脆弱性が含まれています。研究者は、マイクロソフトの Autonomous Code Security チームによって開発された新たな Microsoft Security の新たなマルチモデル エージェント型スキャン ハーネス (コードネーム: MDASH) を活用しました。単一モデルのアプローチとは異なり、この基盤は、最先端のモデルおよび蒸留モデルで構成される複数のモデル群を用いて、100 を超える特化型 AI エージェントを連携させることで、悪用可能な脆弱性の発見や、検証、証明までをエンドツーエンドで実行します。
明確な成果: プライベート テスト ドライバーにおいて、意図的に埋め込まれた 21 件の脆弱性のうち 21 件を検出し、誤検知はゼロを達成しました。さらに、clfs.sys における過去5年間の Microsoft Security Response Center (MSRC) で確認されたケースに対して 96%、tcpip.sys においては 100% の再現性を達成しました。また、1,507 件の実在する脆弱性を対象とした公開ベンチマーク「CyberGym」において、業界最高となる 88.45% のスコアを達成し、リーダーボードでトップスコアを獲得しました。このスコアは、次点と比較しておよそ 5 ポイント上回る結果となります。
戦略的な示唆は明確: AI による脆弱性の検出は、研究段階の取り組みから、エンタープライズ規模で実運用可能なレベルの防御へと進化しました。そして、持続的な優位性は、単一のモデルそのものではなく、モデルを取り巻くエージェント型システムにあります。コードネーム「MDASH」は、マイクロソフトのセキュリティ エンジニアリング チームによって活用されており、現在は限定的なプライベート プレビューとして、一部のお客様による検証も進められています。
本記事では、コードネーム「MDASH」の仕組みや、今回公開された内容、これまでの取り組みで得られた知見、さらにプライベート プレビューへの参加方法をご紹介します。
AI を活用した脆弱性検出をハイパースケールで実現
Microsoft Autonomous Code Security (ACS) チームは、AI を活用した脆弱性調査を、研究段階の取り組みから、エンタープライズ規模で実運用可能なエンジニアリングへと発展させることを目的に結成されました。このチームの一部メンバーは、複雑なオープンソース プロジェクトにおいて、実際にバグを発見して修正する、自律的なサイバー推論システムを構築することで、2,950 万ドル規模の DARPA AI Cyber Challenge で優勝した、Team Atlanta のメンバーです。こうした取り組みから得られた知見、特に最先端の言語モデルを、プロフェッショナル レベルのセキュリティ監査に対応させるために必要なエンジニアリングこそが、当社の新たなマルチモデル エージェント型スキャン ハーネス (コードネーム: MDASH) の基盤となっています。
マイクロソフトのコードベースは、いくつかの理由からセキュリティ監査の観点で課題があります:
- 大規模かつクローズドな領域。Windows、Hyper-V、Azure、およびそれらを取り巻くデバイス ドライバーやサービスのエコシステムは、いずれもマイクロソフト独自のコードベースであり、一般的な言語モデルの学習データには含まれていません。そのため、理解することが非常に難しいです。カーネルの呼び出し規約、IRP やロックの不変条件、IPC の信頼境界、コンポーネント内部のイディオムなどは、単純なパターン マッチでは把握できません。この領域において、モデルは実際に推論する能力が求められます。
- 大規模な DevSecOps。すべての検出結果には明確な担当者が存在し、トリアージ プロセスを経て、Patch Tuesday でのリリースに反映されます。不確かな検出結果を保留しておく余地はありません。ツールがノイズを出せば、それは組織全体の問題となります。
- 高価値なターゲット群。Windows、Hyper-V、Xbox、Azure は、数十億のユーザーに提供されています。そのため、単一の重大なバグを発見した際のインパクトは極めて大きい反面、基幹コンポーネントにおける誤検知がもたらすコストも非常に高くなります。
本記事で紹介する検出結果は、ACS、Microsoft Offensive Research & Security Engineering (MORSE)、および Microsoft Windows Attack Research and Protection の緊密な連携によって生み出されたものです。WARP と MORSE は、Windows の最も高度で困難な攻撃調査領域を担い、ACS は、AI を活用した検出および検証パイプラインを提供します。この両チームの協働により、成熟したスキャン ハーネスが構築されています。
コードネーム: MDASH — Microsoft Security の新たなマルチモデル エージェント型スキャン ハーネス
コードネーム「MDASH」は、その本質において、エージェント型の脆弱性検出および修復システムです。モデルは構成要素の一つに過ぎません。本質はシステムにあります。
有用な考え方としては、コードベースを受け取り、検証済みかつ実証済みの検出結果を出力する、構造化されたパイプラインとして捉えることです。
- 準備段階: ソース ターゲットを取り込み、言語対応のインデックスを構築した上で、過去のコミットを分析して、攻撃対象領域と脅威モデルを描き出します。
- スキャン段階: 候補となるコードパスに対して、専用の監査エージェントを実行して、仮説と根拠を伴う検出候補を出力します。
- 検証段階: 第 2 のエージェント群 (ディベーター) を実行して、各検出結果の到達可能性や悪用可能性について議論をさせます。
- 重複排除段階: 意味的に同等な検出結果を統合します (例: パッチベースのグルーピング)。
- 証明段階: バグの分類上可能な場合に、トリガーとなる入力を構築して実行します。証明段階では、前提条件を動的に検証し、脆弱性の存在を証明するためにバグトリガー入力を構築します (例: C/C++ における ASan)。
これを実運用で機能させている特性は 3 つあります:
- コードネーム「MDASH」によって効果的に管理される、多様なモデルのアンサンブルです。どの段階においても、単一のモデルが最適であるとは限りません。マルチモデル エージェント型スキャン ハーネスは、構成可能なモデル群を実行します。これには、高度な推論を行う SOTA モデル、大量処理における、コスト効率の高い検証を行う蒸留モデル、そして、独立した対立的視点として機能する、別の SOTA モデルが含まれます。モデル間の不一致そのものが、重要なシグナルになります。たとえば、監査エージェントが何か疑わしいものとしてフラグを立て、ディベーターがそれを否定できない場合、その検出結果の信頼性は高まります。
- 専門特化型エージェント。監査エージェントはディベーターのように推論せず、またディベーターは証明エージェントのように推論をしません。各パイプライン段階には、それぞれ固有の役割、プロンプト設計、ツール、および停止基準があります。1 つのプロンプトですべてを完結させ、1 つのエージェントが 1 回の処理でバグを認識し、検証して、悪用できると期待するわけでもありません。コードネーム「MDASH」には、過去の共通脆弱性識別子 (CVE) やその修正パッチに関する綿密な調査を通じて設計された 100 以上の専門エージェントが搭載されています。これらが独立して脆弱性を発見し、その監査結果は一つのレポートとして統合されます。
- 拡張可能なプラグインを備えたエンドツーエンドのパイプライン。このパイプラインは一定の設計思考に基づいていますが、閉じたものではありません。プラグインを使用することで、ドメインの専門家は、基盤モデルだけでは把握できないコンテキストを補完できます。たとえば、カーネルの呼び出し規約、IRP ルール、ロック不変条件、IPC 信頼境界、コーデック ステートマシンなどが該当します。後述の CLFS 証明プラグインはその一例であり、候補となる検出結果に基づいて、脆弱性を引き起こすログファイルを生成する仕組みを備えているドメイン プラグインです。たとえば、Windows チームではカスタム コード解析データベースを用いて推論を拡張しており、CodeQL データベースも活用できます。
このアーキテクチャの利点は、モデル世代を超えたポータビリティにあります。パイプラインのターゲティング、検証、重複排除、証明といった各段階は、構造上モデルに依存しないため、どのモデルが提供する最良の能力でも活用できる仕組みになっています。新たなモデルが導入された場合も、現行のパネルに対して A/B テストを行うのは、設定を 1 つ切り替えるだけです。また、モデルが改良された場合でも、スコープ ファイルやプラグイン、設定、キャリブレーションといったお客様の既存資産はすべて引き継がれるため、セキュリティ価値の最先端を享受し続けることができます。
セキュリティ研究におけるコードネーム「MDASH」の活用
マルチモデル エージェント型スキャン ハーネスのバグ検出能力を評価するためには、まずモデルがこれまで一度も見たことのないコードを基盤とする必要があります。これにより、モデルが「テストの答えを学習してしまった」といった可能性を排除することができます。今回私たちは、マイクロソフトにおけるオフェンシブ セキュリティ研究者の面接で使用されるサンプル デバイス ドライバーの StorageDrive をスキャンしました。このドライバーには、カーネルの use-after-free (UAF)、整数処理の問題、IOCTL の検証不備、ロックエラーを含む、意図的に埋め込まれた 21 の脆弱性が含まれています。StorageDrive は、これまで公開されたことがない非公開のコードベースであるため、現代の言語モデルのトレーニング データに含まれていないということが、安全に推測できます。
デフォルト設定で、StorageDrive に対してハーネスを実行しました。結果は驚くべきもので、21 件の真の脆弱性すべてが正しく特定され、この実行における誤検知はゼロでした。
この単純なテストは、コードネーム「MDASH」の推論および脆弱性検出能力が、プロのオフェンシブ研究者に近似することを示しています。
さらに、このハーネスを使用して Windows の中で最もセキュリティ上重要な部分となる TCP/IP ネットワーク スタックのセキュリティ監査を実施しました。
2026 年 5 月 12 日の Patch Tuesday コホート
Windows のネットワーク スタックおよび隣接するサービス全体において、今回の Patch Tuesday では、当社のエンジニアリング チームがコードネーム「MDASH」を使用して発見した、16 件の CVE が含まれています。
| コンポーネント | 説明 | CVE | 深刻度 | タイプ |
| tcpip.sys | SSRR IPv4 パケットによるリモート未認証 UAF | CVE-2026-33827 | 重大 | リモート コード実行 |
| tcpip.sys | 細工された IPv6 拡張ヘッダーによる NULL参照解除 | CVE-2026-40413 | 重要 | サービス拒否 (DoS) |
| tcpip.sys | ESP SA参照カウント アンダーフローによるカーネル DoS | CVE-2026-40405 | 重要 | サービス拒否 |
| ikeext.dll | 未認証の IKEv2 SA_INIT ダブル フリーによる LocalSystem RCE | CVE-2026-33824 | 重大 | リモート コード実行 |
| tcpip.sys | Ipv4pReassembleDatagram における Use-after-free による情報漏洩 | CVE-2026-40406 | 重要 | 情報漏洩 |
| tcpip.sys | 再構築による IPsec クロス SAフラグメントの結合 | CVE-2026-35422 | 重要 | セキュリティ機能のバイパス |
| tcpip.sys | 未認証のローカル Windows Filtering Platform (WFP) RPC による名前キャッシュの無効化 | CVE-2026-32209 | 重要 | セキュリティ機能のバイパス |
| ikeext.dll | メモリ リーク | CVE-2026-35424 | 重要 | サービス拒否 |
| telnet.exe | 不正な形式の TO_AUTH による FProcessSB での範囲外読み取り (OOB リード) | CVE-2026-35423 | 重要 | 情報漏洩 |
| tcpip.sys | IPv6+TCP MDL 分割パケットによる NULL参照解除のトリガー | CVE-2026-40414 | 重要 | サービス拒否 |
| tcpip.sys | ICMPv6 パケットによる NdisGetDataBuffer の NULL 参照解除のトリガー | CVE-2026-40401 | 重要 | サービス拒否 |
| tcpip.sys | SA の 二重デクリメントによる認証前のリモート UAF | CVE-2026-40415 | 重要 | リモート コード実行 |
| http.sys | 未認証のリモート QUIC コントロールストリームにおける範囲外読み取り (OOB リード) | CVE-2026-33096 | 重要 | サービス拒否 |
| tcpip.sys | RPC blob 経由のカーネル スタックバッファ オーバーフロー | CVE-2026-40399 | 重要 | 権限昇格 |
| netlogon.dll | 未認証の CLDAP User= フィルターによるスタック オーバーフロー | CVE-2026-41089 | 重大 | リモート コード実行 |
| dnsapi.dll | 細工された UDP DNS 応答によるヒープ範囲外アクセス (OOB) のトリガー | CVE-2026-41096 | 重大 | リモート コード実行 |
これらの脆弱性は、カーネルモードが 10 件、ユーザーモードが 6 件となっています。その大半は、認証情報なしでネットワーク上の位置から到達可能です。それでは、詳しく見ていきましょう。
2 点の詳細解説
以下の 2 つの検出結果は、単一モデルのハーネスでは実現できない、新たな Microsoft Security のマルチモデル エージェント型スキャン ハーネス パイプラインの能力を象徴するものです。1 つ目は、カーネルのレースコンディション型 use-after-free であり、非自明な制御フローと、3 つの独立した並行解放パスをまたいで、オブジェクトのライフタイムを推論する必要があります。2 つ目は、6 つのソース ファイルにまたがるエイリアス・エイリアシング型のダブル フリーであり、同一コード ベース内の別の箇所で正しく処理されている実装との対比によってのみ可視化されるものです。
CVE-2026-33827 — SSRR 経由の tcpip.sys におけるリモート未認証の UAF
この脆弱性は、Ipv4pReceiveRoutingHeader 内の参照カウント付き Path オブジェクトのライフタイム管理が不適切であることに起因して、Windows の IPv4 受信パス内で発生します。ルーティング検索を呼び出した後、この関数は参照解除操作を通じて Path への唯一の所有参照を解放しますが、その後、Strict Source and Record Route (SSRR) の処理において、同じポインタを再利用します。オブジェクトの参照カウントが先の解放時点でゼロになる可能性があるため、基盤となるメモリはプロセッサごとのルックアサイド アロケータに返却され、その後再利用される可能性があります。これにより、後続のアクセスがカーネル コンテキストにおける典型的な use-after-free となります。
これは、攻撃者が制御するパケット メタデータを処理するネットワーク経路上で発生し、ネットワーク スタック内の高い IRQL で到達可能となります。根本的な問題としては、パス キャッシュおよび関連するクリーンアップ ルーチンの並行処理モデルによってさらに深刻化します。呼び出し元が所有権を放棄すると、Path オブジェクトの存続は、共有データ構造によって保持される外部参照に完全に依存します。パス キャッシュのスカベンジャー、明示的なフラッシュ ルーチン、インターフェースの状態駆動型ガベージ コレクションなど、複数の独立したサブシステムが並行してオブジェクトを削除し、最終参照を解放する可能性があります。これらの処理は、この関数内の受信側実行ウィンドウと同期されておらず、アクセスをシリアル化するためのロックも保持されていません。その結果、SMP システム上では、その後の参照解除より前に解放されたオブジェクトが再利用され、上書きされる可能性があり、単純な順序付けバグが実際に実行可能な競合状態による use-after-free へと変化します。
悪用の観点から見ると、この脆弱性は、標準的な検証チェックを通過する SSRR オプションを含む細工された IPv4 パケットを通じて、リモートでの未認証の攻撃者によって到達が可能です。古いポインタの参照解除は、解放済みメモリを介したアクセスの連鎖を引き起こし、再割り当てされた領域が攻撃者の影響下にある場合には、制御された読み取りや、より強力な破壊プリミティブにつながる可能性があります。実行には限られたタイミング ウィンドウを捉え、アロケータの再利用を制御する必要がありますが、リモートからの到達可能性、カーネル実行コンテキスト、および制御されたメモリ操作の可能性が組み合わさることで、この問題は Critical レベルの深刻度に引き上げられます。
単一モデルシステムがこのバグを見逃した理由
単一モデルのハーネスでは、このバグを見逃しがちです。なぜなら、ライフタイム違反が同じ関数内であっても局所的に可視化されないためです。Path 参照の解放とその後の再利用は、代替分岐、複数の検証チェック、および複数の早期ドロップ条件といった非自明な制御フローによって分断されており、ほとんどの検出器が依存している単純な「解放してから使用する」というパターンを崩しています。これらの中間状態をまたいで参照の所有権を追跡しなければ、モデルはこれを時間的な依存関係としてではなく、2 つの独立した操作と捉えてしまいます。その結果、参照カウントのセマンティクス上で、ポインタがすでに無効になっている可能性があるにもかかわらず、参照解除自体はそれ単体では疑わしく見えません。
決定的なシグナルもまた、直近のコンテキストの外側に存在します。同じ論理操作が別の箇所では正しい順序で実装されており、必要なすべてのデータは参照を破棄する前に、オブジェクトから取得されています。このため、この呼び出し箇所は明らかな誤用ではなく、一貫性の欠如として扱われます。
これを検出するには、ファイル横断的な推論が必要です。つまり、類似したパターンを特定し、その意図を照合して、逸脱に気づく必要があります。さらに、到達可能性は複数の条件の組み合わせに依存します。具体的には、SSRR フラグを設定する入力、そのパスを許可するデフォルト設定、そして露出しているウィンドウの間にオブジェクトを回収できる並行サブシステムなどです。単発の分析ではこれらのステップが簡略化され、それらの相互作用が失われてしまいますが、段階的なアプローチであれば、所有権の違反、並行処理モデル、および外部制御によるトリガーを、首尾一貫した悪用経路として結びつけることができます。
開示情報。CVE-2026-33827、4月の Patch Tuesday で修正済み。
CVE-2026-33824: 未検証の IKEv2 SA_INIT + フラグメンテーション → ダブル フリー → LocalSystem RCE
この脆弱性は、IPsec の IKE および AuthIP キー生成を担う Windows コンポーネントである IKEEXT サービスに存在し、IKEv2 レスポンダーとして構成された任意のホスト (RRAS VPN、DirectAccess、Always-On VPN インフラストラクチャ、またはインバウンド接続セキュリティ ルールを持つ任意のマシン) に対し、UDP/500 経由でリモートの未認証攻撃者がアクセス可能でした。マイクロソフトの「IPsec Security Realm Id」ベンダー ID ペイロードを搭載した細工された IKE_SA_INIT を送信し、続いて即座に再構成される単一の IKEv2 フラグメント (RFC 7383 SKF) を送信することで、攻撃者はサービス内部の 16 バイトのヒープ割り当てに対する決定的なダブル フリーを引き起こすことが可能でした。
IKEEXT は svchost.exe 内で LocalSystem として実行されるため、これはシステム上で最も高い特権を持つコンテキストの 1 つへの、事前認証のリモート コード実行経路を意味します。根本原因は、典型的な所有権のバグです。IKEEXT が再構成されたフラグメントを受信パイプラインを通じて再注入する際、フラットな memcpy でパケットの受信コンテキストを複製します。これはシャロー コピーで、構造体のバイトは複製されますが、ヒープ割り当ては複製されません。それらの割り当ての 1 つが、攻撃者が提供したセキュリティ レルム識別子であり、コピー後は、キュー内のコンテキストとアクティブな Main Mode SA の両方が同じポインタを保持し、かつ両方がそれを所有していると認識します。
接続の切断時にそれぞれがこれを解放するため、ダブル フリーが発生します。トリガーとなるシーケンスは 2つの UDP パケットであり、レースや特別なタイミングは不要です。IKEEXT サービスは svchost.exe 内で LocalSystem として実行されます。固定サイズのヒープ チャンクのダブル フリーは、現代の Windows においてよく知られた破壊プリミティブで、弊社はこれ以上の悪用詳細については公開しません。到達可能性としては、ホストが提案されたトランスフォームを受け入れる IKEv2 レスポンダー ポリシーを持っている必要があります―このバグは、一般的な構成での RRAS VPN、DirectAccess、Always-On VPN、および IPsec 接続セキュリティ ルールにおいて到達可能ですが、レスポンダー ポリシーを持たない単純な Start-Service IKEEXT においては脆弱ではありません。IKEEXT サービスは、デフォルトで DEMAND_START となります。レスポンダー ポリシーが存在する場合、BFE は最初の着信 IKE パケットを受けて、これを起動するため、攻撃者は IKEEXT がすでに実行中である必要はありません。
単一モデルシステムがこのバグを見逃した理由
このバグは、6 つのファイルにまたがるエイリアシング ライフサイクル バグです: ike_A.c (不正なmemcpy)、ike_B.c (エイリアスの発生源および最初のスタック ローカル コピー)、 ike_C.c (誤った free)、ike_D.c (正しいパターンと 2 回目の free の両方)、ike_E.c (バッファがリモートで初期化される箇所)、および ike_F.c (IKEv2 ディスパッチャと、2 回目の free に先行する UAF 読み取り箇所) です。単一ファイル単位の分析ではこれを検出できません。このバグが実在する最も有力な証拠は、同一コードベース内の ike_D.c における同一パターンの正しいバージョンです。これは、セレクタの memcpy の直後に存在します。これを検出するためには、監査担当者が、ある箇所で欠落しているステップを、別の箇所にある現在のステップを参照して認識する必要があります。当社の専門監査エージェントは、まさにこのような比較を明らかにするように設計されています。ディベート段階では、エージェントが反対尋問に耐えることが求められます。
開示情報。CVE-2026-33824、4 月の Patch Tuesday で修正済み。
コードネーム「MDASH」の性能はどの程度か?
Patch Tuesday コホートと StorageDrive は、将来を見据えたシグナルです。2 つの遡及的ベンチマークによって、実際に十分にレビューされたコードにおいて、システムがグラウンド トゥルースに対して、どのようなパフォーマンスを発揮するかが分かります。
過去の MSRC 事例における再現率。厳格にレビューされた 2 つの Windows コンポーネントのパッチ適用前のスナップショットに対してコードネーム「MDASH」を再実行し、過去に MSRC が確認したバグが (再) 発見されていたかどうかを測定しました:
- clfs.sys: 5年間にわたる 28 件の MSRC 事例に対して 96% の再現率。
- tcpip.sys: 5年間にわたる 7 件の MSRC 事例に対して 100% の再現率。
これらは当社が公表する最も信頼性の高い内部指標であり、特定の理由から非常に意義深いものです。MSRC 事例のデータベースは、実際の攻撃者が何を悪用したか、何が Patch Tuesday を必要としたのか、そして防御側が何に対応しなければならなかったのかを示すグラウンド トゥルースです。厳格にレビューされたカーネル コンポーネントにおける5年分の MSRC バックログの 96% を回収できるシステムは、理論上の弱点を見つけ出しているのではなく、重要であったバグを見つけ出しているのです。
私たちは、これらの数値が何を主張し、何を主張しないかについて慎重に検討しています。これらは、内部コードに対する有限の事例数に基づく遡及的な再現率ベンチマークです。これらは、その当時にこのシステムが存在していたならば、有用であったであろうことを示しています。これらだけでは CLFS における次の 38 件のバグが同じ割合で発見されると予測するものではありません。将来を見据えたシグナルは、Patch Tuesday コホートそのものです。
実例としての CLFS 証明拡張。96% という CLFS 再現率の値は、部分的には証明段階についての話でもあります。多くの CLFS の検出結果は、トリガーとなるログ ファイルを構築しようとするまでは興味深く見えますが、証明のない候補検出は、実際にはトリアージ バックログ上のエントリに過ぎません。私たちが作成した CLFS 専用の証明プラグインは、候補となる検出が与えられれば、トリガーとなるログを構築する方法を理解しています。これはディスク上のコンテナ レイアウト、ブロック検証シーケンス、およびメモリ内のステート マシンを十分に理解しており、候補となるパスをそのシンクまで導くことができます。これこそがプラグインの拡張性の目的です。基盤モデルは、マイクロソフト固有のファイル システム不変条件を内部化することは想定されておらず、またそう期待されるべきでもありません。プラグインがそれらを組み込み、モデルがそれを利用することで、結果として、単にファイルされて忘れ去られるようなバグではなく、証明の過程を生き残るバグが発見されるのです。
CyberGym。公開されている CyberGym ベンチマーク (188 OSS-Fuzz プロジェクトから抽出された 1,507 件の実世界における脆弱性再現タスクのコーパス) において、Microsoft Security マルチモデル エージェント型スキャン ハーネスは、88.45% の成功率を達成しました。これは執筆時点で CyberGym の公開リーダーボードにおける最高スコアであり、次点の 83.1% を約 5 ポイント上回っています。この結果は、一般提供されているモデルを使用して得られたものです。この優れた結果は、周囲のエージェント型システムが、モデルの素の能力を超えて、エンドツーエンドのパフォーマンスに実質的に寄与していることを示唆しています。評価においては、脆弱なソースコードと、高レベルの脆弱性の説明を提供する CyberGym のデフォルト設定 (レベル 1) を使用しました。CyberGym の評価プロトコルとの接続のために、ハーネスの証明段階を拡張して、概念実証 (PoC) 入力を自律的に送信し、フラグ取得を可能にしました。
残りの約 12% の失敗に関する分析から、2 つの注目すべき構造的パターンが明らかになりました。誤ったコード領域を対象とした検出結果のうち、82％ は関数やファイル識別子も欠いている曖昧な記述を伴うタスクに由来しており、説明の品質がスキャン精度の主要な要因であることを示唆しています。また、エージェントが libFuzzer 形式の入力を構築したものの、ベンチマーク タスクが実際には honggfuzz 形式の入力を要求していた事例も確認されており、それ以外は健全な再現が、ハーネス形式の不一致によって失敗する結果となりました。
本内容の意味するところ
業界は現在、AI を活用した脆弱性検出が推測の域を脱し、エンジニアリング上の課題となっています。今回の Patch Tuesday における検出結果や、過去 5 年間にわたる CLFS MSRC 事例に対する遡及的再現率は、AI による脆弱性検出がスケール可能であることを示す証拠です。
MDASH を構築し、マイクロソフト全体での使用を通じて学んだことは、より汎用的なものです。ハーネスが作業を行い、モデルはその入力の 1 つに過ぎません。
これは、3 つの具体的な点で重要になります。
第一に、脆弱性の検出には、単一のプロンプトでは達成できないような構成が必要です。本記事で取り上げたバグ (tcpip.sys のレースや ikeext.dll エイリアス チェーン) は、単一の関数だけを与えられたモデルには見えません。これらは、ファイル横断的なパターン比較、多段階の到達可能性分析、専門エージェント間でのディベート、そしてエンドツーエンドの証明構築を順序立てて実行できるシステムに見えるものです。単一モデルのハーネスは、モデルの能力を過小評価し、過度に信頼された単一のエージェントは、モデルが確実に実行できる範囲を超えてしまいます。重要なのは、モデルを取り巻くハーネスにあり、そのハーネスがエンジニアリングの大部分を占めます。
第二に、検証とは検出と修正を分けるものです。候補となるバグをフラグ付けするスキャナーは、トリアージのバックログを生み出すスキャナーです。Patch Tuesday コホートがこの成果を上げているのは、それを生み出したシステムが候補で止まらず、議論して、重複を排除し、証明まで実行しているためです。検証はチェック項目ではありません。それ自体がエージェントとプラグインからなる独自のパイプラインであり、日々のエンジニアリングの大部分が、最終的に集約される場所なのです。
第三に、このシステムはモデルの改善を取り込むため、それが持続性をもたらしています。新たなモデルが導入された場合でも、ターゲティング、議論、重複排除、証明の各段階を書き直す必要はありません。設定を変更し、A/B テストを再実行するだけで済みます。お客様の投資—プロジェクトごとのコンテキスト、スキャン プラグイン、証明エージェント—は引き継がれます。これは時間の経過とともに、最も重要となるアーキテクチャ上の特性です。というのも、モデルの当たり外れは今後も続くものであり、特定のモデルに価値が依存しているシステムは、6 か月ごとに再構築が必要になるからです。
防御側にとって―規模の大小や所有するコードの種類を問わず―その意味するところは同じです。AI 脆弱性ツールに対して問うべき正しい質問は、どのモデルを使用しているか? ではなく、そのモデルで何を行うのか、そして次のモデルが登場した際に、何が生き残るのか? です。
結論
Microsoft Security のマルチモデル エージェント型スキャン ハーネス (コードネーム: MDASH) は、一般提供されている AI モデルを活用して、当社のエンジニアリング チームのセキュリティ成果を実質的に向上させることに役立っています―現時点において。また、限定的なプライベート プレビューの一環として、お客様によるテストも実施されています。プライベート プレビューに参加するには、こちらから登録してください。
本記事の検出結果をもたらしてくれた Autonomous Code Security チーム、Microsoft Offensive Research and Security Engineering (MORSE)、および Microsoft Windows Attack Research and Protection (WARP) をはじめ、お客様のセキュリティ向上に取り組むマイクロソフトの各チームに深く感謝いたします。
私たちは、すべての人にとってより安全な世界の実現に向けて取り組みを進める中で、お客様や業界の皆様にさらなる最新情報をお届けできることを楽しみにしています。
