AnthropicのMythosがセキュリティバグを大量に発見、Microsoftは対応に追われる

AnthropicのMythosが、Microsoftのエンジニアによる修正速度を上回る勢いで数百件のセキュリティバグを検出し、Microsoftは「対応に奔走」する事態となった。この問題はGoogle Newsの掲載を通じて表面化したが、元の報道が示しているのははるかに大きな課題だ。AIは現在、人間による修正対応の速度を超えて脆弱性の発見を加速させうる。

直接的な負担は、SharePoint、Microsoft 365、Teams、Copilotを担当するチームにかかった。ProPublicaが確認した社内記録によると、優先度の高い発見事項の多くは5月中旬時点で未解決のままだった。Mythosは複数の軽微な欠陥を深刻な攻撃経路へと結び付けられるため、従来のセキュリティトリアージは突然、信頼性が低く見えるようになった。

Mozillaは重要な比較対象となる。FirefoxチームにもMythosによる発見事項が急増したが、関連するすべてのパッチには依然として人間の作成者とレビュアーが必要だった。新たなボトルネックは、疑わしいコードを見つけることではない。各発見事項を検証し、文脈を理解し、安全な修正を実装・テストし、攻撃者が同じ作業を再現する前にリリースすることだ。

Microsoftの記録が実際に明らかにしたこと

Mythosは、脆弱性の発見を定期的なセキュリティ演習から継続的な本番キューへと変えた。

Microsoftの数十人のエンジニアと管理職は5月中旬、Anthropicによる管理されたサイバーセキュリティ施策であるProject Glasswingについて協議した。Anthropicは、同等の能力を持つシステムが広く利用可能になる前に、選定した組織へClaude Mythos Previewへのアクセスを提供していた。

Microsoftの社内記録によると、ある管理職は参加者に対し、MythosがMicrosoftの修正速度を上回ってバグを発見していると述べた。この管理職は対応を「対応に奔走」と表現した。

あるプレゼンテーションのスライドは、SharePoint内での規模を示していた。報道によれば、Mythosは4月だけで、重大に分類されたバグを90件、重要に分類されたバグを141件発見した。5月前半にも追加の問題を見つけたという。

これらの分類は重要だ。Microsoftは、自己伝播型の攻撃を含む深刻な結果を招きうる脆弱性を「重大」と位置付けている。「重要」な脆弱性は、ユーザーデータを侵害したり、コンピューティングリソースを妨害したりする可能性がある。

社内プレゼンテーションでは、SharePointのエンジニアが数か月にわたり対応に追われると予測されていた。チームは、まず重大な発見事項に対応し、その後に重要な発見事項、さらに後でおよそ300件の中程度の発見事項に取り組む計画だった。

記録には、Microsoft 365、Teams、Copilot全体で数百件の重大または重要なバグがあることも記されていた。報道によれば、その大半は5月中旬時点で未修正だった。Microsoftは、プレゼンテーション後に修正したMythosの発見事項の件数を明らかにしていない。

これらの発見事項は、必ずしも目新しく劇的な攻撃の種類ではなかった。エンジニアリングマネージャーは、多くが一般的ではあるものの実在する脆弱性だと表現したとされる。この点は、この出来事の重要性を下げるどころか、むしろ高めている。

ソフトウェア製品には、長年の機能開発、互換性に関する判断、継承されたコンポーネントを通じて、一般的な欠陥が蓄積する。人間のセキュリティ研究者がその全領域を調査する時間には限りがある。コードを継続的に調査できるモデルは、誰も発見に十分な注意を向けられなかったために隠れていた弱点を露呈させる。

Microsoftは、セキュリティ判断では悪用可能性と顧客への潜在的影響を考慮すると述べた。また、悪用の加速は新しい現象ではないとしつつ、強い切迫感を認めた。

