Anthropic OSS Scannerはバグ報告を迅速化する一方、レビューをメンテナーに委ねる
Anthropicは29,000件超の候補脆弱性を発見した後、Anthropic OSS Scannerを開始した。しかし、この無料サービスでは最速の報告経路から人間によるレビューが省かれている。この変化は、オープンソースのメンテナーが受け取るものを変える。また、AIが生成した警告が緊急のセキュリティ脆弱性、重複、あるいはノイズのいずれなのかを判断する責任が誰にあるのかも変える。
このオプトイン型サービスは、Claude Mythosを含むAnthropicの最も強力なモデルを用いて、対象となるオープンソースリポジトリを定期的に調査する。メンテナーは、再現手順、根本原因の分析、利用可能な場合には修正パッチの提案を含む報告を受け取る。Anthropicはスキャン費用を負担し、参加プロジェクトは結果を検証して優先順位を付けるために必要な専門知識を提供する。
この仕組みは、協調的な脆弱性開示を支えてきた確立済みのモデルに一石を投じる。GoogleのOSS-Fuzzや従来のセキュリティプログラムは、再現可能性、専門家によるトリアージ、管理された開示を重視する。Anthropicは、モデル生成の証拠が、人間のレビュアーがすべての報告を承認する前に、準備の整ったメンテナーへ届くほど信頼できるものになったかを検証している。
Anthropic OSS Scannerがより迅速な報告チャネルを開く
このサービスは、単に別のコードスキャンを自動化するものではない。最先端AIモデルからオープンソースのメンテナーへ直接つながるチャネルを作る。
Anthropicは2026年10月8日にOSS Scannerを発表した。同社はこれを、大規模なインフラまたはユーザーセキュリティに影響を与える、確立されたプロジェクト向けの無料オプトインサービスと説明している。
コアメンテナーはAnthropicの公開リポジトリを通じて登録する。プロジェクト設定、セキュリティ連絡先、コンテナ内でソフトウェアをビルドするための手順を提出する。Anthropicは申請者が正当なプロジェクトメンテナーであることを確認したうえで受け入れる。
スキャナーはまず、ネットワークアクセスを持つ隔離された仮想マシン内でプロジェクトをビルドする。その後、エージェントがセキュリティ監査を開始する前にインターネットアクセスを遮断する。この分離により、分析中にエージェントが外部サービスへ連絡したり情報を送信したりする能力を制限する。
メンテナーは脅威モデルも提供できる。脅威モデルには、信頼された境界、敵対的な入力、対象外のコンポーネント、プロジェクトの深刻度ルールを記録する。この文脈は、モデルが本物のセキュリティ境界と、プロジェクトが意図的に許容している動作を区別する助けになる。
Anthropicのscanner documentationによると、このパイプラインはエージェントを使って検出結果を再確認し、根本原因を分析し、候補パッチを準備する。これらの確認は依然としてモデル生成によるものだ。各報告は配信前に人間が承認するわけではない。
報告はメールでまとめて届く。各報告には、自己完結型の再現手順、脆弱性の説明、修正案が含まれる場合がある。Anthropicは、脆弱な動作がいつコードベースに導入されたかも特定する可能性がある。
このレベルの補足資料は重要だ。メンテナーは、ある関数が危険そうに見えるという短い主張だけで安全に行動することはできない。動作を確実に再現し、露出範囲を評価し、既存の機能に対してパッチをテストする信頼できる手段が必要である。
初回監査後、Anthropicは登録済みプロジェクトを定期的にスキャンする計画だ。後続のスキャンでは、新たに導入された弱点を調べたり、以前のモデル実行で見逃した問題のあるコードを再調査したりできる。正確な頻度は需要と利用可能な処理能力に依存する。
プロジェクトは設定値を変更することで報告を一時停止できる。また、登録リポジトリから自身のディレクトリを削除すれば撤退も可能だ。検出結果の量や品質が管理不能になった場合、参加を元に戻せる。
対象条件は、「無料」という言葉から想像されるより狭い。Anthropicは、信頼できない入力を処理するソフトウェアや、多数の下流プロジェクトを支える確立済みのソフトウェアを優先する方針だ。申請は個別に評価し、参加の拡大に応じて基準を調整できる。
Anthropicは、このプログラムが、検証済みの高深刻度およびクリティカルな報告をすでに処理できるプロジェクトに適していると明言している。この条件は、提供内容に重要な境界を設ける。サービスが提供するのは検出能力の増強であり、すべての結果を調査するためのメンテナーではない。
登録プロセスでは、プロジェクトに対して利用可能なセキュリティ連絡先の公開も求める。非公開通信を必要とするチームは、公開暗号鍵を提供できる。この選択肢により、機微な報告が保護されない通常のメール経由で送られるリスクを減らす。
結果として生まれるサービスは、常時利用できる外部リサーチチームに似ている。しかし、その報告はAnthropicの人間によるレビュー済み開示プロセスに伴う保証なしに、プロジェクトのキューへ入る。利点は速度であり、代償は検証作業の移転である。
Anthropicが人間によるレビューを外す理由
AIによる脆弱性発見は、Anthropicがモデルの発見物すべてを検証・開示し、修正を支援する能力よりも速く拡大している。
Anthropicによると、同社のモデルは開始前の6か月間に重要なソフトウェアプロジェクトをスキャンした。その結果、29,000件を超える候補脆弱性が生成された一方、人間が手作業でレビューおよびトリアージしたのは約6,000件だった。
この差は、無料アクセス以上に、この開始の意味を明確にしている。Anthropicにはすでに、報告をレビューし、メンテナーとの調整を行うプロセスがあった。しかしそのプロセスは、モデルが生成する速度で検出結果を処理できなかった。
一部のメンテナーは未検証のバックログを要求し始めた。Anthropicのlaunch announcementによると、プロジェクトは提案パッチを含む約5,000件の生報告を求めていた。こうした要請は、準備されたチームが普遍的な人間による検証よりも迅速なアクセスを重視していたことを示唆している。
そこでAnthropicは開示システムを2つの経路に分けた。既存の協調的脆弱性開示プロセスは、人間によって検証された検出結果を引き続き提供する。OSS Scannerは、モデル生成の出力を自らレビューする意思のあるプロジェクト向けに、任意の高速経路を提供する。
これは協調的開示の放棄ではない。Anthropicによれば、未検証のスキャナー報告は標準的な開示期限を開始させない。メンテナーが受け取ったという理由だけで、同社がこのような検出結果を公開することはない。
その後、Anthropicが従来プログラムを通じて報告を検証した場合、通知後に通常の開示期間が始まる可能性がある。この区別により、メンテナーは自動的な公開カウントダウンを生じさせずに、生の検出結果を調べる時間を得られる。
このシステムは、高度なモデルを防御的サイバーセキュリティへ応用するAnthropicのより広範なプログラム、Project Glasswingから生まれた。5月には、約50のパートナーが10,000件を超える高深刻度またはクリティカルな脆弱性を特定したと同社は述べた。
Anthropicはまた、1,000を超えるオープンソースプロジェクトをスキャンしたと報告した。Claude Mythos Previewは当時、合計23,019件の検出結果のうち6,202件を高深刻度またはクリティカルに分類した。これらの数値は、完了した独立監査ではなく、同社が報告した推定値である。
より広範なGlasswing resultsは、第2のボトルネックを示した。疑わしい脆弱性を見つける時間は、それを検証し、修正を調整し、変更をテストし、パッチ済みソフトウェアを配布する時間よりはるかに短い場合がある。
モデルは数千のリポジトリにわたって分析を繰り返せる。メンテナーは、ローカルな設計判断、互換性に関する約束、リリース慣行、下流依存関係を理解しなければならない。これらの責務は同じ速度では拡張しない。
Anthropicの以前のFirefoxでの取り組みは、両面を示していた。Claude Opus 4.6は2週間の協業中に22件の脆弱性を発見し、Mozillaはそのうち14件を高深刻度と評価した。研究者は、最初の深刻な検出結果を独立した仮想マシン内で検証してから提出した。
Firefox security workには、AnthropicとMozillaの積極的な協力が関わっていた。これは、専門チームが検出結果を再現し、修正を管理できる場合に、AIが発見を加速できることを示した。
OSS Scannerは、この能力を少数の集中的なパートナーシップの外へ広げようとしている。そのために、能力を備えたメンテナーを最終レビュアーとして扱う。モデルが到達範囲を提供し、各プロジェクトが判断を提供する。
この設計は、モデル生成報告の品質変化も反映している。Anthropicは、脆弱性発見における大幅な向上を示すベンチマーク結果を引用している。それでもベンチマークだけでは、あらゆる言語、アーキテクチャ、脅威モデルにおける性能を予測できない。
メンテナーからのフィードバックは、より実用的な指標となる。Anthropicによれば、初期参加者は多くの報告を有用と評価しており、特に動作するエクスプロイトや、ほぼそのまま利用できるパッチが含まれる場合に有用だったという。これらの説明は独立した調査ではなく、Anthropicの発表資料の一部である。
公表された最も強いサンプルには、48プロジェクトにまたがる97件のクリティカルまたは高深刻度の検出結果が含まれていた。外部のペネトレーションテスターは、そのうち85件がAnthropicの開示基準を満たすと判断した。別の11件は実際の問題だったが既存の検出結果と重複しており、1件は無効だった。
このサンプルでは、Anthropicが提示した基準に基づく受理率は88%となった。これは有望だが、普遍的な偽陽性率を確立するものではない。このサンプルは、すでにクリティカルまたは高深刻度と分類された検出結果に焦点を当てていた。
選択効果も重要だ。Anthropicは結果を公表する前に、数十のプロジェクトとともに数週間かけてパイプラインを検証していた。未知のプロジェクト、特殊なビルドシステム、あるいは文書化が不十分なセキュリティ境界での性能は異なる可能性がある。
したがって、この開始は豊富さに対する運用上の対応を意味する。Anthropicには、専門家が速やかにレビューできる数を上回る疑わしい脆弱性がある。OSS Scannerは、成熟したプロジェクトがその検証作業の一部を安全に引き受けられるかを問うものだ。
Anthropic OSS Scannerが従来のセキュリティワークフローに圧力をかける
中心となる競争は、Anthropicと一社のベンダーの対決ではない。AI規模の発見と、人間規模の検証および修正対応の対比である。
従来型のスキャナーは通常、定義されたカテゴリに特化している。依存関係ツールはパッケージのバージョンを既知の脆弱性データベースと照合する。静的解析はソースコードのパターンを調べ、ファザーは通常とは異なる入力を生成してクラッシュや不正な動作を観察する。
言語モデルのエージェントは異なる働き方ができる。ファイルをまたいで移動し、プログラムの動作について仮説を立て、呼び出し経路を調べ、調査を修正できる。同じワークフローでエクスプロイトを説明し、パッチを下書きすることもできる。
この柔軟性は、既知のシグネチャがない脆弱性を明らかにし得る。一方で、誤った説得力のある説明を生み出す可能性もある。詳細な報告が自動的に有効な報告になるわけではない。特に、動作が悪用可能かどうかをプロジェクト固有の前提が左右する場合はそうだ。
GoogleのOSS-Fuzzは、最も明確な歴史的比較対象となる。重要なオープンソースプロジェクトを継続的にファジングし、再現可能な失敗を確立済みの開示プロセスと統合する。Anthropicによれば、このプログラムは同社の対象条件モデルに着想を与えた。
OSS Scannerはファジングを置き換えるものではない。ロジック、権限、状態遷移、コンポーネント間の相互作用を調査できる、推論ベースのレイヤーを追加する。これらの領域は、既知のパターンやランダム生成された入力を中心に構築されたスキャナーでは検出が難しい場合がある。
競争の場も広がっている。Ciscoは、リポジトリを調査し脆弱なコードを特定するために設計されたAntaresモデルを公開した。Capital OneはVulnHunterを公開し、ほかのセキュリティ企業もテストおよび修復製品にエージェントを組み込んでいる。
Ciscoのアプローチは、組織が自社コードのより近くで実行できる、小規模で特化したモデルを重視している。Antaresのモデル戦略は別の懸念に対応するものだ。一部のチームは、機密性の高いリポジトリを外部のモデルプロバイダーに送信したくない。
一方、Anthropicはスキャンサービスを運用し、採択されたオープンソースプロジェクトの計算コストを負担する。このモデルにより、メンテナーは高度なモデルスタックを導入することなく、計算資源を大量に要する手法を利用できる。
その代償は、Anthropicのインフラ、ポリシー、利用可能な容量への依存だ。メンテナーが受け取るのもAnthropicのシステムが生成した形式の出力である。基盤となるモデルや、すべてのスキャンハーネスを制御することはできない。
商用顧客向けには、AnthropicはClaude Securityを別製品として提供している。このサービスは、脆弱性の検出とパッチ生成を企業の開発ワークフローに統合する。OSS Scannerは、無料のエンタープライズ代替品ではなく、オープンソースプロジェクト向けのインフラ支援として位置付けられている。
この違いは、セキュリティベンダーに戦略的な圧力を生む。最先端モデルの提供者が基盤プロジェクトの監査に資金を提供すれば、高価値な脆弱性調査の一部は上流へ移行する。商用ツールはその後、ワークフロー統合、プライベート環境での展開、ガバナンス、対応管理で競争しなければならない。
オープンソースのメンテナーは別の圧力に直面する。十分に支援されたプロジェクトなら、報告を新たな調査の手がかりとして扱える。ボランティア運営のプロジェクトでは、すべての指摘が技術的に有用であっても対応に苦慮する可能性がある。
検証は最初の一歩にすぎない。メンテナーは影響を受けるバージョンを評価し、テストを書き、安全な修正を選び、リリースを調整し、下流の利用者に通知しなければならない。ある経路を閉じるパッチが、別の欠陥を導入したり互換性を損ねたりすることもある。
1つのモデルが複数のブランチにまたがる関連する弱点を特定すると、負担はさらに増す。各報告は、パッケージ配布者、クラウドプロバイダー、アプリケーションチーム、インシデント対応担当者に作業を発生させる可能性がある。検出速度は、サプライチェーン全体の調整コストを増幅させうる。
だからこそ、スキャナーが提案するパッチは重要である一方、それだけで問題を解決するものではない。候補パッチはテストに至るまでの道のりを短縮する。しかし、アーキテクチャ、後方互換性、リリースの安全性に関する責任をメンテナーから取り除くことはできない。
チームには、報告を修正やデプロイ判断と結び付ける、長期的に維持できる記録も必要だ。検索可能なエンジニアリングナレッジベースは、脅威モデル、再現の証拠、パッチレビューを複数のリリースにわたって保存できる。
最良の成果は、報告件数を最大化することではない。悪用可能な露出を測定可能な形で減らすことだ。そのためには、どの指摘が有効だったか、修正がどれほど速く出荷されたか、利用者が修正版を導入したかを追跡する必要がある。
Anthropicは、修正のクレジット表記に報告識別子を含めるようメンテナーに求めている。こうした識別子は、受理された指摘とパッチの測定に役立つ可能性がある。ただし、攻撃者が同じ欠陥を発見する前に下流システムが更新されたかどうかは明らかにならない。
したがって、このスキャナーは発見後のあらゆる段階に圧力をかける。成熟したセキュリティプロセスを持つプロジェクトは、高スループットの入力をもう1つ得る。そうしたプロセスを持たないプロジェクトは、検出精度の向上だけでは解消できないバックログに直面する。
より迅速な発見は検証上のトレードオフを生む
人によるレビューを省けば報告は早く届くが、不確実性もメンテナーのセキュリティキューへ直接移される。
Anthropicはこの制約について、異例なほど率直だ。モデルが人間によるトリアージなしに報告を生成するため、報告が誤っていたり無効だったりする可能性があるとしている。同社は、深刻度評価が過大になる場合もあると認めている。
深刻度は文脈に依存する。匿名のインターネットトラフィックにさらされるコードのメモリエラーは、認証の背後にある同じエラーとは異なる。権限の問題は、あるデプロイ環境では重大でも、別の環境では到達不能な場合がある。
ドキュメントが不完全な場合、モデルはこうした境界を誤解する可能性がある。Anthropicがプロジェクトに脅威モデルファイルの提出を推奨するのは、まさにこのためだ。それでもモデルは、その指針を形式的に検証されたポリシーとして適用するのではなく、解釈する。
重複した指摘もコストになる。Anthropicの97件の指摘に関する検証サンプルでは、11件が、すでに知られていた実際の問題か、別の場所で重複していた問題を表していた。重複報告にも有用な証拠は含まれうるが、メンテナーはそれを認識し、整理しなければならない。
報告量は、プロジェクトの注意力に対するサービス拒否問題にもなりうる。オープンソースコミュニティはすでに、低品質なAI生成バグ報告に不満を示している。正確な報告であっても、機能開発、リリース、サポート、既存のセキュリティ義務と競合する。
OSS Scannerは、オプトイン登録とメンテナーによる検証を通じてこのリスクを抑えている。また、検証済みの重大な指摘をすでに処理できるプロジェクトを対象にしている。こうした制御は望ましくない投稿を減らすが、プロジェクトが利用できるエンジニアリング時間を増やすわけではない。
このサービスの隔離モデルは、別の懸念にも対応している。スキャンエージェントはビルド段階の後、インターネットアクセスなしで動作する。報告は、アクセスを必要とするAnthropicのセキュリティ担当者が利用できる、制限付きクラウド環境に保存される。
ただしセットアップ段階では、依存関係の取得とプロジェクトのビルドのためにネットワークアクセスが依然として必要となる。プロジェクトのメンテナーは、安全で再現可能なDockerfileを提供しなければならない。ビルドスクリプトは環境によって異なる動作をしたり、利用できない外部サービスに依存したりすることがある。
Anthropicの公開登録リポジトリには、ローカル検証ツールとビルド確認ツールが含まれている。同社のドキュメントは、より強力な仮想マシン隔離なしでテストした場合、プロジェクトのDockerfileがローカルサービスへアクセスできると警告している。
この警告は重要だ。メンテナーはスキャナーの出力に注目するあまり、登録の仕組みを見落とす可能性がある。安全なセキュリティサービスは、分析対象のプロジェクトと、その設定準備に使うワークステーションの両方を保護しなければならない。
情報開示には、より微妙なリスクがある。Anthropicは、未検証の報告に対して公開期限を課していない。これは、Anthropic自身がレビューしていない主張でメンテナーに圧力をかけることを避けるためだ。
期限がないことは、修正対応が見えないままになる可能性も意味する。公衆は、どれだけの報告が受理、修正、却下、あるいは未解決のままなのかを容易には把握できない。Anthropicが求める帰属識別子は、部分的な可視性しか提供しない。
防御側と攻撃側の間には非対称性もある。対象となるプロジェクトは、Anthropicの最も強力なモデルによる非公開かつ継続的な分析を受けられる。攻撃者は依然として、ほかのモデル、ローカルツール、または独自の調査を使い、同じ公開ソースコードを調べられる。
このスキャナーがその差を縮められるのは、メンテナーが迅速に対応できる場合だけだ。過負荷の受信箱に置かれた正確な報告は、防御上の優位性をほとんどもたらさない。悪用が始まる前に、パッチをテストし、リリースし、導入しなければならない。
Anthropic自身によるGlasswingに関する報告では、高深刻度またはクリティカルな指摘のパッチ適用には平均で2週間かかったとされている。この企業報告の数値は、発見速度だけを唯一の成功指標にはできない理由を浮き彫りにしている。
より意味のある評価には、深刻度別の適合率、トリアージ時間の中央値、パッチ受理率、回帰率、下流での導入状況を含めるべきだ。また、新しい脆弱性を重複や既知の問題から分ける必要もある。
プロジェクトの多様性も結果に反映すべきだ。成熟したCおよびC++インフラでの性能は、分散サービス、暗号ライブラリ、データベース拡張機能、権限管理が複雑なWebアプリケーションでの性能を予測しない可能性がある。
このサービスはメンテナーの行動を変える可能性もある。チームは、スキャナーが脅威モデルを利用するため、脅威モデルをより明確に文書化するようになるかもしれない。より良いドキュメントは、AIエージェントだけでなく人間のレビュアーにも役立つ。
反対の結果もありうる。報告が完成度高く見えるため、チームがもっともらしいパッチを急いで受け入れてしまう可能性がある。再現手順と自信に満ちた説明は、レビューを支援すべきであり、代替すべきではない。
メンテナーは各報告を、十分に練られた調査の手がかりとして扱うべきだ。それでも独立した再現、コードレビュー、回帰テスト、露出評価が必要となる。高い深刻度ラベルには緊急性を与えるべきであり、自動的な信頼を与えるべきではない。
Anthropicの初期の証拠は、慎重な楽観論を支持している。このサービスは、受理された指摘、利用可能なパッチ、複数の重大なエクスプロイトチェーンを生み出してきた。その広範な信頼性は、登録対象が初期パートナーを超えて拡大した後の性能に左右されるだろう。
モデルが機能するかを示す3つのシグナル
次の試験は、OSS Scannerが、保護対象のプロジェクトを圧倒することなく、加速された発見を検証済みの修正へ転換できるかどうかだ。
第1のシグナルは、登録キューの構成である。Anthropicは普遍的なアクセスを約束しておらず、需要の変化に応じて適格性を調整できる。受理されたプロジェクトの数と種類が、このサービスの実用的な到達範囲を明らかにする。
基盤ライブラリの登録が増えれば、このプログラムが共有インフラを改善するというAnthropicの主張は強まる。十分な資金を持つプロジェクトがキューの大半を占めたとしても価値は生まれるが、小規模な依存関係は露出したままになる。
容量は需要と同じくらい重要になる。Anthropicは継続的なスキャンを約束しているが、その頻度はプロジェクト量やほかの要因により変動しうる。更新の速いリポジトリにとって、間隔が長ければスキャナーの価値は弱まる。
第2のシグナルは、大規模運用におけるメンテナー検証済みの適合率だ。Anthropicの97件の指摘サンプルは有用な出発点を示しており、初期の評価コメントは実行可能な報告の割合が高いことを示している。より大規模な公開測定がなお必要だ。
報告識別子は、その評価を支えうる。Anthropicは、どの指摘がコミットで帰属表記を受け、セキュリティアドバイザリとなり、あるいはパッチにつながったかを追跡できる。メンテナーも、過大な深刻度、重複、誤解を報告できる。
パッチ受理率の上昇は、このファストトラックモデルを強化する。スキャナーが実際の欠陥を見つけ続けたとしても、重複が持続的に多いことや、主張された深刻度と割り当てられた深刻度の大きな差は、このモデルを弱める。
適合率は、プロジェクトの種類と深刻度ごとに報告しなければならない。統合された平均値は、複雑なアーキテクチャにおける弱い性能を隠しうる。また、少数の重大なエラーに加えて多数の影響の小さい指摘を数えることで、スキャナーが正確に見えることもある。
第3のシグナルは、修正の処理能力だ。AnthropicがOSS Scannerを作ったのは、手作業のレビューが検出に追いつけなかったためである。同じ不一致は、登録された各プロジェクトの内部でも再現されうる。
有用な測定項目には、再現までの時間、パッチ作成までの時間、リリースまでの時間が含まれる。脆弱なバージョンにとどまる利用者は、リポジトリが修正されても保護されないため、下流での導入も重要だ。
プロジェクトは、セキュリティ担当者を増やしたり、テストを自動化したり、リリースプロセスを改善したりして対応するかもしれない。Anthropicは、報告の重複排除やパッチ検証に関する支援を拡大できる。こうした変化は、モデルが欠陥を発見した後に始まる作業に対処する。
競合各社の対応は比較をより明確にする。Ciscoの小型セキュリティモデルはローカルでの制御を優先し、エンタープライズプラットフォームは統合とガバナンスを重視する。Googleのファジングインフラは、再現性を重視した成熟したモデルを引き続き提供している。
単一のアプローチであらゆる脆弱性クラスを網羅することはできない。最も起こりそうな結果は、多層的なセキュリティである。既知の欠陥には依存関係スキャン、実行時の障害にはファジング、推論負荷の高いバグにはエージェント、そして最終判断には人間を用いる。
OSS Scannerの最も強力な発想は、AIがセキュリティ研究者を置き換えられるということではない。有能なメンテナーが緊急性のある可能性がある証拠を確認する前に、限られたレビュアーが必須の関門であり続けるべきではない、ということだ。
最大のリスクも同じ発想から生じる。関門がなくなると、受け取るすべてのプロジェクトが、何が本物なのか、何が重要なのか、そして何を安全に修正できるのかを判断する責任をより多く負うことになる。
開発者は、生の検出件数ではなく、このサービスが確認済みの成果に注目すべきだ。エンタープライズの購入者は、重要な依存関係が登録されているか、そしてパッチが実際にデプロイ済みのシステムへ届くかを問うべきである。メンテナーは、さらに別のレポートの流れを求める前に、自らのトリアージ能力を評価すべきだ。
Anthropic OSS Scannerが成功するかどうかは、発見からデプロイ済みの修正までの道のりを短縮できるかにかかっている。もしセキュリティのバックログを増やすだけなら、ボトルネックは解消されず、移動したにすぎない。どちらの結果が先に現れるかが、ソフトウェア業界が脆弱性研究にAIをどう活用するかを形作るだろう。
