バグ報告が新たな上限に達し、AppleとGoogleのセキュリティ格差が拡大

AI支援を受けた研究者が3週間で50件超のmacOSに関する潜在的な問題を生み出したことを受け、Appleはセキュリティ報告の受付件数に上限を設けた。この変更は、現代の脆弱性報奨プログラムにおける深刻な矛盾を浮き彫りにしている。AIは人間のチームが検証、優先順位付け、修正を行う速度を上回って、もっともらしい脆弱性を見つけられる。

報じられた制限には、割り当て件数に達した研究者に対する30日間のクーリングオフ期間が含まれる。研究者は追加の受付枠を申請できるが、その手続きにより、Appleが潜在的に緊急性の高い報告を受け取る前に、もう一つ判断の段階が加わる。Appleは標準の上限件数や承認基準を公表していない。

この緊張関係により、AppleとGoogleの比較はとりわけ有用になる。Googleは長年にわたり、テスト、再現、そして人間によるレビューでモデルを囲みながら、構造化された脆弱性研究にAIを組み込んできた。一方Appleは、セキュリティアップデートでAI支援による発見を評価しつつ、同じ変革の出力側をいまフィルタリングしている。

重要なのは、AIがセキュリティ研究に属するかどうかではない。すでに属している。より難しい問いは、機械が生成した発見が限られた人間の注意に値することを、誰が証明しなければならないのかという点だ。

Appleの新たな上限はトリアージ能力をセキュリティ境界に変える

Appleの報告件数上限は、脆弱性の受付を開かれた経路から計量制の経路へと変える。

当初の報道によると、Appleはセキュリティポータル経由の報告に上限と30日間のクーリングオフ期間を導入したことを認めた。より多くの受付枠が必要な研究者は、上限の引き上げを申請しなければならない。

報じられた変更は、イタリアのサイバーセキュリティ企業Bynarioによる異例の研究ラッシュに続くものだった。同社はmacOSの調査でChatGPTを使用し、3週間で50件を超える潜在的な問題を生み出したとされる。

報告された問題の一つは、攻撃者にMacの広範な制御を与え得るとBynarioが考えた権限昇格チェーンに関するものだった。しかし同社は、その問題を通常のポータル経由で送信する前に、報告件数の上限に達していた。

この主張は慎重に扱う必要がある。Appleは、報告されたチェーンを公に検証しておらず、CVEを割り当てたことも、その技術的影響を確認したこともない。したがってBynarioの評価は、確立された脆弱性評価ではなく、研究者による主張にとどまる。

それでもこの事例は、現実的な受付上の問題を示している。時折発生する労働集約的な発見を前提に設計されたシステムが、短期間のキャンペーンで数十件の手掛かりを生み出せる研究者に直面している。

Appleの現行の報奨金ガイドラインは、品質の基準を明確にしている。報告には、明確な説明、信頼できる概念実証、再現手順、そして現実世界でのセキュリティ影響を示す証拠が必要だ。

ガイドラインはまた、長文のAI生成説明を避けるよう研究者に求めている。Appleは、適切な検証を欠く理論上のAIによる発見を、その提示が技術的に洗練されて見える場合でも対象外としている。

こうした報告を繰り返し提出すれば、結果を伴う。Appleは、実現不可能または未検証の発見を研究者が繰り返し送付した場合、処理を180日間停止できるとしている。停止期間が2回を超えると、恒久的な除外につながる可能性がある。

これらのルールは、報告がシステムに入った後の品質に対処するものだ。上限は、Appleが内容を確認する前のアクセスを制御する。この違いは、ある研究者が複数の有効な発見を持つ場合や、上限に達した後で重大な問題を発見した場合に重要になる。

セキュリティポータルは、単なる事務的な受信箱ではない。発見から修正までを結ぶ防御経路の一部である。この経路内の遅延は、有効な脆弱性が攻撃者に利用可能な状態にある期間を延ばし得る。