両方の主張は成り立ちうる。セキュリティチームは、脆弱性が判明した後、常に攻撃者と競争してきた。変わったのは、同時に始まりうる競争の数だ。

Microsoftは、Mythosへのアクセスをおよそ50人のフルタイム従業員に配布していたと報じられている。この限定されたグループだけでも、製品チームを数か月にわたり拘束するほどのキューを生み出せた。より多くの研究者、顧客、敵対者が同等のツールを手にすれば、流入量は増大する。

だからこそ、この話題はGoogle Newsでの扱いが示唆する以上の注目に値する。Microsoftが直面しているのは、これまで知られていなかった悪用可能な脆弱性である単一の危険なゼロデイではない。巨大なコードベース全体で新たな候補を繰り返し発見できる本番システムに直面している。

そのシステムに休息、スケジュール上の空白、個人的な動機は必要ない。組織がコンピューティングリソースと効果的なテスト環境を提供する限り、探索を続けられる。

結果として、構造的な不一致が生じる。発見はソフトウェアのように拡張し始めた一方で、修正対応は依然として主に専門的な人間労働を通じてしか拡張できない。

Google Newsの注目度がセキュリティの変化を過小評価する理由

中心的な逆転現象は、防御側の検出能力が高まることで、ソフトウェアベンダーが一時的に安全性の低い存在に見えうることだ。

Anthropicは、同様の能力が広がる前に、選定した防御側に弱点を発見・修復する時間を与えるためProject Glasswingを導入した。Microsoftはこの取り組みに参加し、Microsoft Foundryを通じて承認済みのProject Glasswing顧客にMythosを提供した。

この取り決めにより、防御側は先行できた。しかし、モデルがチームの処理能力を超える速さで発見事項を生み出す場合、その先行の価値には限界がある。

従来のセキュリティプログラムでは、発見を希少な資源として扱う。組織はテストを実施し、外部からの報告を受け入れ、得られたキューを順位付けする。最も危険な脆弱性には即座に対応し、深刻度の低い発見事項は待機させる。

Claude Mythos Previewは、このプロセスの供給側を変えた。Anthropicの公開ダッシュボードでは、5月22日時点で候補となる発見事項が23,019件と報告されている。外部のセキュリティ企業がそのうち1,900件をレビューし、1,726件が有効であると確認した。

Anthropicは、281件のオープンソースプロジェクトにまたがる1,596件の脆弱性を開示していた。その時点で上流で修正済みと記載されていたのは97件にとどまった。Anthropicは、人間によるトリアージとレビューが処理速度を制約する要因であると明示している。

これらの数値は、Anthropicが追跡するオープンソースの作業を対象としており、Microsoftの非公開キューを対象とするものではない。それでも同じ仕組みを示している。モデルはある速度で候補を生成し、外部専門家は別の速度で検証し、保守担当者はさらに別の速度でパッチを適用する。

候補の発見事項が自動的に悪用可能な脆弱性になるわけではない。レビュアーは挙動を再現し、誤検知を除外し、現実的な攻撃条件を評価し、影響を受けるコードが到達可能かを判断しなければならない。

有効なバグであっても、プロジェクトの脅威モデルの範囲外にある場合がある。既知の報告と重複するものもある。AIが生成した洗練された説明があっても、エンジニアリング上の判断は不要にならない。

しかし、Mythosは単に、曖昧で低品質なAIレポートという見慣れた洪水を生み出しているわけではない。Anthropicの外部レビュー済みの発見事項では、報告された真陽性率は90.8%だった。この割合は、影響を受けるすべての保守担当者ではなく、Anthropicが雇ったセキュリティ企業によるものであるため、普遍的な証明として扱うべきではない。

それでも発見件数は、組織の行動を変えるのに十分な規模だ。セキュリティチームは、誤検知、重複、有意な被害につながらない問題と並行して、より多くの有効な報告に備えなければならない。

