Amazon・Googleのセキュリティ推進策、AIバグをめぐる現実に直面

Amazon・Googleのセキュリティパートナーは、切迫した警告を軸にしたAI防衛競争に加わった。しかし、調査対象となった脆弱性のうち、実際の攻撃で悪用されたのはわずか1.3％だった。

この数値は、VulnCheckがAI支援によって発見されたと公に帰属された1,061件を分析した結果によるものだ。研究者らはこれらの発見を、管理された環境外で観測された攻撃の証拠と照合した。

この結果は、AnthropicのProject GlasswingをめぐるAmazon・Googleのセキュリティ施策を支える中心的な前提に疑問を投げかける。AIは脆弱性を迅速に発見できるが、発見そのものが効果的な攻撃を自動的に生み出すわけではない。

それでもAnthropicは、緊急性を示す深刻な根拠を提示している。同社のClaude Mythos Previewシステムは、オープンソースプロジェクトをスキャンして23,019件の脆弱性候補を特定した。同社はこのうち6,202件が高深刻度または重大深刻度に値すると見積もっている。

こうした膨大な件数は、AIが生成するエクスプロイトの洪水が迫っているとの予測を形作ってきた。だが、現時点で公開記録が示している移行は異なるものだ。

AIは、人間が検証、開示、修正、優先順位付けを行う速度を上回って、潜在的なセキュリティ上の発見を増幅している。攻撃者にはなお、技術的な弱点を信頼性のある作戦へ転換するという、より困難な仕事が残されている。

この違いは、防御側が注力すべき場所を変える。差し迫った問題は、単にAIがより多くのバグを見つけることではない。セキュリティチームが、重大な露出と、拡大する機械生成の証拠量とを切り分けなければならないことだ。

悪用データが物語を変える

AI支援による発見は脆弱性の件数を増やしたが、観測された悪用率を高めてはいない。

VulnCheckは、Project GlasswingとBerkeley Vulnerability Research Initiativeに帰属する1,061件の脆弱性を調査した。その後、同社のKnown Exploited Vulnerabilitiesデータベースと比較した。

同社は、実環境での悪用が確認された脆弱性を14件見つけた。公開された悪用分析によれば、これは調査対象グループの1.3％に相当する。

VulnCheckによると、この割合は同社のより広範な脆弱性データセット全体の割合とほぼ同一だった。したがってAIが見つけた脆弱性は、従来の手法で発見された脆弱性よりも悪用されやすいとは見られなかった。

この比較が重要なのは、脆弱性の発見と悪用が異なる能力を測るためだ。スキャナーは、想定されるセキュリティ境界に違反する可能性があるコードの振る舞いを特定する。

実用的なエクスプロイトは、その振る舞いを現実的な条件下で引き起こさなければならない。多くの場合、緩和策を回避し、価値の高いシステムに到達し、標的ごとの構成差をまたいで確実に動作する必要がある。

実際の攻撃者は経済性も評価する。アクセス手段、開発時間、露見リスク、利用可能な標的、そして取得できるデータや制御の価値を考慮する。

多くの脆弱性はこの基準を満たさない。ローカルアクセス、特殊な構成、あるいは攻撃者がすでに必要とする権限を要求するものもある。役立つ制御を可能にせず、クラッシュを引き起こすだけのものもある。

脆弱性は技術的に有効なままでも、作戦上の価値がほとんどない場合がある。深刻度スコアだけでは、犯罪者がその武器化に投資するかどうかを説明できない。

Project Glasswingでは、この区別が特に重要になる。Anthropicによると、Mythos Previewは1,000件を超えるオープンソースプロジェクトで23,019件の候補を生成した。

VulnCheckが調査した公開データでは、Project Glasswingの発見のうち、公開済みのCommon Vulnerabilities and Exposuresレコードになったものは126件にとどまった。実環境での悪用が確認されたものは、わずか1件だった。

このより限定的な比較は、残る候補が無害であることを証明するものではない。協調開示では、ソフトウェア保守者がパッチを配布できるようになるまで、一部の詳細を意図的に非公開にする。

ただし、候補件数は検証済みの脆弱性成果の代替にはなり得ないことを示している。まして、どれだけの発見が信頼できる攻撃ツールになったかを測ることはできない。

VulnCheckの研究者Patrick Garrityは、現時点での影響は現実のものだが限定的だと説明した。AIが発見した脆弱性は、従来の手法で見つかったものより本質的に悪用しやすいわけではないと論じている。