Appleは、上限引き上げの申請を通じて制限を回避する経路を提供している。しかし公開情報では、申請に対する判断がどれほど迅速に下されるのか、また何の証拠が上限引き上げにつながるのかは説明されていない。

この詳細の欠如は、独立研究者に不確実性を生む。研究成果の多い1週間によって、最も重大な発見が届く前にアクセス枠を使い切るかどうかを、容易には予測できない。

この上限は研究者のインセンティブも変える。研究者は、複数の発見を統合したり、弱い報告を保留したり、Appleが見る前に発見を順位付けしたりするかもしれない。これはシグナルの向上につながり得るが、重要なトリアージ判断をAppleの外部へ移すことにもなる。

一部の研究者は、その判断を慎重に行うだろう。他方で、深刻度を誤り、無関係なバグをまとめ、あるいはポータルへの不満から公表に踏み切る者もいるかもしれない。どの結果も異なるセキュリティリスクを生む。

Appleは、受理された報告の大半を90日以内に解決するとしている。この目標は、すでに受領した報告を対象とするものであり、上限やアクセス審査のために待機している発見は含まれない。

したがって、報じられた方針は本稿の中心的なトレードオフを生む。Appleには自動化されたノイズから身を守る必要があるが、そのフィルターが検証済み研究の障害となってはならない。

AI生成のバグ報告が人間のレビューを圧迫する理由

AIは、もっともらしい発見を生み出すコストを下げた一方で、それを証明するコストは下げていない。

現代の言語モデルは、ソースコードを調べ、未知のインターフェースについて推論し、エクスプロイト仮説を作成し、洗練された技術文書を生成できる。こうした能力により、熟練した研究者は同じ期間内により多くの経路を探索できる。

同時に、経験の浅い利用者も、不確かなモデル出力を説得力のある報告に変えられる。根底にある挙動が一度も再現されていなくても、形式が厳密さの印象を生むことがある。

セキュリティトリアージチームは、その見かけを額面通りに受け取ることはできない。影響を受けるコンポーネントが実在するか、挙動が意図されたものか、攻撃者がそこに到達できるかを判断しなければならない。

さらに、製品バージョン、セキュリティ境界、重複報告、過去の社内作業も確認する必要がある。生成に数分しかかからない報告でも、エンジニアリングレビューには何時間も要する場合がある。

誤検知は無害ではない。裏付けのない主張は、実際の利用者に影響する悪用可能な条件を記述した報告と競合する。キューはセキュリティ資源の配分問題となる。

Apple自身のルールは、欠けている要素が人間による検証であると示している。同社のプログラム規約は、人間のレビューを伴わないAI支援で生成された反復的なスパムや虚偽の主張を禁じている。

この文言はAIツールを禁止するものではない。結果を提出する人物に責任を負わせるものだ。研究者は問題が存在することを示し、攻撃者が何を得られるのかを説明しなければならない。

概念実証、すなわちPoCは、主張された挙動を示すコードまたは再現可能な手順である。モデルの仮説を、別のエンジニアが検証できる証拠へと変換する。

再現だけでは、常にセキュリティ影響を立証できるわけではない。ソフトウェアがクラッシュしても、データの露出、権限境界の突破、あるいは攻撃者への意味のある制御の付与につながらない場合がある。

この違いは言語モデルにとって難しい。モデルは脆弱性に関連するパターンを認識できる一方で、コードを取り囲む保護機構を誤解することがある。

たとえば、見かけ上の権限回避は、利用者が意図的にアクセスを許可した後にしか発生しないかもしれない。不審なデータフローも、既存のサンドボックス内に閉じ込められたままである可能性がある。

セキュリティプログラムは、キーワードではなく文脈を調査しなければならない。攻撃者の開始時点、必要な利用者操作、到達可能な資産、そして最終的に得られる能力を把握する必要がある。

AIは重複発見も増やす。複数のモデルが同じリリースを調査し、似たコードパターンを優先し、一つの根本的欠陥の異なる表現を報告する可能性がある。