ベンダーが数十年にわたって蓄積されたコードを持つ製品を保守する場合、圧力は深刻化する。古いコンポーネントには、過去のアーキテクチャでは合理的だった前提が含まれていることが多い。現代的な機能は、それらの前提を新たな入力や攻撃経路にさらす可能性がある。

Microsoftの規模は問題を増幅させる。Windows、Microsoft 365、SharePoint、Teams、Azureは、政府、学校、病院、企業で利用されている。広く導入されたコンポーネントの欠陥は、攻撃者により大きな潜在的利益をもたらす。

普及度の高さは、防御側の作業負荷も増やす。エンジニアは、複数の製品バージョン、クラウド構成、アクセス制御、顧客環境を評価しなければならない。ある弱点をふさぐパッチが既存の導入環境を壊したり、別の脆弱性を作り出したりしてはならない。

バグを発見するAIでも、安全な本番環境向け修正を保証することはまだできない。もっともらしいコードを生成することと、すべての依存関係および運用上の影響を理解することは別物だ。

AIが数千件の欠陥を発見したというGoogle Newsの要約では、この違いが見落とされがちだ。見出しの数値が測るのは発見能力である。何件が悪用可能か、何件のパッチが安全か、顧客がそれらのパッチをどれほど速く導入するかを測るものではない。

したがってMicrosoftの対応に追われる状況は、成功と失敗を同時に反映している。Mythosは、防御側に以前は持ち得なかった可視性を与えている。その可視性は同時に、未解決のセキュリティ作業がすでにどれほど存在していたかも明らかにする。

小さなバグが攻撃チェーンを形成すると従来のトリアージは機能しなくなる

AIは、各脆弱性を孤立した項目として優先順位付けできるという前提に挑戦している。

セキュリティトリアージでは通常、想定される影響と悪用可能性に応じて発見事項を順位付けする。攻撃者に制御権を与えるリモートから悪用可能な欠陥は、影響範囲が限定的なローカルバグよりも優先されるべきだ。

この階層は依然として必要である。すべてのソフトウェア欠陥を即座に修正できる企業はない。Microsoftは、セキュリティ対応計画によると、毎年数千件の脆弱性報告を処理している。

複雑化させるのは、別々の弱点を組み合わせて一つの攻撃を成立させる手法である脆弱性チェーンだ。深刻度の低い情報漏えいが、アクセス制御エラーを悪用するために必要なデータを露出させる可能性がある。別の欠陥が、その後に攻撃者が制限された環境から脱出する助けとなる場合もある。

個別に見れば、これらのバグは許容可能に映るかもしれない。しかし組み合わさると、機密データやシステム制御に至る経路を生み出しうる。

Anthropicの上級技術顧問であり、Council on Foreign RelationsのフェローでもあるVinh Nguyenは、4つの低レベルの欠陥が組み合わさることで、高深刻度の結果につながる可能性があると警告した。彼は、Microsoftの既存のトリアージ戦略がこのリスクを過小評価している可能性があると主張した。

Microsoftは、チェーン化は長年にわたり脆弱性評価の一部を成してきたと応じた。この回答は、同社がその手法を理解しているかという点には答えている。しかし、急速に拡大するキュー全体でチェーンを評価できるだけの人員、モデル、修正プロセスを備えているかという疑問を完全には解消しない。

人間のレビュアーが、数百件の発見事項のあらゆる可能な関係を検討するのは難しい。キューが大きくなるにつれ、組み合わせの数は急速に増える。Mythosのようなシステムは、そうした組み合わせを繰り返し探索し、多段階の実証を構築できる。

このため、未修正の中程度の発見事項を軽視することはさらに難しくなる。個別の深刻度は中程度のままかもしれないが、別のバグが欠けていた段階を補うと、その価値は変わる。

この課題は、固定的な深刻度スコアの有効性も損なう。脆弱性の実際のリスクは、導入条件、利用可能な権限、到達可能なサービス、ほかの弱点との相互作用に左右される。

