AIによるバグ報告の殺到でAppleが対応、AppleとGoogleのセキュリティの隔たりが拡大
自動化された脆弱性発見の価値が高まる一方、AI支援のバグ報告がセキュリティ受付プロセスを圧迫し始めたことを受け、Appleは新たな制限を導入した。AppleとGoogleのセキュリティの隔たりは今、より大きな矛盾を浮き彫りにしている。AIは潜在的な欠陥をより速く特定できるが、ベンダーはどの報告に緊急対応すべきかを自動的に判断できない。
報道によれば、Appleは2026年6月に提出件数の上限と30日間のクーリングオフ期間を導入した。上限に達した研究者は、Appleのセキュリティポータルを通じてより高い枠を申請しなければならない。同社は標準の上限、報告件数、却下率、審査バックログの規模を公表していない。
一方Googleは、AIによる脆弱性調査を防御側の力を増幅する手段として位置付けている。同社のBig Sleepエージェントは未発見のソフトウェア欠陥を見つけているが、開示は引き続き人間の専門家が監督している。この対比は、単にApple対Googleという構図ではない。AIセキュリティプログラムが、発見能力と同じ速度で判断能力も拡張できるかを問う試金石だ。
Apple、バグ対応パイプラインの入口にゲートを設置
Appleの新たな制限は、脆弱性の発見が同社の既存の受付管理能力を超えたことを認めるものだ。
報じられた変更は、Appleの内部セキュリティポータル経由の提出に影響する。上限は1人の研究者が提出できる報告数を制限し、クーリングオフ期間は直後の追加提出を阻止する。研究者はAppleに追加の受付枠を求められるが、そのためにはさらに審査の段階を経る必要がある。
Appleの公開文書はすでに、AI生成コンテンツへの懸念の高まりを示している。同社の報奨金ガイドラインは、AIツールが生成した長文の説明を避けるよう研究者に求めている。また、適切な人間による検証を欠く理論上の問題やAIが発見した問題も対象外としている。
この区別は重要だ。AIモデルは、攻撃者が実際に到達できることを証明せずに疑わしいコードを特定できる。また、テストを行うと破綻するもっともらしい説明を作り出すこともある。セキュリティチームは挙動を再現し、悪用可能性を評価し、重複を探し、影響範囲を見積もり、修正を調整しなければならない。
したがって、誤った報告を含め、すべての提出には審査コストが伴う。体裁の整った無効な報告は、明らかに不完全な報告よりも多くの時間を消費しかねない。レビュアーは、自信に満ちた表現と技術的証拠を切り分ける必要がある。
Appleによれば、不適格な報告を繰り返し提出すると、180日間の処理停止につながる可能性がある。停止期間が2回を超えると、報奨金プログラムから永久に除外されることがある。規約では、誤りまたは未検証のAI支援による主張を大量に提出するパターンも、許容できない行為としている。
こうした方針はスパム抑止を目的としている。新たな上限は、Appleが個々の報告を判断する前に件数を制限するため、さらに踏み込んだ措置だ。これは最終的な品質判断ではなく、緊急時の受付管理策といえる。
この仕組みは、キューの増大をすばやく抑えられる。一方で、有効な発見を数多く行う研究者も、推測的なモデル出力を提出する人とほぼ同じように扱うことになる。Appleは例外を認めることができるが、その基準や想定される回答時間を説明していない。
ここには重大な例外ケースがある。ある研究者が集中監査の中でAIを使い、独立していて再現可能な複数の脆弱性を発見するかもしれない。その研究者が上限に達した場合、攻撃者が同じコードを調査する間にも、有効な報告はクーリングオフ期間中待たされる可能性がある。
Appleは、このような事例が発生したとは述べていない。また、上限が重大な開示を遅らせた証拠も公表していない。それでもこの可能性は、割り当て枠が粗いフィルターである理由を示している。
同社のセキュリティ上の影響範囲は、この問題をとりわけ重大なものにしている。Appleによれば、同社の技術は23億5,000万台を超えるアクティブデバイスを保護している。共有コンポーネントの欠陥は、膨大な導入基盤にわたるスマートフォン、タブレット、コンピュータ、腕時計、サービスに影響し得る。
Appleのプログラムは、高度なエクスプロイトチェーンに対して多額の報奨金も提示している。同社は、2020年に公開プログラムを開始して以降、800人を超える研究者に3,500万ドル以上を支払ったとしている。これらの数字は、報告がキューに入る方法を制限する一方で、Appleが外部研究を引き続き重視していることを示唆する。
重要な変化は、Appleが低品質な報告を却下していることではない。成熟した報奨金プログラムなら、どこでもそうする。Appleは、受付件数そのものに制限が必要になったことを認めたのだ。
AIによるバグ報告が、時間を節約する前に作業を増やす理由
AIは疑わしい挙動を見つけるコストを下げるが、セキュリティへの影響を立証するために必要な高コストの作業をなくすわけではない。
従来の脆弱性調査には自然な制約がある。研究者は対象を理解し、コードやシステムの挙動を調べ、テストを設計し、概念実証を開発しなければならない。こうした工程には時間がかかり、提出件数を抑制する。
AIエージェントは、そのプロセスの一部を圧縮する。多数のファイルを調べ、テストハーネスを生成し、入力を変異させ、実行経路を追跡し、エクスプロイト仮説を提案できる。複数のエージェントを、同じ公開コードベースに対して並行して実行することも可能だ。
これにより、2種類の規模拡大が生まれる。生産的な規模拡大は実際の脆弱性をより多く生み出す。無駄な規模拡大は、重複、到達不能なクラッシュ、想定内のエラー、実用的な攻撃経路のない技術的には正しい観察を生み出す。
どちらも同じキューに入ってくる。
概念実証とは、定義された条件下で報告された挙動を示す、再現可能なデモンストレーションである。Appleは研究者に対し、動作するエクスプロイトまたは信頼できる概念実証を求めている。また、攻撃者が回避するセキュリティ境界の説明も期待している。
この要件は多くの弱い発見をふるい落とすが、生成AIは完全な報告の形式を模倣できる。技術用語、コード断片、影響に関する主張、修正提案を提示できる。しかし、それらの要素のどれも、問題が実在する保証にはならない。
人間のレビュアーは証拠を検証しなければならない。また、別の研究者が異なる症状を通じて、同じ根本的な欠陥を提出していないかを判断する必要もある。多数のエージェントが同じコードを独立してスキャンする場合、この重複分析はさらに難しくなる。
GitHubは、より広範な件数変化について異例なほど明確な証拠を公表している。同社プラットフォーム全体の非公開脆弱性報告は、2026年1月の週約550件から、5月の大半で週3,000件超へと増加した。同社のアドバイザリーチームは同月、審査済みアドバイザリを1,560件公開し、通常の出力の5倍を上回った。
それでもGitHubは、この記録的な処理速度が追いつかなかったとしている。脆弱性の急増に関する同社の説明は、審査を高速化するだけでは、無制限の受付を解決できないことを示している。
中心的なボトルネックは判断だ。セキュリティチームは、どの報告が到達可能で悪用可能な条件を表すのか、どの報告が単に異常なプログラム状態を記述しているだけなのかを判断しなければならない。この作業には、アーキテクチャ、デプロイ、緩和策、攻撃者の能力に関する知識がしばしば求められる。
AIはこうした判断を支援できるが、自動システムに報告を却下させることには別のリスクがある。モデルは、過去の誤検知に似ているという理由で、見慣れないエクスプロイトを退ける可能性がある。新規の発見が自動フィルターの中に埋もれれば、攻撃者に有利に働く。
そのため、ベンダーチームは非対称な誤りの問題に直面する。誤った報告を受理すればレビュアーの時間を浪費する。本物の脆弱性を却下すれば、ユーザーが危険にさらされる可能性がある。
提出上限は流入量を減らすことで、前者のリスクを管理する。もっとも、信頼できる研究者を遅らせる場合には後者のリスクを悪化させ得る。より優れたシステムは、件数が乱用と同義だと決めつけずに、証拠の品質を評価する必要がある。
有用なシグナルには、再現可能性、到達可能な攻撃経路、サニタイザー出力、影響を受けるバージョン、エクスプロイトの前提条件、明確なセキュリティ上の影響が含まれる。研究者の実績は役立つが、新規参入者を恒久的に排除すべきではない。確立された研究者も、かつては皆無名だった。
この事例が示すAIバグ報告は、通常のサポートチケットではない。そこには価値ある発見と、説得力のある虚構の両方が含まれ得る、信頼されていない技術的主張だ。Appleのキュー問題は、これらのカテゴリーを見分けるコストを反映している。
AppleとGoogleのモデルの分岐点は、発見ではなく検証にある
AppleとGoogleの対比は実際には、AI支援セキュリティパイプラインのどこに検証を置くかをめぐる見解の相違だ。
GoogleのBig Sleepは、Google DeepMindのモデルとProject Zeroの脆弱性専門知識を組み合わせている。このエージェントは未知の欠陥を探索するが、Googleの公開プロセスでは外部への開示前に人間による監督が維持されている。
Googleは2025年、Big SleepがCVE-2025-6965として追跡される重大なSQLite脆弱性を発見したと発表した。同社によれば、脅威インテリジェンスは、攻撃者がこの欠陥を把握しており、悪用の準備を進めていることを示唆していた。
この主張はGoogleによるものであり、同社の評価として扱うべきだ。それでも、AI支援による発見の最良のケースを示している。エージェントが高い影響を及ぼす欠陥を十分に早期に発見し、防御側が介入できるようにする。
Googleは後に、Big Sleepがオープンソースソフトウェアで発見した最初の20件の脆弱性群を報告した。専門家がメンテナーに報告する前に発見内容をレビューした。このレビュー段階により、メンテナーが生のモデル推測を受け取る可能性が下がった。
GoogleのBig Sleepの概要も、人間による監督と確立された開示手順を強調している。同社は、自律的な発見を自律的な大量提出の許可として提示しているわけではない。
これにより、受け取る側にとってより明確なインターフェースが生まれる。Googleは、自社の研究プログラム内で最初の検証を引き受ける。メンテナーは、すでに専門家の確認を通過した発見を受け取る。
Appleのポータルは、そのインターフェースの反対側にある。調査手法、ツール、動機、スキルレベルが大きく異なる独立研究者からの報告を受け入れている。Appleは、すべての送信者が同等の検証を実施したとは想定できない。
したがって、一見したAppleとGoogleの隔たりには重要な構造的差異がある。GoogleはBig Sleepのワークフローを管理している。Appleは、外部研究者が自社製品に向けるエージェントを管理していない。
それでもGoogleのモデルは有用な基準を示す。AIによる発見は、エージェントを運用する当事者が結果を検証する責任も負う場合に最も効果を発揮する。生の発見を送ることは、スキャンを実行する選択をしていないメンテナーにそのコストを移転する。
報奨金が利用可能な場合、この基準の徹底はより難しくなる。自動化により、研究者はより多くの対象を調査し、より多くの報告を提出できる。それは価値ある作業を生み出し得るが、提出件数に基づくくじ引きのような戦略も促しかねない。
Appleの規則は、そのインセンティブに対抗しようとしている。報告は完全で、実行可能で、悪用可能であり、最初に提出されたものでなければならない。同社は、信頼できる再現経路を欠く発見や、実現不可能なシナリオを記述する発見を対象外としている。
しかし、上限が測るのは品質ではなく数量だ。Googleのプロセスは提出前の検証に重点を置く。Appleの緊急管理策は、検証前の提出を制限する。
最も強力な将来のシステムは、両方の考え方を組み合わせるだろう。研究者は機械で検証可能な証拠を提供し、ベンダーは自動クラスタリングと再現ツールを使う。人間の専門家は、新規の発見と影響が曖昧な案件に集中する。
そのプロセスで人間を完全に排除することはできない。脆弱性の深刻度は、展開パターン、権限、緩和策、連鎖的な攻撃機会などの文脈に左右される。モデルはこうした要因を分析できるが、その結論には依然として説明責任を伴うレビューが必要だ。
Googleも、人間だけではこのペースについていくのが難しいことを認めている。同社のCodeMenderプロジェクトは、AIで脆弱性を発見・修復し、自動化を発見段階の先へ進めることを目指している。専門の批評エージェントが、最終的な人間の承認前に提案されたパッチをレビューする。
これはAppleにとっての真の競争圧力を示している。発見の高速化には、受付を厳格化するだけでなく、確認と修正の高速化も必要だ。Appleのレビュー能力が大部分で人手に依存したままであれば、AI支援による報告は引き続きその限界を試すことになる。
AppleがGoogleの社内ツールをコピーする必要はない。ただし、パイプライン全体に対する答えは必要だ。そこには、発見、認証、重複排除、再現、優先順位付け、パッチ作成、研究者とのコミュニケーションが含まれる。
勝者となるのは、最も多くのアラートを生成するAIを持つ企業ではない。信頼できる発見を、最小限の無駄な労力で本番環境に適用された修正へと変えられる企業だ。
業界全体のセキュリティプログラムは門を狭めつつある
Appleの上限は、オープンな報告受付から、評判・証拠・管理されたアクセスへと移行する業界全体の変化の一部だ。
GitHubは、増え続けるキューに直面した後、2026年7月にバグ報奨金プログラムを再編した。公開ルートと並行して、恒久的な招待制プログラムを導入した。公開プログラムでは現在、低品質な報告やAI生成の報告を減らすため、HackerOneのシグナル要件を採用している。
必要な評判を持たない新規研究者には、実績を築くための4件の提出枠が与えられる。GitHubはこの設計を、セキュリティ研究を恒久的に締め出す壁ではなく、招待制プログラムへの導線だと説明している。
同社の報奨金制度の変更は、7月27日以降に提出された報告から適用された。それ以前の報告には、従来の制度が引き続き適用される。
GitHubのアプローチは、過去の提出品質をシグナルとして使うため、一律の上限とは異なる。また、より大きなアクセスにつながる道筋も用意している。ただし、評判システムは、優秀な新人や主要な報奨金プラットフォーム外で活動する研究者を不利にする可能性がある。
curlプロジェクトはさらに厳しい措置を取った。メンテナーがAI生成の報告への対応に苦慮したことを受け、HackerOneの報奨金プログラムを終了した。少人数のセキュリティチームは、虚偽または価値の低い提出が、精神面と運用面で持続不可能な負担を課していると述べた。
Linuxのメンテナーも、重複するAI発見による同様の圧力を報告している。複数の人が同じコードに対して類似のツールを実行し、同一の結果を非公開で提出できる。非公開キューでは既存の報告が見えないため、各送信者はその発見が独自のものだと考える場合がある。
これらの事例は、Appleだけが特別に準備不足というわけではないことを示している。脆弱性報告の経済性は、報告を受け取る組織よりも速く変化してきた。
以前は、発見そのものが研究者の労力の大部分を占めていた。現在では、AIエージェントが多くの対象にわたるコードレビューとテストを自動化できる。トリアージ能力は、それに見合う規模で拡大していない。
オープンソースプロジェクトは、メンテナーに専任のセキュリティ担当者がいない場合があるため、最も深刻な不均衡に直面している。大手ベンダーはより多くのリソースを持つが、製品、研究者、ユーザー、潜在的な攻撃対象領域も多い。
誤った教訓は、AI支援の報告にはほとんど価値がないというものだ。Googleの結果はその逆を示している。AIシステムは、従来のレビューが見落とした問題を含め、成熟したソフトウェア内の実際の欠陥を特定できる。
正しい教訓は、未検証の出力には負の外部性があるということだ。モデルを動かす人は低コストで手がかりを得る一方、受信者は各手がかりに重要性があるかを判断するコストを負担する。
業界のプログラムは、そのコストを提出者側へ戻すことで対応している。より強い証拠を求め、割当量を設け、研究者の履歴を考慮し、あるいは信頼された参加者にプレミアムなアクセスを限定している。
この移行はガバナンス上の問いを生む。信頼された研究者でも誤ることはあり、無名の研究者でも重大な欠陥を見つけることはある。評判スコアはトリアージの参考にすべきであり、技術的証拠の代替にすべきではない。
プログラムには透明性のある異議申立ての経路も必要だ。自動システムが報告を重複または実現不可能と判定した場合、研究者は新たな証拠を提示できるべきである。そうでなければ、フィルタリングが本物の欠陥を隠しかねない。
開示タイムラインはさらに圧力を加える。研究者は多くの場合、公表前の定められた期間内にベンダーが脆弱性を修正することを期待する。長い受付遅延は、エンジニアが報告を評価する前から、その期間の一部を消費してしまう。
Appleの報奨金プロセスでは、一般に問題を解決した後に報奨の判断が下される。これは慎重な評価を促し得る一方、研究者が同社の社内ペースとコミュニケーションに依存することも意味する。受付の追加的な遅延は、その関係を緊張させる可能性がある。
独立系研究者は、ベンダーのセキュリティに対する重要な外部チェックであり続ける。プログラムが過度に制限的になると、彼らを公開開示、非公開のエクスプロイト市場、あるいは別の標的へと向かわせる可能性がある。
したがってAppleは、2つの希少なリソースを守らなければならない。1つはレビュー担当者の注意力であり、もう1つは研究者が重大な欠陥を非公開で報告しようとする意欲だ。
上限は最初のリソースを直ちに保護する。それが後者を損なうかどうかは、例外処理、応答時間、複数の有効な発見を提出した研究者への対応に左右される。
Appleの制限からは分からないこと
報じられた方針は、Appleが受付上の問題を認識していることを示すが、同社が重大な脆弱性を見逃していることの証明ではない。
Appleは、受け取るAI支援の報告件数を公表していない。有効、重複、理論上のみ、完全な捏造にそれぞれ該当する件数も開示していない。こうした数値がなければ、外部の人間はバックログの規模や質を測定できない。
同社はまた、デフォルトの上限が研究者の評判によって変わるかどうかも説明していない。Appleが割当量の申請をどれほど迅速に審査するのか、緊急の報告がクーリングオフ期間を迂回できるのかも明らかではない。
こうした欠落した詳細により、運用リスクについて確固たる結論を下すことはできない。迅速な例外審査と組み合わされた上限であれば、信頼できる研究者への影響は小さいかもしれない。遅く柔軟性のないプロセスは、重要な発見を遅らせる可能性がある。
「AI生成の報告」という表現も、いくつかの異なる実務をひとまとめにしている。ある研究者はモデルを文章の編集にのみ使うかもしれない。別の研究者はエージェントで欠陥を見つけた後、手動で再現・分析するかもしれない。さらに別の研究者は、影響を受けるソフトウェアを開かずに生の出力を提出するかもしれない。
これらのワークフローを同じカテゴリとして扱うと、支援と怠慢を混同することになる。Appleの公開ルールは一般に、AI利用そのものを禁じるのではなく、検証に焦点を当てている。この区別は中心的なものとして維持されるべきだ。
GoogleのツールがAppleの受付問題を直接解決できるという検証済みの証拠もない。Big Sleepは、Googleの専門家に支えられた統制された研究環境内で動作する。公開の報奨金ポータルには、はるかに多様な内容が寄せられる。
Googleの結果は一部が自己申告に基づくものだ。同社は問題追跡と開示の詳細を提供しているが、防御上の優位性に関する広範な主張はなお独立した検証に値する。管理された1つのエージェントの性能は、すべてのAIセキュリティツールを代表するものではない。
自動パッチ作成には、さらなる不確実性が伴う。パッチは目に見えるクラッシュを止めても、根本的な脆弱性を残す可能性がある。また、互換性の問題を生じさせたり、1つの攻撃経路を閉じる一方で別の経路を開いたりすることもある。
特に数十億台のデバイスに展開されるオペレーティングシステムでは、人間の承認が引き続き重要だ。Appleは修正が機能するかだけでなく、パフォーマンス、プライバシー、バッテリー駆動時間、アプリケーション互換性に影響するかも評価しなければならない。
同社のクローズドな開発モデルは、外部からの評価を複雑にする。研究者は公開された挙動を観察し、リリース済みソフトウェアを調査できるが、Appleの社内トリアージツール、人員規模、修正キューを見ることはできない。
したがって読者は、2つの安易な物語に抗うべきだ。Appleは、AIそのものがセキュリティチームを打ち負かしたとは認めていない。方針と報じられた確認を通じて、報告量にはより強力な統制が必要だと認識している。
反対の物語も不完全だ。この上限は単なる日常的な事務処理ではない。30日間のクーリングオフ期間は、通常のレビューおよびスパム対策ルールでは、少なくとも一部の提出パターンに対して不十分だったことを示している。
方針は結果によって評価されるべきだ。研究者には迅速な受領確認が必要であり、再現可能な発見には速い技術レビューが必要であり、重大な欠陥には協調したパッチが必要だ。キューの規模が重要なのは、それがこれら各段階を遅らせ得るためである。
ここでナレッジマネジメントは運用上のセキュリティとなる。チームには、報告、影響を受けるコンポーネント、過去の重複、パッチ、開示期限の間を検索可能な形でつなぐ仕組みが必要だ。適切に設計された検索可能なナレッジベースはこの作業を支援できるが、セキュリティの専門知識に取って代わることはできない。
Appleの課題は、単により多くの報告を保存することではない。発見が受付担当者、製品エンジニア、インシデント対応者、リリースチームの間を移動する際に、文脈を維持しなければならない。文脈が失われると、有効な報告でさえ繰り返し作業に変わってしまう。
AIは関連する発見をクラスタリングし、過去の判断を取得するのに役立つ。再現手順の下書きを作成したり、影響を受けるコードの担当者を特定したりもできる。こうした用途は、重大度に関する最終的な権限をモデルに与えずに、管理上の負荷を減らす。
未解決の問いは、Appleがそのより深い能力を構築しているのか、それとも主にスロットリングに頼っているのかということだ。上限は時間を稼ぐが、Appleがその時間を何に使うつもりなのかは明らかにしない。
AppleとGoogleの差が続くかを示す3つのシグナル
次の段階は、受付品質、修正速度、信頼できる研究者への対応によって測られる。
1つ目のシグナルは、Appleがより明確な割当量ルールを公表するかどうかだ。研究者は、デフォルトの上限、例外基準、緊急ルート、想定されるレビュー時間を知る必要がある。透明性は、不透明な制限を予測可能な運用プロセスへと変える。
再現可能な発見を持つ研究者に対する迅速な割当量承認は、この方針がノイズを対象にしているというAppleの主張を支える。未解決のアクセス申請や遅延した重大な開示に関する報告は、その主張を弱めることになる。
2つ目のシグナルは、Appleが人間のレビューを弱めずに自動トリアージを拡大するかどうかだ。有用な変更には、重複のクラスタリング、隔離環境での概念実証の実行、機械可読な証拠要件などが含まれる。
Appleは、ターゲットフラグもより広く提供できる。ターゲットフラグとは、研究者が保護されたセキュリティ目標に到達したことを証明する管理されたマーカーである。Appleはすでに、報奨金プログラムの一部でこうしたフラグを使い、評価を迅速化している。
証拠に基づく自動化は、一律の上限よりも直接的に品質へ対応する。信頼できる再現経路を含む発見をAppleが優先できるようにしつつ、異例の脆弱性への経路も維持できる。
3つ目のシグナルは、Googleのセキュリティエージェントが、慎重に管理されたデモの外でどのように機能するかだ。Big Sleepの公開開示、誤検知の制御、発見からパッチまでの時間は、有意義な比較材料となる。
GoogleのProject ZeroはBig Sleepを開示フレームワークの下に置いており、そこではパッチの可用性と透明性が重視されている。同プロジェクトの開示方針は、発見がどのように公開へ向かうかを外部の人が検証する手段を提供している。
Googleが、保守担当者を圧倒することなく検証済みの脆弱性を継続的に生み出せるなら、そのモデルの信頼性は高まる。受信者から重複報告の多さや内容の浅い指摘が報告されれば、Appleとの差は縮まる。
業界全体はGitHubにも注目するだろう。評判ベースの仕組みは、無制限のアクセスと一律の上限との中間的な道を示している。提出物の品質、新規参加者の成果、対応時間が、この設計が機能するかどうかを明らかにする。
開発者やエンタープライズの購買担当者にとって、この問題は抽象的なAI政策ではなく、パッチ適用のタイミングに影響する。発見される欠陥が増えても、攻撃者に悪用される前にベンダーが検証・修正できて初めて、セキュリティは向上する。
セキュリティ責任者は、AI支援の調査と未検証の自動化をどのように区別しているか、ベンダーに問うべきだ。また、報告件数の増加が修正目標、開示調整、人員配置に変化をもたらしたかも確認すべきである。
研究者にも責任がある。影響を受けるバージョンを確認し、正確な前提条件を記録し、挙動を再現し、越えられたセキュリティ境界を説明すべきだ。AIが生成した文章は、こうした手順の代わりにはならない。
AppleとGoogleの事例は、結局のところ、セキュリティシステム全体における処理能力の問題である。Googleは、統制された監督の下で、より迅速な発見を示している。Appleは、制御されていない外部集団からの受付を制限している。
どちらか一方のアプローチだけで問題は解決しない。検証のない発見はノイズを生む。検証能力を拡大しないまま制限を加えれば、見えない遅延が生じる。
今後数か月は、Appleが緊急ブレーキを、よりシグナルの強いパイプラインへ置き換えるかに注目したい。明確な例外規定、自動化された証拠処理、研究者とのより迅速なコミュニケーションがあれば、その立場は強化される。
クールダウン期間が依然として主な目に見える対応であるなら、AppleとGoogleのセキュリティ上の隔たりは深まる。AIはもっともらしい発見の供給を増やし続ける一方、人間によるレビューは希少な資源であり続ける。
広く導入されているソフトウェアに依存する仕事に携わる人なら、この不均衡を懸念すべきだ。ベンダーが単に報告を制限しているだけなのか、それとも発見から修正までの道筋を改善しているのかを問うべきである。その答えが、AIによる脆弱性調査が防御上の優位性となるのか、あるいは過負荷の受信トレイをもう一つ増やすだけなのかを決める。