Appleの7月のOSアップデートは、この重複を示していた。謝辞では、関連コンポーネントにまたがる複数のAIツールや研究グループが評価される一方、いくつかのカーネル問題には複数の報告者がいた。

重複報告も時間を消費する。エンジニアは発生条件を比較し、二つの提出が一つの根本原因を表すのか、それとも別々のエクスプロイト経路を表すのかを判断しなければならない。

経済的な不均衡は明白だ。報告の生成は自動化されつつあるが、検証は依然として経験豊富なエンジニアに大きく依存している。受け取る組織が、その検証コストの大半を負担する。

これが、業界全体で上限が現れつつある理由だ。機械規模の生成と人間規模の判断との非対称性に対する直接的な対応である。

ただし、生の件数は品質の不完全なシグナルだ。自動化を活用する慎重なチームは多くの有効な発見を生み出せる一方、洗練された一件の報告が完全に推測にすぎないこともある。

より良いシグナルは、検証密度だ。プログラムは、研究者の報告がどの程度の頻度で再現され、定義された境界を越え、セキュリティ修正につながるかを測定する必要がある。

Appleはすでに、このアプローチのためのインフラを一部備えている。Target Flagsは、選定された脆弱性カテゴリ向けにAppleプラットフォームへ組み込まれた、機械検証可能なアーティファクトだ。

関連するフラグを取得した研究者は、実行の制御や保護されたメモリといった、定義された能力を示す。Appleは、文章による主張よりも迅速にこの証拠を検証できる。

Target Flagsはすべてのカテゴリを対象にしているわけではない。また、根本原因、影響を受けるバージョン、考えられるエクスプロイトチェーンを理解するための作業を不要にするものでもない。

それでも、より良い受付モデルへの方向性を示している。提出プロセスが、機械と人間の双方が効率的に検証できる証拠を要求すれば、AIは発見を拡張できる。

AppleとGoogleのセキュリティモデルは異なる種類の規模を評価する

AppleとGoogleの対比は、開放性と制限の対立ではない。非構造的な件数と、計測可能な発見との対比である。

Googleは、実行ツール、ファザー、再現可能な検証で大規模言語モデルを囲みながら、脆弱性研究に活用してきた。同社のプロジェクトは、証拠がワークフローの一部である場合のAI支援による発見の姿を示している。

Google Project ZeroとGoogle DeepMindは、脆弱性研究向けAIエージェントとしてBig Sleepを開発した。このシステムは、脆弱性が正式リリースに到達する前に、SQLiteの悪用可能なスタックバッファアンダーフローを発見した。

開発者は、Googleから報告を受けたその日のうちに問題を修正した。それでもGoogleは、この結果を実験的なものと説明し、ターゲット固有のファザーでも同様に有効だった可能性があると述べた。

この慎重さは重要だ。Big Sleepは、単に説得力のある説明を生成したわけではない。実際のソフトウェアで具体的な挙動を発見し、証拠を提示し、その発見を協調的な修正プロセスへ渡した。

GoogleのBig Sleepに関する研究も、モデルへのアクセスはシステムの一部にすぎないと位置付けていた。このエージェントには、証拠を収集し、自らの推論を検証できるツールが与えられていた。

GoogleのOSS-Fuzzの取り組みも同様のパターンに従う。ファジングは、通常とは異なる入力をソフトウェアに自動で与え、プログラムのクラッシュや安全でない挙動を監視する。

言語モデルは、こうしたファズターゲットの生成と改善を支援した。Googleは、生成されたテストを実際のソフトウェアに対して実行した結果、OpenSSLのものを含む26件の脆弱性が見つかったと報告している。

AIファジングプログラムは、モデルの不審な応答すべてを脆弱性として扱ったわけではない。コンパイル、実行、クラッシュのトリアージ、根本原因分析は、引き続きプロセスの一部だった。

この構造は、メンテナーが受け取るシグナルを変える。コードが危険に見えると述べる文章ではなく、受信者は特定の入力に結び付いた観測可能な障害を受け取る。