Microsoftは、下位に分類された問題を格上げすべきかを継続的に再評価していると述べた。AIがレビュー担当チームによる把握よりも速く新たな関係性を発見する場合、この適応的なアプローチは不可欠になる。

同社は、発見事項の品質と深刻度を検証するための自動化を追加している。また、エンジニアがコードを書く段階で脆弱性を検出できるよう、エージェントベースのセキュリティテストを開発プロセスに組み込む計画だ。

発見をより早い段階に移すのは理にかなっている。変更されたコンポーネントを理解している開発者であれば、数カ月後に遠隔地のインシデント対応チームが修復するよりも、効率的に対処できることが多い。早期テストは、パッチを必要とするリリース済みバージョンの数も減らす。

しかし、Mythosを開発工程に組み込んでも、既存ソフトウェアのバックログが消えるわけではない。Microsoftは、将来のバージョンを生み出すプロセスを変えつつ、現行製品も保護しなければならない。

また、誤った判断を自動化することも避けなければならない。すべての検出結果を過大評価するトリアージエージェントは、エンジニアリング能力を使い果たす。有用な攻撃チェーンのつながりを過小評価すれば、誤った安心感を生む。

組織には、再現可能な挙動、影響を受ける構成、現実的な攻撃の前提条件、提案される修正を含む、証拠に富んだ報告書が必要となる。また、各検出結果を設計判断、テスト、その後のインシデントに結び付ける、永続的な記録も必要だ。

エンジニアリングチームにとって、検索可能なナレッジベースは、コード、インシデントノート、技術文書にまたがる文脈を保持するのに役立つ。脆弱性の深刻度を判断することはできないが、過去の判断を再構築するための労力は減らせる。

したがって本当の競争は、Mythos対Microsoftのエンジニアではない。機械の速度による発見と、より遅く個別レビューされる報告書を中心に構築された組織システムとの競争だ。

Microsoftは、ほぼ即座にコンピューティング能力を追加購入できる。一方、レガシーコンポーネントを理解する経験豊富なエンジニアの層を厚くするには、はるかに長い時間がかかる。

Mozillaが示す、人間のエンジニアが依然として修正に必要な理由

Firefoxは、AIが有用な発見を増幅できても、修復で最も難しい部分は自動化できないことを示している。

Mozillaの経験は、エンジニアが利点と作業負荷の双方を説明しているため、最も明確な公開比較を提供している。

2026年4月、Firefoxは423件のバグ修正をリリースした。2025年4月の31件と比べて大幅な増加だ。Mythosは、ブラウザー内に10年以上残っていた欠陥を含む、高深刻度の脆弱性の発見に役立った。

このモデルは、悪意あるコードによる被害を限定することを目的とした隔離層であるFirefoxのサンドボックスで問題を発見したと報じられている。サンドボックス脆弱性は、悪用に創造的な一連の操作を必要とすることが多いため、特に価値が高い。

Mozillaのエンジニアは、Firefox security researchersに対し、最近のシステムは従来のAIスキャンツールから大幅に改善されたと語った。より優れたエージェントワークフローにより、候補となる検出結果をテストし、提出前に一部の弱い結果を除外できる可能性がある。

しかしMozillaは、AIが生成したパッチをそのままリリースすることは認めていなかった。該当する各バグでは、依然として1人のエンジニアが修正を書き、別のエンジニアがレビューする必要があった。

チームはAIにパッチの提案を求めたが、その出力は通常、出発点として使われた。人間の作業を置き換える、本番環境でそのまま使える成果物ではなかった。

この隔たりがMicrosoftのバックログを説明する。不審なコードパスを見つけることは、範囲が限定されたタスクだ。広く導入されたエンタープライズ製品を修復するには、より大きな責任の連鎖が求められる。