この結果は、重要な分母の問題も浮き彫りにする。Project Glasswingの候補総数には、最高評価の発見に加え、中深刻度および低深刻度の問題も含まれる。

公開CVE件数は、より後段の段階を表す。こうしたレコードには一般に、検証、調整、影響を受ける製品と弱点を説明するための十分な技術的明確さが求められる。

既知の悪用には、さらに高い基準が課される。誰かが実際の標的に対して脆弱性を使用したという信頼できる証拠が必要だ。

こうした段階を但し書きなしに比較すれば、誤解を招く結論になる。各段階が異なる証拠をふるいにかけるため、大規模な候補プールと極めて少ない悪用件数は共存し得る。

したがって1.3％という割合は、安全宣言ではなく現実確認である。AIは、発見の供給を変革した一方で、その平均的な作戦価値を変革するには至っていないことを示している。

Amazon・Googleのセキュリティパートナーには、依然として迅速に動く理由がある

観測された悪用率が低いからといって、Amazon・Googleのセキュリティチームや他のProject Glasswingパートナーが直面する危険がなくなるわけではない。

Anthropicは、選定された防御側にClaude Mythos Previewへの早期アクセスを提供するため、Project Glasswingを導入した。初期参加者にはAmazon Web Services、Google、Apple、Microsoft、Cisco、Nvidia、その他のインフラプロバイダーが含まれていた。

このプロジェクトは約50のパートナーで始まった。Anthropicは後に、15か国以上の約150の追加組織へアクセスを拡大すると述べた。

参加者は、同等の能力が広く利用可能になる前に、Mythos Previewを使って社内コードやオープンソースコードを調査する。Anthropicはこれを非対称な防御上の優位性と呼んでいる。

同社の懸念は明快だ。AIシステムは、人間の研究チームが手作業で調べられるよりもはるかに多くのコードパスを検査できる。

将来の攻撃者は、協調開示のルールに従うことなく同じ規模を利用できる可能性がある。また、明確な商業的標的を持つインターネット接続型ソフトウェアにスキャンを集中させることもできる。

現在の悪用率が示すのは公開された証拠であり、すべての非公開活動ではない。犯罪グループが成功したゼロデイ作戦を確実に公表したり、技術的手法を公開したりするとは限らない。

そのため、確認済み悪用件数は一部の活動を過小評価することになる。修正対応中に発見が機密扱いとなる場合、その不確実性はさらに大きくなる。

最近の事例は、AI支援の攻撃的作業がもはやベンチマークだけに閉じ込められていないことを示している。Googleは、未知のソフトウェア脆弱性を特定する際にAIモデルを使用したとみられる犯罪者を妨害したと報告した。

防御側が介入したため、この作戦による被害は報告されていない。しかしこの事例は、犯罪者が実際の脆弱性ワークフローの中でAIを試していた証拠を提供した。

実験と大規模な悪用の間には、依然として大きな隔たりがある。検出された1件の作戦だけで、攻撃者がプロセス全体を自動化できることは示されない。

それでも防御側は、悪用統計が上昇するまで準備を待つことはできない。公開確認は通常、侵入、フォレンジック調査、またはベンダーによる開示の後に行われる。

Amazonは、別の運用面から同じ問題に取り組んでいる。同社のRuleForgeシステムは、脆弱性情報と概念実証コードを検知ルールへ変換する。

Amazonによると、このシステムはルール生成の生産性を336％向上させた。別の評価器は、真陽性の検知を維持しながら偽陽性を67％削減した。

これらの主張は独立したベンチマークではなく、Amazon自身のRuleForgeの結果に基づくものだ。それでもこのアーキテクチャは、防御側が発見以外にもAIを活用する方法を示している。

RuleForgeは、取り込み、生成、評価、検証を担当する専門エージェントに作業を分割する。導入前のルール承認については、人間のレビュアーが責任を保持する。

このワークフローは、開示された脆弱性と運用可能な防御の間にある、欠けがちな中間部分を対象としている。バグを見つけても、テレメトリー、検知、パッチ、導入ガイダンスが自動的に生まれるわけではない。

Googleは、CodeMenderとGemini 3.5 Flash Cyberを通じて、より迅速な発見と修正を進めている。この特化モデルは、大規模なコードベース全体で脆弱性を発見、検証、修正するよう設計されている。

Googleによると、このモデルはV8評価で55件の固有の確認済み問題を発見した。報告された設定では、主系統のGeminiは47件、Claude Opus 4.6は36件を発見した。