これはGoogleが誤検知の影響を受けないことを意味するわけではない。自動テストでは、セキュリティ上の影響を伴わないクラッシュも検出されうるほか、複雑な環境では誤解を招く結果が生じる可能性もある。

このアプローチでは、検証が発見の工程により近づく。これにより、裏付けのない仮説が別の組織の人間によるトリアージチームに届く可能性を下げられる。

Appleは、異なる管理手段を通じて類似の目標を追求している。同社のバグ報奨金プログラムでは、外部研究者に対し、動作するエクスプロイト、信頼性の高い再現手順、利用可能な場合はTarget Flagsの提出を求めている。

違いは、それぞれのシステムがどこで規模を吸収するかにある。Googleの公開された研究事例では、管理された実験パイプライン内にモデルを組み込んでいる。一方、Appleのポータルは、管理されていない世界中の人々からの報告を受け付ける。

そのため、AppleとGoogleを単純に順位付けして比較するのは誤解を招く。Googleは、報告が自社環境を出る前に、内部エージェント、対象、証拠要件を調整できる。Appleは、外部研究者がどのツールを使うかを制御できない。

ただし、Appleは提出プロトコルを管理できる。一律の上限は選択肢の一つにすぎず、おそらく最も情報量の少ない方法でもある。

より強力なポータルでは、攻撃者の開始時点、影響を受けるバージョン、侵害された境界、再現率、最終的に得られる能力について、構造化された主張を求められるだろう。

隔離環境内で安全な概念実証を実行することも可能だ。また、セキュリティエンジニアに割り当てる前に、重複報告をクラスタリングすることもできる。

一貫して再現可能な発見を報告する研究者には、より大きな上限を自動的に付与できる。新規アカウントは、手動の申請ではなく、検証済みの提出を通じて受け付け枠を獲得できる。

AppleのTarget Flagsは、すでに一部のカテゴリーでこのモデルの基盤を提供している。適用範囲を拡大すれば、提出可能量を検証可能な結果に結び付けられる。

Googleの経験は、モデルが発見だけでなくトリアージにも役立つべき理由を示している。AIシステムは新規報告を既知の問題と比較し、再現手順を抽出し、不足している証拠を特定できる。

Appleは、すべての報告をレビューするとしている一方、自動化システムは案件の優先順位付けに役立ちうる。報告が複雑なセキュリティ境界に影響する可能性がある場合には、人間の判断が引き続き必要となる。

したがって、AppleとGoogleの比較から得られる有用な教訓は運用面にある。AIによる発見は、ワークフローが同時に検証コストを下げる場合に最も効果を発揮する。

上限は入力の量を抑制する。証拠パイプラインは入力の平均的な価値を高める。Appleにはおそらく両方が必要だが、そのバランスが研究者の信頼を左右する。

GitHubとcurlが示す、業界全体に広がる受付危機

Appleの上限は、商用およびオープンソースソフトウェア全体で、無制限の脆弱性報告受け付けから後退する広範な動きの一部だ。

GitHubは、低労力かつAI生成の報告が増え、キューが拡大したことを受け、2026年7月にバグ報奨金プログラムを再編した。同社は、公開経路と招待制経路を分離した。

確立されたHackerOne上の実績がない新規研究者には、実績を示すための4件の提出枠が与えられる。GitHubは、この上限でも真剣な新規参加者が能力を証明するには十分な余地があるとしている。

同社のバグ報奨金プログラム再編は、2026年7月27日以降に提出された報告に適用される。GitHubは、規則を遡及的に変更するのではなく、それ以前の報告については従来の体制を維持した。

同社が掲げる原則はAppleのものと非常に近い。AIの利用自体が問題なのではない。専門家によるレビュー時間を消費する未検証の出力が問題なのだ。

GitHubは、有効な報告とは簡潔で、再現可能で、実際のセキュリティへの影響と結び付いているものだと説明している。また、関連する証拠を埋もれさせる理論的な叙述を削除するよう研究者に求めている。