エンジニアは、正しいソフトウェアバージョンに対して報告を確認しなければならない。チームは、欠陥がクラウドサービス、ローカルインストール、あるいはその両方に影響するかを確立する必要がある。回帰テストを作成し、隣接するコンポーネントも調査しなければならない。

その後、パッチはレビュー、統合、品質テスト、リリース準備、顧客への通知を経る。顧客が保護策をインストールできるようになるまで、機微な詳細は管理された状態に保たれなければならない。

大手ベンダーには追加の制約がある。セキュリティ更新は、数え切れない環境で運用障害を引き起こす可能性がある。パッチを急げば、1つのセキュリティリスクを、障害、データ破損、互換性問題と引き換えにする恐れがある。

AIコーディングシステムは、複数の段階で支援できる。テストの提案、関連関数の特定、変更履歴の要約、修正案の比較が可能だ。しかし、こうした行為のどれも、説明責任をエンジニアから移すものではない。

Microsoft自身の過去の研究も、この限界を裏付けている。2025年の研究では、主要モデルが実際のソフトウェア問題から作られたベンチマークであるSWE-bench Liteの多くのタスクをデバッグするのに、依然として苦戦していることが示された。研究者は、修正案を出す前にエージェントがデバッガーをどう利用するかを示す、より豊富な対話データがモデルには必要だと主張した。

その研究以降、サイバー分野のモデルは急速に改善したが、検証はいまも中核にある。実環境には、ベンチマークでは十分に表現できない、文書化されていない挙動やビジネス上の制約が存在する。

競争環境も広がっている。OpenAIはサイバーセキュリティに特化したモデルを開発しており、Microsoftは、Windowsのネットワークおよび認証コンポーネントで16件の脆弱性を発見したマルチモデルのセキュリティシステムを説明している。

Palo Alto Networksは、AnthropicとOpenAIのモデルをテストする中で75件のバグを見つけたと報じられている。通常の月間範囲である5件から10件と比べて多い。同社の研究者は、環境チューニングで結果が改善する前は、製品全体で約30%の誤検知率を観測していた。

CurlのメンテナーであるDaniel Stenbergは、より控えめな結果を報告した。Mythosは低深刻度のバグを1件、複数の誤検知、そしてプロジェクトが重要ではないと判断した別の問題を見つけた。

これらの事例は、Mythosが常にあらゆる標的を圧倒するという単純な結論を退ける。性能は、コードベース、ツール、プロンプト、利用可能な文脈、そして人間のオペレーターに左右される。

またMicrosoftは、単一のオープンソースプロジェクトよりはるかに大きく、多様な製品領域を抱えている。SharePoint、Microsoft 365、Teams、Copilotにまたがる大量の検出結果は、複数の専門チームに同時に負荷をかけうる。

この不確実性は重要だ。Anthropicが公開パフォーマンスデータの多くを管理しているためである。独立したメンテナーやテストパートナーは価値ある証拠を提供しているが、ベンダー間で発見の品質、修復時間、本番環境での成果を測定する共通監査は、まだ存在しない。

Anthropicのダッシュボードには、すでに既知である可能性がある実際のバグや、メンテナーが修正しないと判断したバグも含まれる。同社の真陽性指標を、重大な公開アドバイザリーとなる検出結果の割合と混同すべきではない。

慎重な結論であっても重要だ。Mythosは、専門組織が人員配置やリリース計画を変えるほど十分に有用な検出結果を得る閾値を超えた。

ただし、モデルが自ら生み出したキューを安全に解消できる閾値には達していない。

リスクは単一のAIモデルではなく、修復能力にある

Microsoftの最大の脆弱性は、拡張可能な検出能力と希少な製品知識との隔たりにある。

明白な解釈では、Anthropicが挑戦者、Microsoftが圧倒される既存勢力として描かれる。この競争関係は重要だが、より広い制約から注意をそらす可能性がある。