モデル構成や安全ポリシーは異なるため、プロバイダーのベンチマークには注意が必要だ。Googleも、競合他社の結果の一部は自己申告であると指摘している。

それでも方向性は明らかだ。大手テクノロジー企業は、スキャンを検証と修復につなげるシステムを構築している。

1.3％という悪用率は、こうした投資を無効にするものではない。その根拠を、バグの件数から、信頼できる証拠と展開済みの防御との間の時間を短縮することへ移すものだ。

発見は安価になったが、悪用は依然として連鎖である

中心的な変化は、AIが発見のボトルネックを弱めた一方で、悪用のボトルネックを解消していないことだ。

現代のコードベースには、数百万行のコード、外部依存関係、古いインターフェース、文書化されていない前提が含まれる。AIエージェントはこの探索空間を分割し、多くの仮説を並行して検証できる。

Anthropicは、独立系セキュリティ企業が同社のオープンソーススキャンから得られた高深刻度または重大深刻度の候補1,752件を評価したと報告した。このうち1,587件は有効な真陽性だった。

この90.6％の検証率は、レビュー対象の部分集合において、システムが単なるランダムノイズ以上のものを生み出したことを示唆する。レビュアーは1,094件を高深刻度または重大深刻度と確認した。

これらの結果はAnthropicの発見に関する主張を裏付ける。しかし、未レビューの残りの候補すべてが同じ割合で専門家の分析を通過することを示すものではない。

また、確認済みの脆弱性が攻撃者にとって同等に有用であることも示していない。悪用は、より長く予測しにくい連鎖に依存する。

まず、攻撃者は脆弱なコンポーネントを理解し、到達可能な標的がそれを使用しているかを判断しなければならない。影響を受けるコードパスが無効のままであれば、ライブラリの脆弱性に価値はほとんどない。

次に、攻撃者は必要な入力を制御しなければならない。公開リクエスト経由で到達可能になるバグもあれば、認証やローカル実行を必要とするものもある。

第三に、悪用は価値のある効果を生み出さなければならない。サービスをクラッシュさせることと、コードを実行すること、認証情報を盗むこと、信頼境界を越えることは大きく異なる。

第四に、エクスプロイトはソフトウェアのバージョンやデプロイ設定の違いに耐えなければならない。不安定な手法は、有用なアクセスを得る前に攻撃者を露見させる可能性がある。

最後に、攻撃者はエクスプロイトを作戦に組み込まなければならない。そのためには、インフラ、標的選定、永続化、権限昇格、証拠を消す手法が必要になる。

AIはあらゆる段階を支援できるが、支援は自律性と同義ではない。モデルはもっともらしいコードを生成しても、環境の詳細が変わると失敗する場合がある。

モデルは確信度の較正にも苦労する。Amazonは、別の判定器が出力を評価するまで、同社のルール生成モデルがほぼすべての候補を好意的に評価していたことを確認した。

同じ傾向は脆弱性研究にも影響する。モデルは、本番環境ではその経路を不可能にする条件を見落としたまま、警戒すべき経路を説明することがある。

Anthropicは、独立した検証を通じてその弱点に対処しようとした。同社が報告した真陽性率は、慎重に設計されたツールと専門家によるレビューによって、大量のノイズを制御できることを示している。

しかし、このレビューは新たなキャパシティ制約を生む。重大な発見ごとに、再現、影響分析、メンテナーとの連絡、修正、そしてデプロイ前のテストが必要になる。

Anthropicによると、重大度が高い、またはクリティカルなMythosの発見は、パッチ適用まで平均で2週間かかる。一部のメンテナーは、レビュー能力が十分でないとして、同社に開示ペースを落とすよう求めた。

ここでセキュリティ上の負担は移る。機械による発見はキューを増やすが、そのキューをどれだけ早く安全なソフトウェアへと変えられるかは、依然として人間の組織に委ねられている。

オープンソースプロジェクトは最も深刻な不均衡に直面している。広く使われるパッケージであっても、複雑な非公開レポートを数百件処理できない小規模チームに依存していることが多い。

エンタープライズチームは、自社リポジトリをより適切に管理できる。Anthropicによると、Claude Securityの利用者は製品リリース後の最初の3週間で2,100件以上の脆弱性にパッチを適用した。

この主張は、所有権とデプロイ権限があれば修正までの時間を短縮できることを示唆している。ただし、これらの発見がどれほど深刻だったのか、また提案されたパッチのうち何件が修正を要したのかは示していない。