GitHubに影響する規模は、同社の報奨金プログラムにとどまらない。プラットフォーム上の非公開脆弱性報告は、1月の週約550件から、5月の大半の期間には週3,000件超へと増加した。

5月には、GitHub Advisory Databaseがレビュー済みのアドバイザリ1,560件を公開した。GitHubによれば、この合計は通常の月間公開数の5倍を超えたが、それでも流入する需要には追い付かなかった。

これらの数字は、エコシステム全体におけるボトルネックを示している。レビューと修正の能力には制約があるため、発見件数の増加が自動的に保護の迅速化へつながっているわけではない。

オープンソースプロジェクトは、同じ不均衡にさらに厳しい形で直面する。専任のトリアージ担当者、再現可能なテスト環境、継続的なレビューのための予算が不足していることが多い。

curlは、メンテナーがAI生成報告の持続不可能な殺到を説明した後、2026年初頭にバグ報奨金を終了した。同プロジェクトは7月中、脆弱性開示チャネルも停止した。

現在の開示ポリシーでは、投稿者に対して、大量のAI生成説明をそのまま貼り付けないよう求めている。報告は理解しやすいものでなければならず、プロジェクトの協調的開示プロセスを尊重する必要がある。

curlは8月3日に脆弱性報告の受け付けを再開した。この停止は、受付への圧力が広く導入されているソフトウェアコンポーネントの報告経路を一時的に閉鎖しうることを示している。

この結果は、選別的な上限よりも悪い。開示チャネルが完全に閉じられると、研究者は待つか、別の連絡先を探すか、未開示の脆弱性を保持しなければならない。

メンテナーは心理的な負担にも直面する。誤った主張が繰り返されると、レビュー担当者はノイズを予期するようになり、有効だが不完全な報告を軽視するリスクが高まる。

セキュリティコミュニティは以前にもこのパターンを経験している。静的解析ツールや自動スキャナーも、大量の低信頼度アラートを生み出してきた。

組織は、再現、深刻度の文脈、担当者情報を求めることで対応した。AIは、説得力のある文章や想定エクスプロイトの説明を追加できるため、同じ問題を拡大させる。

したがって、新世代の管理策はスパムフィルタリングに似ている。評判、レート制限、構造化された証拠、自動クラスタリングはすべて、オープンなチャネルを利用可能な状態に保つ助けとなる。

セキュリティ報告は、まれな有効メッセージが極めて重要になりうるため、通常のスパムとは異なる。厳格な誤検知フィルターは、ベンダーが最も必要とする報告そのものを抑制しかねない。

そのため、透明性が不可欠だ。研究者は、残りの提出可能量、不受理の理由、上限拡大に必要な証拠を把握できるべきである。

また、高信頼度の発見に対する緊急経路も必要だ。この経路ではより強い証拠を求めるべきだが、一般的なクールダウン期間を待つことに依存すべきではない。

プログラムは、すべての新規研究者を疑わしい存在として扱うことなく、推測的な提出を抑制できる。サンドボックス化された再現と機械検証可能な成果物は、評判だけよりも客観的なゲートを提供する。

GitHubの公開経路は、新規参加者に明確な回数の機会を与える。Appleの報じられたプロセスは、デフォルトの上限とエスカレーション基準が公開されていないため、依然として不透明だ。

この情報格差はいまやリスクの一部となっている。隠されたルールは、正当な研究者にとって計画を立てにくく、より広いコミュニティにとって評価もしにくい。

Appleの上限はノイズを阻止できても、実際の脆弱性を遅らせる可能性がある

中心的なリスクは、AppleがAI出力を拒否することではない。件数上限が生産性を乱用と取り違える可能性があることだ。

Bynarioの報じられた経験は、この懸念を捉えている。同社は数十件の潜在的な問題を発見し、Appleの上限に達した後、重大な権限昇格チェーンとみなしたものを特定した。

技術的な主張は独立して検証されていない。Appleによる検証または公開アドバイザリがない限り、その報じられた価値や深刻度を確立した事実として扱うべきではない。