Anthropicは、攻撃者が同等のアクセスを得る前に、Mythosが防御側による重要システムの保護を支援することを望んでいる。MicrosoftもFoundryを通じて承認済みアクセスをホストしている。AnthropicのモデルがMicrosoft製品の弱点を露呈させる一方で、両社は協力している。

主な対立は、AIの速度による防御という期待と、人間の速度による修復という現実との間にある。

経験豊富なセキュリティエンジニアは、欠陥コードを編集するだけではない。システム境界、脅威モデル、顧客の依存関係、リリースの影響を理解している。その知識の多くは、特定の製品やコンポーネントに固有だ。

レガシーコードは不足を深刻化させる。原著者がすでに去っているかもしれない。文書には設計上の前提が欠けているかもしれない。テストは通常の動作を対象としていても、敵対的な入力を表現していない可能性がある。

技術的負債、すなわち過去の妥協によって生じた蓄積済みのエンジニアリング作業は、その妥協が悪用可能な挙動を隠す場合、セキュリティ負債となる。AIは組織が返済できる速度よりもはるかに速く、その負債を明らかにできる。

Microsoftの社内Security Response Centerは歴史的に、繁忙期には数百件から数千件の報告を扱ってきた。ProPublicaは以前、人員不足への懸念を報じた一方、Microsoftはセキュリティ対応に必要なリソースを継続的に評価していると述べた。

ビジネス上のインセンティブは難しい。新機能は目に見える収益や顧客の関心を生み出せる。セキュリティ保守は通常、観測されることのない損失を防ぐ。

AIを活用した発見は、この不均衡を維持しにくくする。新機能はすべて、機械が検査できるコードを拡大する。先送りされたリファクタリングはすべて、将来のモデルが調査できる追加の相互作用を生む。

懸念はMicrosoftにとどまらない。ボランティアのメンテナーは、商用製品や公共インフラ全体に組み込まれたオープンソースライブラリを支えている。小規模なチームは、技術的に有効な報告を受け取っても、それを再現または修復する時間がないかもしれない。

責任ある開示は、公開詳細を遅らせることで役立つ。しかし、エンジニアリング能力を生み出すわけではない。開示期間は、資金不足のプロジェクトが満たせないカウントダウンになりうる。

Five Eyes warningは、高度なAI脆弱性能力が広がると述べ、組織に準備を促した。この警告の重要性は、特定の予測日よりも、進む方向にある。

攻撃者に必要なのは、正確に同じMythosサービスではない。コードを検査し、仮説を検証し、弱点を組み合わせるための、人間の労力を減らせるモデルとツールだ。

ソースコードへのアクセスは役立つが、常に必須ではない。攻撃者は、オープンソースコンポーネントを調べ、バイナリをリバースエンジニアリングし、過去に流出したコードを研究し、公開サービスをテストできる。

Microsoftは、そのセキュリティプロセスが、決意した敵対者がコードを入手できることを前提としていると述べた。この脅威モデルは適切だ。運用上の問題は、攻撃者が検出結果を信頼性の高い手法に変える前に、同社がそれらを修復できるかどうかである。

過剰反応のリスクもある。Microsoftが規律ある検証なしに、すべてのAI検出結果へエンジニアを振り向ければ、価値あるセキュリティ作業や製品保守を遅らせる可能性がある。

したがってチームに必要なのは、優先順位付けの放棄ではなく、より優れた優先順位付けだ。深刻度スコアには、攻撃チェーン、実際の展開上の露出、既知の悪用、代替的な緩和策の利用可能性を組み込まなければならない。

また、修復の処理能力も測定する必要がある。発見されたバグを数えると、キューを拡大したモデルに報いることになる。完了チケットを数えると、性急な分類に報いる可能性がある。有用な指標は、表面的なパッチを促すことなく、検証済みのリスク低減を反映しなければならない。