したがって、この仕組みは成熟したエンジニアリングプロセスを持つ組織に有利に働く。チームが自社の資産、担当者、依存関係、デプロイ経路をすでに把握している場合、AIは作業を加速できる。

資産台帳が不十分な組織は、どのシステムが重要かを把握しないまま、より多くの発見を受け取ることになる。その結果、バックログが拡大し、実際の脅威への対応が遅くなる可能性がある。

真のリスクはトリアージとパッチ適用能力の不足にある

AIによる脆弱性発見は、発見件数の増加が検証と修正の能力を上回ると危険になる。

セキュリティプログラムはすでに、数千件のスキャナー結果、依存関係アラート、設定警告、ペネトレーションテストの発見事項を管理している。AIは、より大きな規模と不確実な精度特性を持つ、別の発見源を加える。

機械生成の発見をすべて緊急と扱うチームは、レビュアーの能力を使い果たす。AIの出力をノイズが多いとして退けるチームは、まれではあっても影響の大きい攻撃経路を見落としかねない。

これは精度の問題を生む。防御側は、技術的な深刻度、到達可能な資産、攻撃者の関心、信頼できる悪用の証拠を兼ね備えた少数の案件を特定する必要がある。

従来の深刻度スコアリングは、その判断の一部しか扱えない。隔離されたテストシステムにあるクリティカルな欠陥は、外部公開されたゲートウェイ上のより低評価の欠陥よりも、差し迫った危険性が低い場合がある。

脅威インテリジェンスは、活発なスキャン、公開済みのエクスプロイトコード、犯罪者コミュニティでの議論、観測された攻撃に関する証拠を加える。資産コンテキストは、脆弱なコンポーネントが価値の高いサービス内に存在するかを示す。

最も強力なワークフローは、これらのシグナルを組み合わせる。重複する発見を統合し、到達可能性を検証し、エンジニアに作業を送る前に担当を割り当てる。

Googleのリスクベースの脆弱性ブループリントは、脆弱性の深刻度、資産の重要性、現在の脅威証拠を組み合わせることを推奨している。

このモデルは、生の発見件数が持つ中心的な弱点に対処する。最大のリストを出したツールを評価するのではなく、どの発見を最初に対処すべきかを問う。

VulnCheckの数値もこのアプローチを裏付ける。2026年上半期、同社は広範なソフトウェア市場で、既知の悪用が確認された脆弱性を495件特定した。

コンテンツ管理システムは、それらの約3分の1を占めた。ネットワークエッジデバイスも引き続き一般的な標的だった。

これらの製品が攻撃者を引き付けるのは、到達可能で広く導入され、初期侵入にとって価値が高いためだ。その悪用の経済性は、目立たない内部コンポーネントのそれを上回ることが多い。

セキュリティリーダーは、AIの結果をパッチ適用を遅らせる許可と解釈すべきではない。代わりに、3つの別個のキューを区別すべきだ。

第1のキューは、すでに悪用が確認されている脆弱性を対象とする。脅威がすでに存在するため、これらの欠陥には即時の封じ込め、検知、修正が必要だ。

第2のキューは、信頼できる悪用経路を持つ、検証済みかつ到達可能な脆弱性を対象とする。観測された攻撃がなくても、チームは迅速にパッチを適用すべきである。

第3のキューは、未検証の候補、または到達不能な資産上の発見を対象とする。これらもレビューを必要とするが、証拠に裏付けられた脅威を後回しにしてはならない。

この構造により、発見件数の急増がすべての問題を1つの深刻度バケットへ平坦化するのを防げる。また、メンテナーが開示スケジュールを交渉する際の、説明可能な根拠にもなる。

低い悪用率の背後には、もう一つのリスクがある。割合が安定していても、絶対数は大幅に増加し得る。

AIが有効な脆弱性を10倍多く生み出せば、悪用率が一定でも、悪用される事例は10倍になる。割合はこの規模効果を見えにくくする。

レビューされたデータも初期段階を反映している。攻撃者には、新しいツールを採用し、信頼性の高いハーネスを構築し、それらを偵察システムと統合する時間が必要だ。

Anthropicの最も高性能なサイバーモデルへの一般公開アクセスは、依然として制限されている。この制約により、現在の悪用データから広範な悪用について分かる範囲は限定される。

Anthropicは、Mythosへの一般アクセスに向けて十分に強力な安全策をまだ構築できていないと認めている。同社は、管理された防御プログラムを拡大する一方で、配布を制限している。