それでも、この経緯は一律上限の弱点を示している。未解決の報告件数に基づく上限では、次の提出が些細なものか、重複か、緊急性を要するものかを判断できない。

Bynarioの初期の発見が不完全だったなら、この方針は意図どおり機能しうる。同社に検証と優先順位付けを求めることで、Appleのエンジニアリング時間を節約できるからだ。

一方、複数の報告が有効で、後に見つかったチェーンの影響がより大きかった場合には、回避可能な遅延を生む可能性もある。公開されている証拠だけでは、どちらの解釈が正しいかはまだ判断できない。

Appleには慎重さを求める強い理由がある。同社の2025年10月の報奨金発表によれば、同社は23億5,000万台を超えるアクティブデバイスをサポートしている。

広く使われるAppleコンポーネントに影響する脆弱性は、iOS、iPadOS、macOS、watchOS、tvOS、visionOSにまたがる作業を生む可能性がある。単一の根本原因に対して複数の協調リリースが必要になることもある。

同社は2025年後半にバグ報奨金プログラムを拡大し、孤立した理論上のバグよりも完全なエクスプロイトチェーンを重視した。また、迅速な検証のためにTarget Flagsも導入した。

Appleのバグ報奨金プログラム拡大では、2020年に公開プログラムを開始して以来、研究者に3,500万ドル超を支払ったとしている。800人超の研究者が報奨を受け取った。

これらの事実は、Appleが門戸を閉ざしているという単純な主張を複雑にする。同社は、実証された影響を欠く報告へのアクセスを厳格化する一方で、高度な研究へのインセンティブを拡大している。

この方針は、セグメンテーションとして理解するのが最も適切だ。Appleが求めているのは、深く検証されたエクスプロイト研究であり、機械生成された疑念の無制限な流入ではない。

懐疑的な問いは、その実装がこの違いを十分に早く識別できるかどうかだ。Appleが迅速にレビューしなければ、上限引き上げの申請は別のキューになる。

評判システムは、既存のアクセス格差を強化する可能性もある。確立された研究者はプログラムの期待を理解しており、直接の連絡先を持つことも多いが、新規参加者はポータルに依存する。

新規研究者が有効な発見を持っていても、エクスプロイトとして適切にまとめる経験が不足している場合がある。モデルは問題の説明を支援できるが、その支援が報告の信頼性を低く見せる可能性もある。

Appleは、AIらしい文章を無効性の代理指標として使うことを避けなければならない。文体では、脆弱性が再現するか、意味のある境界を越えるかを立証できない。

最も安全なフィルターは証拠を評価するものだ。AIが発見や記述を支援したかどうかにかかわらず、信頼できる概念実証を伴う簡潔な報告は注目を受けるべきである。

研究者側にも責任がある。各発見を再現し、推測的な主張を削除し、観測可能な挙動とモデルの解釈を分けるべきだ。

正確なセキュリティ境界を特定し、攻撃者が最終的に得られる能力を説明すべきである。候補をすべて提出することは、未完成の研究のコストをベンダーに転嫁する行為になる。

機械の速度で発見を生み出すチームには、自らの内部トリアージも必要だ。重複をクラスタリングし、現行リリースをテストし、実証された影響に基づいて問題を順位付けすべきである。

検索可能なエンジニアリングナレッジベースは、テスト証拠、影響を受けるバージョン、過去の報告を保持できる。この記録は、研究者が重複または矛盾する提出を避ける助けとなる。

ベンダー側も、より明確なステータス情報で応えるべきだ。研究者は、Appleが事例を再現したのか、既存の作業と結び付けたのか、追加の証拠を必要としているのかを知る必要がある。

より良いコミュニケーションは、繰り返しの報告や、解決済み案件を再開しようとする繰り返しの試みを減らすだろう。また、上限に関する判断を恣意的に見えにくくする。

検証が私的な判断ではなく共有プロトコルになれば、AppleとGoogleの隔たりは縮まる。発見者と受領者の双方に、主張とともに移動する証拠が必要だ。

