MITRE CVE記録、AIによる脆弱性発見がセキュリティチームのトリアージ能力を上回る状況を示す
MITREは2025年に過去最多となる48,244件の脆弱性を記録し、MITRE CVEの件数は2026年前半も増え続けた。AI支援型の調査によって脆弱性はより速く見つかるようになった一方、多くのセキュリティチームにとっては、各報告を検証し、優先順位を付け、修正する能力を超えるペースで開示件数が増えている。
報告された集計値によると、2026年6月までに35,000件超の脆弱性が登録されていた。これは前年の通年最多記録のほぼ4分の3に相当する。こうした増加は、開発者が突如として大幅に質の低いソフトウェアを書くようになったことだけを示すものではない。
より本質的な変化は、発見の手法にある。AIシステムは、大規模なコードベースの調査、ソフトウェアバージョンの比較、攻撃経路の提案、不審な挙動の抽出を、人間の研究者では及ばない規模で実行できる。Anthropic、OpenAI、Google、Microsoft、そしてセキュリティベンダーはいずれも、サイバーセキュリティに特化したモデルや研究プログラムに投資している。
ここには明確な緊張関係がある。隠れた弱点を早期に見つければ、防御側はそれを取り除く時間を得られる。しかし、新たな開示はすべて、すでに逼迫しているメンテナー、調整機関、セキュリティチーム、資産所有者の仕組みに流れ込む。
その結果は、成功する攻撃の単純な急増ではない。利用可能な証拠は、開示件数の急増、観測された悪用のより小幅な増加、そして両者の間に広がる運用上の隔たりを示している。
MITRE CVE記録は予測を上回る速さで増加している
決定的な変化は、1件の目を見張る脆弱性ではない。開示システム全体が持続的に加速していることだ。
Common Vulnerabilities and Exposures識別子、すなわちCVEは、公開されたセキュリティ上の欠陥に付与される標準化されたラベルである。CVEにより、ベンダー、研究者、政府機関、セキュリティツールは、不統一な名称に頼らず同じ問題を参照できる。
登録件数は2017年から2020年にかけて、年間数万件の水準で推移していた。2021年には20,161件に達し、その後2024年には40,077件、2025年には48,244件へと増加した。2026年6月までに、すでに35,000件超が登録されていた。
FIRSTとして知られるForum of Incident Response and Security Teamsは、年初前から再び記録が更新されると予想していた。同組織の2月の予測では、2026年のCVE件数の中央値を59,427件としていた。
実際の開示はすぐにその軌道を上回った。FIRSTの年央予測によれば、4月までの公開件数は従来予測を46.3％上回った。同組織は通年の推定値を約66,000件へ引き上げた。
この再評価では、4月までに初期モデルの想定を6,420件上回るCVEが特定された。その差は、AI支援による発見、報告範囲の拡大、CVEエコシステム内部の変化など、複数の要因によるものとされた。
GitHub Security Advisoryの件数は前年比449％増加していた。別の割り当て機関を持たない脆弱性の大規模なバックログを処理したことで、VulnCheckのCNA of Last Resortによる活動は3,119％増加した。
これらの詳細は重要である。MITRE CVE記録は単一の事象を測るものではない。新たな研究、過去の発見のシステムへの登録、ベンダーの開示サイクル、対象範囲の拡大、管理上の変更が組み合わさっている。CVEが1件増えるたびに、新たにソフトウェアが安全でなくなった証拠だと捉えるのは、データの読み違いになる。
脆弱性追跡の対象となるソフトウェア製品数も大幅に増えている。セキュリティ研究者は現在、より多くのアプリケーション、デバイス、ライブラリ、クラウドサービス、オープンソースコンポーネントを調査している。可視性が高まれば、以前は文書化されなかった欠陥が自然に明らかになる。
大手ベンダーによるリリースは、月ごとの急激な増加を生むことがある。ある企業が協調的なレビューを完了した後に、関連する数百件の問題をまとめて開示する場合がある。結果として作られるグラフは、根底にある発見率だけでなく、公開スケジュールも反映する。
ただし、こうした留保は変化そのものを打ち消すものではない。AIは、研究者が調査できるコード量を広げ、もっともらしい弱点を特定するまでの時間を短縮している。この新たな能力は、報告インフラがすでに増加する負荷に直面する中で導入されている。
したがって、この記録は進歩と圧力の両方を測っている。攻撃者が見つける前に、より多くの欠陥が可視化されつつある一方で、有効な報告が増えるたびにメンテナーと防御側の作業も増える。
AIによる脆弱性発見がバグ探索の規模を変えた
AIによる脆弱性発見は、希少な手作業だったコードレビューを、膨大なソフトウェア資産全体で繰り返し実行できるプロセスへと変える。
従来の脆弱性調査では、専門家がアプリケーションを理解し、危険な挙動を特定し、テストを構築し、攻撃が実行可能かを確認する必要がある。自動スキャナーも役立つが、既知のパターンに依存することが多く、誤検知も生じる。
最先端のAIモデルは、さらに別の層を加える。複数ファイルにまたがって推論し、プログラム内のデータを追跡し、修正済みと未修正のバージョンを比較し、テストケースを生成し、弱点の組み合わせを提案できる。重大な発見には依然として人間の研究者による検証が必要だが、探索段階でカバーできる範囲は広がる。
AnthropicのClaude Mythos Previewは、2026年に注目を集めた事例となった。同社によれば、オープンソースソフトウェアを調査するため、2月から初期モデルのスナップショットを使い始めた。その後、外部のセキュリティ企業が、高深刻度またはクリティカルな発見のトリアージ、検証、報告を支援した。
Anthropicの公開開示ダッシュボードでは、8月のスナップショットに462件の発行済み識別子が記録されていた。これには177件のCVEレコードと285件のGitHub Security Advisoriesが含まれるが、1件の脆弱性に両方の識別子が付与される場合もある。
より広範な主張ははるかに大きかった。Anthropicは、Project Glasswingが10,000件超の高深刻度またはクリティカルな脆弱性を発見したと述べた。公開記録はその報告総数の一部しかカバーしておらず、研究者は個々の発見の大半を評価できない。
Epoch AIは、Microsoft、Google、Apple、Oracle、Cisco、Linux、Mozilla、Apacheを含む21の主要テクノロジー組織の開示データを調査した。同社の深刻度データでは、6月に公開された高深刻度およびクリティカルなCVEは約1,550件だった。
この6月の合計は、AnthropicがMythos Previewを発表する前に観測された月間記録の3倍を超えた。7月には高深刻度およびクリティカルな開示が約2,500件に達し、従来の記録のおよそ5倍となった。
Epochは、この数値が公開済みの開示を対象としており、非公開で発見されたすべての脆弱性を含むものではないと注意を促した。また、レコードに新たな情報が追加されるにつれ、深刻度評価は変化すると指摘した。アナリストが個別のCVEを改訂すれば、過去の月間合計も変動し得る。
それでも、この時期は最先端モデルが重要な調査ツールになったという結論を支持する。AIプログラムは、社内監査の拡大、新たな開示イニシアチブ、大手ベンダーの投資拡大と並行して運用を開始した。
Googleは、自社の最近の発見件数について、規模とスピードの両面で前例がないと説明した。ベンダーのデータは、新たに報告された脆弱性の多くが外部の攻撃者ではなく社内調査から生じたことを示した。この違いにより、防御側は犯罪グループが脆弱性を武器化する前に修正する機会を得る。
AIは研究者が古いソフトウェアを再調査することも支援する。レガシーコードには、すべての経路を検証する十分な時間が誰にもなかったために、長年のテストをすり抜けたエラーが含まれている可能性がある。不審な挙動を継続的に探すモデルは、最近の開発とは無関係な脆弱性も発見できる。
この利点は大手テクノロジー企業にとどまらない。オープンソースのメンテナー、小規模ベンダー、セキュリティコンサルティング企業も、自動分析を利用して、これまで十分な注意を受けてこなかったコンポーネントを調査できる。
ただし、発見は最初の段階にすぎない。もっともらしい欠陥は、再現、評価、安全な報告、識別子の付与、修正、テスト、展開を経なければならない。AIはその連鎖の出発点を加速させるが、末端にいるすべてのチームの能力を自動的に拡張するわけではない。
この不均衡こそが、発見件数の増加が直ちにシステムの安全性向上につながらない理由を説明する。その恩恵は、攻撃者が脆弱性をエクスプロイトへ転換する前に、メンテナーが発見を信頼できる修正へ変換できるかどうかに左右される。
開示件数の増加は、すべての欠陥が緊急事態であることを意味しない
サイバーセキュリティにおける中心的な課題は、十分な脆弱性を見つけることから、どの発見が即時かつ到達可能なリスクを生むのかを特定することへ移っている。
生のMITRE CVE記録は、優先順位付きのキューではなく件数である。インターネットに公開されたゲートウェイで活発に悪用されている脆弱性と、使われていないコンポーネント内のローカルな欠陥とでは、対応は異なるべきだ。
FIRSTは、悪用可能性のデータを通じてこの違いを検討した。同組織の年央評価では、Cybersecurity and Infrastructure Security AgencyのKnown Exploited Vulnerabilitiesカタログと、10％を上回るExploit Prediction Scoring Systemの結果を用いて脆弱性を絞り込んだ。
同組織は、総件数が急増したにもかかわらず、実際に対応すべき悪用可能性は概して横ばいにとどまったと結論付けた。同組織の表現では、防御側はより多くの雨に直面しているものの、必ずしもそれに比例して大きな洪水に直面しているわけではない。
この結果は、AIによる脆弱性発見についてよくある解釈に疑問を投げかける。モデルが研究者による発見件数の増加を支援していることは明らかだ。しかし現時点の証拠は、AIが見つけたすべての弱点が悪用しやすくなった、あるいは攻撃者にとって魅力的になったことを示してはいない。
VulnCheckは、AnthropicのProject GlasswingおよびBerkeley Vulnerability Research Initiativeに関連する、公開帰属済みのAI支援型発見1,061件を分析した。そのうち実環境での悪用が確認されていたのは14件、すなわち1.3％だった。
この割合は、VulnCheckのより広いデータセットにおける悪用率に近かった。この比較は、AI支援型の発見が、従来の手法で発見された脆弱性より本質的に実際の攻撃へ発展しやすいわけではないことを示唆している。
この隔たりは、Anthropicが公開した結果ではさらに明確である。VulnCheckによると、Claude Mythosは23,019件の脆弱性候補を特定した一方、同社の分析でCVEとして確認されたのは126件にとどまった。実環境での悪用が確認されたのは1件だった。
これらの数値は、残りの候補が無害だったことを証明するものではない。多くは依然としてレビュー中である可能性や、協調開示の段階、修正待ち、あるいは公開がリスクを生むため非公開となっている可能性がある。ただし、候補数と検証済みCVEは同一視できないことを示している。
Google Threat Intelligence Groupも、別のデータセットから関連する結論に達した。同組織の悪用分析では、2026年1月から8月までに、公開され、かつ悪用された脆弱性が141件記録された。
この合計は、2025年通年で記録された127件を上回った。月平均の悪用件数は、2025年の10.5件から2026年には18件へ増加した。
ただし、2026年に開示されたすべての脆弱性のうち、観測された悪用に現れたのはわずか0.23％だった。これは、431件の開示ごとに、実際に悪用されている脆弱性が約1件という割合に相当する。
この小さな割合を理由に油断すべきではない。とりわけ広く導入されているインターネット接続製品に存在する場合、1件の脆弱性でも数千の組織に影響を及ぼし得る。攻撃者は広範な被害を引き起こすために、すべてのCVEを武器化する必要はない。
年の後半には、悪用に関するデータもより懸念すべきものになった。Googleは、5月以降、開示件数の増加と悪用件数の増加が密接に連動していることを確認した。指数化された開示件数は128%増加し、指数化された悪用件数は127%増加した。
高リスク脆弱性の悪用は2倍以上に増えた。Googleは、2026年1月から8月にかけて悪用された高リスク脆弱性を75件確認しており、2025年通年の28件を上回った。
ゼロデイ活動は比較的安定していた。ゼロデイとは、ベンダーや利用者が有効な修正手段を得る前に悪用される脆弱性を指す。月平均は2025年の8件から2026年には11件へ増加したが、8月には22件に達した。
Googleは、攻撃者にとっては、AIを用いてまったく新しいゼロデイを発見するよりも、既知の欠陥であるnデイを迅速に武器化する方が、より即時的な価値を得られる可能性があると示唆した。モデルはパッチ、リリースノート、製品バージョン、概念実証コードを比較し、このプロセスを加速できる。
このため、セキュリティチームに必要なのは、単に脆弱性リストを増やすことではなく、リスクの文脈である。CISAの悪用済み脆弱性カタログは、実際に悪用されている証拠のある欠陥を特定する。EPSSは、公開済みCVEが近い将来に悪用される確率を推定する。
こうしたシグナルは完全ではないが、組織が文書化された弱点と緊急の攻撃経路を区別する助けになる。資産の露出状況、権限、到達可能なシステム、利用可能な緩和策は、依然として意思決定に不可欠な要素である。
本当のボトルネックはトリアージとパッチ適用能力
AIは、組織が責任の所在を判断し、修正をテストし、安全にパッチを展開するよりも速く、セキュリティ上の発見を生み出せる。
有効な脆弱性が1件見つかるたびに、運用プロセスが始まる。メンテナーは問題を再現し、重大度を判断し、影響を受けるバージョンを特定し、修正を作成し、回帰をテストし、アドバイザリを準備して公開を調整しなければならない。
その後、顧客側にも独自の連鎖が生じる。影響を受ける製品を特定し、脆弱な機能が有効かどうかを把握し、代替的な統制を評価し、更新を予定し、パッチが成功したことを確認する必要がある。
組織に正確なソフトウェア資産台帳がない場合、この作業は困難になる。影響を受けるコンポーネントがどこで稼働しているか、あるいはどの業務サービスがそれに依存しているかを把握していなければ、セキュリティチームは脆弱性を確信を持って優先順位付けできない。
サードパーティー依存関係は問題をさらに難しくする。脆弱なライブラリがアプリケーションの数層下に存在し、運用担当者から見えないままになる可能性がある。コンテナ、プラグイン、ファームウェア、マネージドサービスも、責任の所在をさらに不明瞭にし得る。
人材不足が圧力を強めている。Proofpoint日本法人のYukimi Sota氏は元の報道機関に対し、セキュリティ業界で人材が不足しているため、多くの企業が対策で後れを取っていると語った。
日本企業で最近発生した不正アクセスと情報漏えいにより、この記録にはさらなる緊急性が加わった。報道によれば、主要なカーシェアリングサービスであるTimes Carも被害に含まれ、日本政府は企業に防御の強化を促した。
直近のリスクは、新しいCVEのすべてに緊急展開が必要だということではない。リスクは、構造化されていないキューによって、攻撃者がすでに悪用している少数の欠陥をチームが見落とすことにある。
公開順にすべてへパッチを適用すれば、貴重な時間を浪費する。急いだ変更が複雑な本番システムに影響する場合、障害を引き起こす可能性もある。防御側は脅威インテリジェンスを自らの資産および事業の文脈と組み合わせなければならない。
実用的な優先順位付けは、活発に悪用されているものから始まる。その後、チームはインターネットへの露出、認証要件、攻撃の複雑性、取得される権限、データの機密性、影響を受けるサービスの重要度を検討すべきだ。
ベンダーの重大度評価だけでは、こうした問いには答えられない。隔離されたテストシステムにあるクリティカルな脆弱性よりも、公開ゲートウェイ上の高重大度の欠陥の方が、より差し迫った危険をもたらす場合がある。
セキュリティチームには、意思決定を確実に保存する手段も必要だ。アドバイザリ、例外記録、影響を受けるシステムに関するメモ、緩和の証拠は、チケット、チャット、スプレッドシート、メールに分散しがちである。
検索可能な技術ナレッジベースは、脆弱性通知をアーキテクチャ文書や過去の是正作業と結び付ける助けになる。スキャンやパッチ適用の代わりにはならないが、繰り返しの調査を減らせる。
AIもこの段階で支援できる。モデルはアドバイザリを要約し、製品名を資産台帳に対応付け、バージョンを比較し、是正手順の草案を作成し、分析担当者が重複レポートをグループ化するのを支援できる。
これらの用途には統制が必要である。セキュリティチームは生成された結論を検証し、機密のシステム情報を保護し、認証情報や機密性の高いアーキテクチャ詳細を未承認のサービスへ送信しないようにしなければならない。
自動化された修正には別のリスクがある。ある脆弱なコード経路を除去するパッチが、別の欠陥を生んだり、本番環境の挙動を壊したりする可能性がある。メンテナーには引き続きテスト、レビュー、段階的な展開が必要だ。
圧力はソフトウェアエコシステム全体に均等には及ばない。大手ベンダーは専任の製品セキュリティチームを運営し、大規模な開示サイクルを調整できる。一方、小規模なオープンソースプロジェクトは、数千人の利用者を少数のボランティアが支えている可能性がある。
そのため、AI支援型の研究は、十分な資金を持つモデル開発者やセキュリティ研究所から、限られたリソースしか持たないメンテナーへコストを移す可能性がある。より多くのバグを見つけることには価値があるが、開示プログラムは受け手の対応能力を考慮しなければならない。
責任ある報告には、重複排除、明確な再現手順、重大度の根拠、合理的な是正期間が必要である。確信度の低いアラートを数千件送信しても、相応のセキュリティ向上を生まずに注意力を消費することになる。
最も望ましい結果は、均衡の取れたパイプラインである。AIが広く探索し、人間が重要な発見を検証し、メンテナーが有用な報告を受け取り、防御側が実際の露出に基づいて展開の優先順位を決める。
この規律がなければ、発見件数の増加はアラート疲れの新たな原因になる。チームはより多くの警告を見る一方で、最も危険な少数は埋もれたままとなる。
AIは脆弱性競争の両陣営を変える
戦略的な競争は、AIを使う防御側と従来型の攻撃者の対立ではない。両陣営が同じ脆弱性ライフサイクルの異なる段階で、似た能力を利用できる。
現在、防御側は、社内AIプログラムが公開前に欠陥を発見して修正する場合に、有意義な優位性を得ている。Googleによれば、大規模なChromeアップデートにおける433件の脆弱性のうち401件は社内で発見された。
この傾向は、開示の急増に予防的な作業が含まれていることを示唆する。ベンダーが管理する発見であれば、詳細な技術情報が広がる前に、エンジニアはパッチを開発し、リリースを調整し、顧客を準備できる。
攻撃者は開示後に影響力を得る。AIはアドバイザリを読み解き、コード変更を比較し、概念実証を生成し、露出したシステムをスキャンし、公開済みのエクスプロイトコードを適応させられる。これらの活動は、公開から悪用の試行までの期間を短縮する。
Recorded Futureによれば、攻撃者が脆弱性を悪用するまでに必要な平均時間は、2025年の72時間から2026年には24時間へ低下した。この推定は、ほとんどのCVEが観測された攻撃に現れないとしても、到達可能な欠陥を即座に優先する必要性を裏付けている。
AIシステムは、最終的には未知の欠陥を自律的に発見して悪用できるようになるかもしれない。公開された事例やベンダーの主張は、より長い一連のサイバーセキュリティ作業に向けた進展を示しているが、入手可能な証拠には依然としてばらつきがある。
一部の実演は、慎重に選定された標的、大規模な計算資源、カスタム指示、専門家の監督を備えた管理環境で行われている。その結果は、一般的な犯罪者が同じ性能を大規模に再現できることを示すものではない。
Palo Alto Networksは、AnthropicとOpenAIの高度なモデルが自社製品で75件の脆弱性を発見するのに役立ち、通常の月間件数の7倍超に達したと述べた。同社の最高製品責任者も、この取り組みには大幅なカスタマイズと人間の専門知識が必要だったと認めている。
この留保は重要である。モデル能力は、運用上の攻撃を構成する一部分にすぎない。敵対者には依然として、標的へのアクセス、インフラ、検証、秘匿性、永続性、そして技術的アクセスを有用な成果へ変える手段が必要だ。
防御側にも構造的な利点がある。ベンダーはソースコード、内部テスト、製品テレメトリ、パッチ配布を管理している。自らのシステムにモデルを向け、アーキテクチャを理解するエンジニアによって結果を検証できる。
攻撃者は非対称性の恩恵を受ける。防御側がすべての重要システムを管理しなければならないのに対し、攻撃者は標的への有用な経路を1つ見つければよい。AIがこの不均衡を生み出すわけではないが、より速い研究はそれを強め得る。
開示そのものが両陣営を結び付けている。CVEの公開は、防御側に共通の識別子と是正情報を与える。一方で、特にパッチによって脆弱なコードが明らかになる場合には、攻撃者に注目すべき場所を教えることにもなる。
開示を無期限に遅らせることは解決策ではない。報告されない欠陥は、顧客に保護への道筋を与えないまま悪用可能な状態で残り得る。目標は、不要な技術的露出を抑えながら、メンテナーが修正をリリースする時間を確保する調整である。
現時点で最も強い証拠が支持する結論は、楽観的な主張にも警鐘を鳴らす主張にも及ばない、より限定的なものだ。AIはすでに脆弱性発見能力を高めている。また分析とエクスプロイト開発にも役立っているが、悪用は生の開示件数に正比例して増加してはいない。
この均衡は変わり得る。モデルは進化し、サイバーセキュリティに特化した学習は拡大し、より多くの組織が研究ワークフローにエージェントを統合している。最も高性能なシステムを巡るアクセス制御が、こうした能力の拡散速度に影響するだろう。
セキュリティリーダーは、単一の劇的な予測を前提に計画すべきではない。発見と武器化の双方が高速化すると想定し、複数の想定される時間軸にわたって有用であり続けるプロセスを構築すべきだ。
そのためには、資産識別サイクルの短縮、テスト済みの緊急パッチ手順、より優れたセグメンテーション、悪用を検知するためのより強力な監視が必要になる。また、その出力を信頼できるデータと照合できる場面で、防御的AIを活用することも意味する。
セキュリティチームが次に注視すべきこと
脆弱性の急増が管理可能な状態にとどまるのか、それともより大きな悪用危機へ発展するのかを示すシグナルは3つある。
最初のシグナルは、CVE総数と確認済み悪用の関係である。生の開示件数は今後も記録を更新し続ける可能性が高いが、それだけで運用上のリスクが決まるわけではない。
チームはCISAカタログ、悪用テレメトリ、高信頼度の確率スコアを追跡すべきだ。悪用された脆弱性が開示件数のごく一部にとどまるなら、優先順位付けによって作業量の大部分を管理できる。
悪用が開示よりも速く増え始めた場合、中心となる論点は変わる。それは、攻撃者が単に大きくなった候補群から恩恵を受けるだけでなく、発見のより大きな割合を実際に機能する攻撃へ転換していることを示す。
2つ目のシグナルは、発見、検証、パッチ提供までの遅延である。AI支援プログラムは数千件の候補を主張できる一方、修正を伴う公開アドバイザリに現れるのはその一部にとどまる。
変換までの遅延が短縮していれば、ベンダーと調整者が発見と並行して能力を拡大していることを示す。バックログが増加していれば、AIがパイプラインの前段を加速させた一方で、より難しい是正のボトルネックを解決していないことを意味する。
公開台帳により、これを評価しやすくなるはずだ。有用な報告では、候補、検証済み脆弱性、割り当て済み識別子、完了したパッチ、展開済みの修正を区別する必要がある。
3つ目のシグナルは、パッチやアドバイザリが公開された後の悪用までの速さだ。かつて防御側は、多くの脆弱性に対する対応可能期間を数週間単位で見積もっていた。日常的な攻撃の武器化が1日以内に起きるという証拠が示されれば、より多くの組織が露出状況の確認と緊急修復の自動化を迫られるだろう。
このシグナルは、目を見張るような実験室でのデモよりも重要である。現実世界での武器化までの時間が再現性をもって短縮されれば、攻撃者が完全自律型のゼロデイ発見を実現しなくとも、一般的なソフトウェアを利用するあらゆる企業に影響が及ぶ。
したがって、MITRE CVEの記録は、無差別なパニックではなく、プロセスの見直しを促すべきだ。組織は、自らが運用しているシステム、インターネットに接続されているシステム、そして修復判断の責任者を把握する必要がある。
また、緊急アップデートが承認待ちのキューに閉じ込められることなく、アドバイザリからデプロイまで進められるかを検証すべきである。紙の上にしか存在しない緊急手順では、24時間の悪用ウィンドウに対応できない。
AIによる脆弱性の発見は、依然として防御側にとっての好機である。犯罪者が見つける前に古い弱点を明らかにし、十分なレビューを受けてこなかったコードを保守担当者が調査する助けとなる。
その利点は、発見後に何が起きるかに左右される。誰も検証しない検出結果はノイズを生む。利用可能なパッチがない検証済みCVEは露出を生む。顧客が展開できないパッチでは、根本的なリスクは残ったままだ。
開発者、セキュリティ責任者、テクノロジーの購買担当者にとって、重要な問いはもはや、AIがより多くの欠陥を見つけられるかどうかではない。証拠は、それが可能であることを示している。問われるのは、攻撃者が同じことをする前に、検出結果の洪水を少数で優先順位付けされた行動リストへと変えられるかどうかだ。