このアプローチは目先の露出を減らすが、測定上の課題を生む。制限されたモデルからは、一般的な犯罪グループが同等の能力を手にした場合にどう行動するかは分からない。

したがって、懐疑的な結論は限定的でなければならない。現在の証拠は、AIが発見した脆弱性が本質的に悪用されやすいことを示していない。

また、将来のシステムでも同じ比率が維持されることを証明するものでもない。さらに、既存の悪用がすべて発見され、あるいは公に帰属されていることも保証できない。

最も強力な政策対応は、パニックでも自己満足でもない。高度なサイバーモデルへのアクセスが拡大する前に、拡張可能な検証・パッチ適用システムを構築することだ。

Googleの特化型モデルが能力の上限を引き上げる

Googleの最新サイバーモデルは、今日の安心材料となる悪用率を恒久的な予測として扱えない理由を示している。

Gemini 3.5 Flash Cyberは、脆弱性の発見、検証、パッチ生成向けにファインチューニングされた軽量モデルだ。Googleは、政府機関と信頼できるパートナーに対し、CodeMenderを通じた限定的なアクセスを計画している。

このモデルの設計は、より大規模な汎用モデルへの1回の呼び出しに頼るのではなく、低コストの探索を繰り返すことを重視している。複数のエージェントがコードパスを調査した後、発見を統合する。

Googleによると、このアプローチは、1回の分析では探索空間をカバーしきれない複雑なリポジトリに適している。また、コミットやリリース時の頻繁なスキャンにも対応する。

同社は、より注目すべき社内テスト結果を報告した。Gemini 3.5 Flash CyberはGoogle Cloudのシステムを調査し、2時間以内に公開APIのリモートコード実行脆弱性を発見した。

Googleによると、このモデルは機微な本番サービスでメモリ破損の問題も発見した。その後、テスト条件下で完全に信頼できるエクスプロイトを生成した。

Googleのサイバーモデルの結果によると、そのエクスプロイトはAddress Space Layout RandomizationとWrite XOR Executeの保護を回避した。

Address Space Layout Randomizationは、攻撃を妨げるためにメモリ位置を変更する。Write XOR Executeは、メモリが同時に書き込み可能かつ実行可能になることを防ぐ。

両方の制御を回避するには、不審なソースコードを認識するだけでは足りない。システムは、より困難な検証とエクスプロイト開発の段階に近づくことになる。

この結果は、管理された防御プログラム内で行われた、同社報告による実演にとどまる。Googleは影響を受けたシステムや、外部で再現できるだけの詳細を明らかにしていない。

それでも、悪用が現行モデルの能力を超えているという安心できる主張は弱まる。より妥当な結論は、悪用能力が不均一に、かつ制約された条件下で存在するということだ。

Googleには他にない利点もある。セキュリティチームは、内部コード、本番環境のコンテキスト、過去のファジング結果、詳細な脆弱性データベースにアクセスできる。

この情報は、外部の攻撃者が得られるものよりも優れた基盤をエージェントに与える。また、同社が実システムに照らしてモデル出力を検証する助けにもなる。

攻撃者には別の利点がある。外部公開された製品に集中し、流出したソースコードを再利用し、パッチを調べ、より高い失敗率を受け入れられる。

攻撃キャンペーンは、すべての発見を理解する必要はない。十分に価値の高い標的に対する、信頼できる1つの経路があればよい。

この非対称性は、VulnCheckの発見にもかかわらずAmazonとGoogleのセキュリティへの取り組みが依然として重要である理由を説明する。業界は、現在の攻撃を測定するだけでなく、能力の拡散に備えている。

Project Glasswingは、Mythos級のシステムが広く利用可能になる前に、選定された組織が重要なソフトウェアを強化する時間を提供する。Googleも同様の限定公開アプローチを取っている。

ただし、管理されたアクセスだけで戦略全体を構成することはできない。オープンモデル、特化型ツール、改善されたエージェントフレームワークは、能力差を縮め続ける。

したがって、防御側には露出を継続的に減らすシステムが必要だ。脆弱なコードが本番環境に到達した後で別のアラートを追加するよりも、リリース前のスキャンのほうが価値が高い。

自動パッチ提案は修正を早められるが、認証、メモリ処理、暗号、信頼境界に影響する変更は人間がレビューしなければならない。

勝てる防御アーキテクチャは、モデルによる発見を再現可能な証拠へ結び付ける。さらに、その証拠をテスト済みのパッチ、デプロイ責任者、攻撃テレメトリーへ接続する。