Appleが適切なバランスを見つけたかを示す3つのシグナル

次の試金石は、Appleが緊急の受付管理策を、透明で証拠に基づくシステムへ転換できるかどうかだ。

最初のシグナルは、明確な上限ルールの公開だ。Appleは、未解決の報告がどのように上限に算入されるのか、上限がどれほど早くリセットされるのか、研究者がどのようにより多くの提出枠を得るのかを説明すべきである。

この情報は、上限が調整された防御策であるという根拠を強めるだろう。曖昧さが続けば、正当な研究者が依然として予測不能なアクセスに直面していることを示唆する。

第2の兆候は、機械で検証可能な証拠の利用拡大だ。Appleは、Target Flags、安全な再現環境、その他の構造化されたチェックを、より多くの脆弱性カテゴリーに拡張できる。

拡張が成功したかどうかは、Appleが参加を単に減らすことなくトリアージコストを削減しているかに表れる。主に手作業による例外処理に依存するポータルであれば、その結論は弱まる。

第3の兆候は、今後のリリースサイクルにおける大量報告を行う研究者への対応だ。セキュリティアドバイザリは、AI支援チームが検証済みの発見に対して引き続きクレジットを得ているかを示すだろう。

Appleの2026年7月のリリースではすでに、Anthropicの研究者、Claude、OpenAI Codex Security、Z.AIのGLM、NVIDIAのAI Red Teamにクレジットが付与されている。この実績は、Appleが確認済みの修正につながる限り、AI支援による作業を受け入れていることを示している。

今後の謝辞は、この上限がその生産的な経路を維持するかどうかを示すだろう。独立研究者へのクレジットが急減すれば、過剰なフィルタリングを示す可能性がある。ただし、クレジットだけで因果関係を証明することはできない。

Google、GitHub、大規模なオープンソースプロジェクトは、有用な比較対象となる。これらのプログラムも、構造化された証拠、研究者の評価、受け付け件数の制限へと移行している。

その結果は、バグバウンティの枠を超えて重要になる。AIシステムは、コード提案から自律的なテスト、エクスプロイト、トリアージ、修復へと進化している。

発見のスピードは今後も上がり続ける。人間のセキュリティチームは、到着順にレポートを処理するだけでは、そこで生じるキューを解消できない。

必要なのは、悪用可能性を可視化し、重複した発見を統合し、影響の大きいケースを迅速に振り分けるプロトコルだ。また、通常の上限を使い切った後も開かれている緊急経路も必要になる。

研究者は、今後1〜3か月の間にAppleのガイドラインが改訂されないか注視すべきだ。また、限られた提出枠を使う前に、再現手順をすべて記録しておくべきである。

エンタープライズのセキュリティチームも、社内で同じ課題に直面している。AIスキャナーは開発者が調査できる数を超えるアラートを生成し得るため、導入指標は確認済みリスクの削減を評価する必要がある。

発見件数を数えると、量が促される。再現可能な脆弱性、完了した修正、露出の減少を数えると、有益なセキュリティ作業が促される。

これがAppleとGoogleの比較から得られる持続的な教訓だ。勝つセキュリティプログラムは、AIが最も多くの潜在的なバグを指摘するプログラムではない。

検証済みの発見を、最も少ない無駄で発見から修復へ移せるプログラムだ。Appleの上限は時間を稼ぐが、その後を決めるのは証拠に基づく受け付けでなければならない。

研究者にとって、直近の行動はシンプルだ。提出前に検証し、テスト成果物を保全し、侵害されたセキュリティ境界を明確に記述すること。ベンダーにとっての責務も同様に直接的だ。こうしたチェックを通過する証拠のために、信頼できる経路を開いたままにすることである。

Appleはより明確な上限制度を公表し、機械で検証可能な提出を拡大するのか。それとも研究者は、上限に達した後でしかルールを知ることができないのか。その答えは、この上限がAppleのトリアージチームを守るのか、それとも単にボトルネックを移し替えるだけなのかを示すだろう。