顧客への透明性も重要になる。購入者は、ベンダーが露出期間を短縮し、パッチ品質を改善し、再発する欠陥クラスを減らしているかを知る必要がある。大きな発見件数だけでは、進展も失敗も立証できない。

ニュースサイクルは次のモデル発表へ移るだろう。Microsoftのキューは、それを閉じるために必要な製品知識とテスト作業とともに残り続ける。

Googleニュースサイクルが過ぎ去った後に注目すべきこと

Microsoftがセキュリティシステムに適応しているのか、それとも最初のMythosの波をただ生き延びているだけなのかは、3つの兆候によって分かる。

最初の兆候は、報告されたSharePointバックログに対するMicrosoftのパッチ実績だ。社内計画では、重要な検出結果への対応が8月まで続き、中程度のバグはその後に続く、数カ月の作業が見込まれていた。

Microsoftは、セキュリティ更新をMythosの発見に結び付けた完全な件数を公表していない。今後のアドバイザリーによって、高優先度の検出結果が減少しているか、同じコンポーネントに関連する欠陥が再び現れるかが明らかになる可能性がある。

持続的な減少は、MicrosoftがAIによる発見と効果的な修復を組み合わせられるという同社の主張を裏付ける。継続的な蓄積は、発見能力が依然としてエンジニアリングの処理能力を上回っていることを示すだろう。

2つ目の兆候は、Microsoftが相互に関連する脆弱性の順位付けを変えるかどうかだ。同社は、連鎖がすでにリスク分析に反映されていると述べているが、Mythosは、ケースごとのレビューに挑戦する規模で組み合わせをテストできる。

新たな深刻度ガイダンス、自動化されたチェーン分析、または関連する脆弱性を攻撃経路としてまとめる報告に注目すべきだ。こうした変化は、MicrosoftがAIの実際の能力に合わせてトリアージを再設計していることを示すだろう。

下位に分類された検出結果が、関係性の分析が見えないまま待機し続けるなら、チェーンリスクが過小評価されているという懸念は残る。

3つ目のシグナルは、独立したテストにおける競合サイバーモデルの性能だ。OpenAI、Microsoft、Anthropic、セキュリティベンダー、政府系研究所はいずれも、脆弱性を見つけるシステムを開発または評価している。

複数のモデルで比較可能な結果が得られれば、Microsoftが直面しているのはAnthropicのあるプレビューに結び付いた一時的な急増ではなく、業界全体の能力転換であることが確認される。一方、偽陽性やエクスプロイト検証に大きな差があれば、運用設計がモデルの生の知能と同じくらい重要であることを示すだろう。

開発者は、ベンダーがエンドツーエンドの測定値を公開するか注視すべきだ。有用な報告には、候補となる検出結果、確認済みの脆弱性、受け入れられた深刻度、修正までの中央値、リグレッション、展開範囲が含まれる。

エンタープライズの購買担当者も、関連する問いを投げかけるべきだ。自社のサプライヤーは、自動化された発見を検証済みの顧客保護へと変えられるのか。より多くのバグを見つけても、安全にパッチを適用できないベンダーは、可視性を高めただけで、セキュリティの仕事を完了したことにはならない。

ナレッジワーカーとプロダクトリーダーにも役割がある。インシデント記録、アーキテクチャ上の判断、顧客の制約事項は、AIによる検出結果を評価するエンジニアが引き続き参照できなければならない。組織の記憶をより良くすれば、モデルのアラートから根拠ある修正までの時間を短縮できる。

次のgoogle newsの見出しは、おそらく脆弱性件数の増加や、より強力なモデルを強調するだろう。だが、より重要な結果は、目立たない運用データの中に現れる。

Microsoftはキューを減らし、パッチ品質を維持し、攻撃者より先に危険な組み合わせを特定できるのか。読者はこの3つのシグナルを追跡し、AIスピードの発見が、未解決リスクのリストをただ速く増やすだけではなく、AI支援による防御につながっていることを示す証拠を求めるべきだ。