これは脆弱性を数えるよりも要求水準が高い。しかし、測定可能なセキュリティ成果に最も密接に結び付く基準でもある。

バランスの変化を示す3つのシグナル

次の段階は、悪用の証拠、修正の処理能力、特化型サイバーモデルへのアクセスを通じて測定される。

第1のシグナルは、AIに起因する脆弱性のうち、既知の悪用カタログに登録される割合だ。VulnCheckの現在の1.3%という結果は、有用な初期ベースラインとなる。

より広範な脆弱性率を上回る持続的な上昇は、AIが特に攻撃者を引き付ける標的を生み出すという主張を強める。安定した比率は、発見件数の解釈を支持するだろう。

ここでは帰属の品質が重要になる。研究者は、AIが発見した脆弱性と、人間または従来のスキャナーが弱点を発見した後にAIで開発されたエクスプロイトを区別しなければならない。

これらは政策上の含意が異なる、別種の能力だ。不適切なラベリングは、証拠が許す以上に議論のどちらか一方を強く見せかねない。

第2のシグナルは、Project Glasswingの公開修正台帳だ。候補のうち、検証済みアドバイザリー、パッチ、CVE、またはクローズされた誤検知となる件数に注目すべきである。

AnthropicのGlasswing更新情報は、レビューされたサブセットで強力な検証結果を報告した。しかし、より広範な候補バックログは、公開CVE数を大きく上回ったままだった。

パッチ適用率が上がれば、開示と修正のシステムが発見能力に追いついていることを示す。バックログの拡大は、人間の能力が主要なセキュリティ制約になったことを裏付けるだろう。

パッチの品質は、量と同じくらい重要だ。急いだ修正はリグレッションを招き、別の攻撃経路を残し、あるいは攻撃者がエクスプロイトを再構築できるほどの情報を開示する可能性がある。

したがって、研究者はパッチ公開だけでなく、デプロイと検証も追跡すべきだ。修正がユーザーを保護するのは、メンテナーがリリースし、運用者が導入した後に限られる。

第三の兆候は、Mythos、Gemini Flash Cyber、あるいは同等の専門モデルへのアクセス拡大だ。AnthropicとGoogleは現在、最も機微な能力へのアクセスを制限している。

利用可能性が広がれば、高度なサイバーエージェントがより大きな利用者層でどのように振る舞うかを初めて本格的に検証できる。また、安全対策と本人確認への圧力も高まる。

アクセスが拡大しても確認済みの悪用が増えなければ、現在の現実的な評価はより強固になる。悪用が急増すれば、今日の低い発生率は導入の遅れにすぎなかったことになる。

Amazon、Google、そして両社のパートナーは、成果に基づく測定指標もさらに公表すべきだ。有用な指標には、検証済みの発見件数、パッチ適用までの時間、導入済みの修正、阻止された攻撃が含まれる。

候補件数は、探索範囲の広さを評価するうえで依然として有用だ。しかし、セキュリティプログラムが実際のリスクを低減したかを測るには不十分である。

開発者にとっての教訓は、AIセキュリティツールに再現可能な証拠を求めることだ。検出結果には、影響を受けるコード、到達可能となる条件、影響範囲、そしてテスト可能な修正方法が含まれるべきである。

企業の購買担当者にとっては、既存の資産やワークフローとの統合が優先事項となる。所有者や文脈のないままアラートだけを増やすツールは、運用リスクを高めかねない。

オープンソースのメンテナーにとっては、開示のペース配分と、資金の裏付けがあるレビュー能力への関心を高める必要がある。AIシステムは今や、ボランティアコミュニティが処理できる量をはるかに上回る速度で作業を生み出せる。

AmazonとGoogleによるセキュリティ連合は、もっともらしい将来の脅威に対応している。しかし現時点の証拠が示すのは、差し迫った危機は自動化された大規模悪用ではなく、過負荷状態の防御パイプラインだということだ。

この違いは、支出、製品設計、政策の方向性を左右すべきである。チームに必要なのは、優先順位のないアラートを減らし、発見から修正までをつなぐ検証済みの道筋を増やすことだ。

今後数か月は、悪用比率、パッチ適用の滞留、専門モデルへのアクセスを注視すべきだ。これらの兆候を合わせて見れば、AIが攻撃の経済性を変えるのか、それとも主に発見量を増やすだけなのかが分かる。

すべてのセキュリティチームにとって実務上の問いはシンプルだ。より大きなキューに重要な検出結果が埋もれる前に、組織は最も重大な問題を検証し、修正できるだろうか。