Google OSS VRPの停止が浮き彫りにするAIバグ報告の隠れたコスト
Googleは10月1日、無効なAI報告が審査プロセスを圧迫したことを受け、オープンソースのバグ報奨金制度を通じた新規の製品脆弱性報告の受け付けを停止した。Google OSS VRPの停止は、プログラムのすべてを終了するものではない。しかしGoogleが再設計を完了するまで、主要な報告経路の一つは閉鎖される。
当面の問題は、人工知能がソフトウェアの欠陥を発見できないことではない。AIシステムはすでに、大規模で十分にレビューされたコードベースから有効な欠陥を見つけ出している。問題は、もっともらしい報告を生成するコストが、そのセキュリティ上の影響を証明するコストよりはるかに低くなったことにある。
この不均衡により、脆弱性トリアージは希少なリソースとなった。Googleは、本物の発見を、幻覚による攻撃経路、到達不能なコード、重複報告、通常のプログラミングエラーから切り分けなければならない。GitHub、Linuxのメンテナー、小規模なオープンソースプロジェクトも同じ圧力に直面している。
Googleによると、期限前に提出された報告は引き続き審査対象となる。サプライチェーンに関する報告は受け付けを継続し、特定のGoogle Cloudリポジトリの欠陥についてはCloud Vulnerability Reward Programを利用できる。同社は2027年第1四半期までに次の更新情報を提供する見込みだ。
この停止は示唆に富む対立を生み出している。AIは防御的なセキュリティ研究を拡張すると期待される一方、未検証の自動化は、真の脆弱性を修正するために必要な人間の注意力を消費しかねない。AI支援によるバグ探索の将来は、発見数そのものよりも証拠の質に左右されることになる。
Google OSS VRPの停止は限定的だが即時に実施された
Googleは一つの報告カテゴリーを凍結したのであって、外部セキュリティ研究者との幅広い関係を放棄したわけではない。
影響を受けるのは、一般にOSS VRPと呼ばれるOpen Source Software Vulnerability Reward Programだ。Googleは2022年、対象となるオープンソースプロジェクトに影響する脆弱性を責任ある形で開示した研究者に報奨を与えるため、この制度を開始した。
このプログラムは、Googleが所有する公開リポジトリ内のソフトウェアと、他所でホストされる一部のプロジェクトを対象とする。対象範囲には、製品脆弱性とサプライチェーン侵害の両方が含まれてきた。これらのカテゴリーは異なるリスクを扱うため、現在は異なる報告経路に従っている。
製品脆弱性は、プロジェクトのコード、ロジック、設計内部の欠陥に関するものだ。説得力のある報告では、攻撃者がその欠陥に到達でき、有意なセキュリティ上の結果を引き起こせることを示す必要がある。安全でなさそうに見える関数を特定しただけでは、悪用可能性は立証されない。
サプライチェーン報告は、ソフトウェアのビルド、パッケージ化、署名、配布の方法に対する脅威を扱う。基盤となるソースが正当なものに見えても、リリースパイプラインが侵害されれば悪意あるコードが拡散する可能性がある。Googleはこの報告カテゴリーを継続して受け付けている。
停止の対象は、2026年10月1日以降に提出された新規の製品脆弱性報告だ。それ以前の報告は、従来のプロセスに基づく審査対象であり続ける。Googleはまた、該当する場合には他の脆弱性報奨プログラムを利用するよう研究者に案内した。
Google Cloudリポジトリに関わる一部の報告は、引き続きCloud VRPを通じて対象となる可能性がある。この例外は、単にソースリポジトリがGoogleに属するかではなく、問題がGoogle Cloud製品に影響するかどうかに左右される。
GoogleはX上のBug Huntersアカウントを通じてこの変更を発表した。最初の詳細な報道によれば、同社はこの決定を無効なAI主導の報告の流入と結び付けた。
この停止は、突然の方針転換というよりも、数カ月にわたる引き締めの後に実施されたものだ。4月のルール更新でGoogleは、低品質かつ無効な報告がOSS VRPに急増していると説明していた。
Googleは繰り返し見られる二つのパターンを特定した。一部の報告には、主張された脆弱性をどのように誘発できるかについての幻覚的な説明が含まれていた。別の報告では実際のコーディングミスを見つけていたものの、到達可能なコードや重大なセキュリティ影響を示せていなかった。
この区別が重要なのは、ソフトウェアの欠陥とセキュリティ脆弱性は同じものではないからだ。到達不能なテストユーティリティでのクラッシュと、本番サービスにおけるリモートコード実行とでは、結果が異なる。
Googleはすでに、優先度の低いプロジェクト階層における特定の製品脆弱性やその他のセキュリティ問題について、報奨やクレジットの提供を停止していた。また、実行可能な発見、検証済みの再現手順、影響の実証を重視していた。
したがって10月の措置は、ノイズを減らすための既存の取り組みを拡張したものだ。報告が流入し続けるなかで適格性を調整する代わりに、Googleはより広範な再設計の期間中、影響を受ける受け付け経路を閉鎖した。
同社は、却下した報告の正確な数、バックログの規模、採用率を公表していない。数千件の提出があったとの主張は、完全なプログラム統計ではなく、報じられた数字にとどまる。
このデータ不足は外部からの分析を制限する。それでも、ルール変更、公の警告、そして最終的な凍結という一連の流れは、段階的なフィルタリングでは業務負荷の問題を解決できなかったことを示している。
無効なAIバグ報告がセキュリティトリアージを破綻させる理由
AIは報告の経済性を変える。提出は自動的に拡大できる一方、検証には依然として希少な人間の判断が必要だからだ。
従来の脆弱性研究には、いくつものコストの高い工程が必要となる。研究者は対象を理解し、弱点を特定し、再現可能な攻撃を構築し、影響を評価し、結果を明確に伝えなければならない。
大規模言語モデルは、この作業の一部を加速できる。ソースコードを調査し、危険なデータフローを示唆し、テストケースを下書きし、粗いメモを洗練された文章に変えられる。自動化エージェントは、多数のリポジトリでこれらの手順を繰り返せる。
同じツールは、自信に満ちた誤った説明を生み出すこともある。モデルは、信頼されたままの入力を攻撃者が制御できると仮定するかもしれない。権限チェックを見落とし、デプロイ構成を誤解し、到達可能な実行経路をでっち上げる可能性もある。
こうした失敗は、提出後に高くつく。セキュリティエンジニアは、もっともらしく見える報告を文面の印象だけで却下できない。引用されたコードを調べ、条件を再現し、データを追跡し、主張された影響が実際に存在するかを検証する必要がある。
そのため、誤報は作成に数分、却下に数時間を要することがある。悪意がなくとも、類似した報告が千件に達すれば、この不均衡は運用上のサービス拒否状態へと変わる。
報告の見せ方は問題をさらに悪化させうる。言語モデルは、長文の脆弱性説明、深刻度ラベル、攻撃図、緩和策を容易に作り出す。だが、これらはいずれも動作する再現手順の代わりにはならない。
洗練された文章は、かえってトリアージコストを増やす可能性がある。レビュー担当者は、生成された文脈が何ページにもわたる中から事実上の主張を見つけ出さなければならない。また、どの記述がテストに基づくものか、どれがモデルの推論によるものかを判断する必要もある。
Googleの以前のルールは、検出と検証の違いに焦点を当てていた。静的解析ツールからの警告は疑わしいコードを特定できる。しかし、そのコードが悪用可能なセキュリティ境界の侵害を生むと自動的に証明するわけではない。
到達可能性は不可欠な検証の一つだ。レビュー担当者には、現実的な条件下で信頼できない入力が危険な操作へ到達できる証拠が必要となる。報告では、サニタイズ、権限、構成、既存の防御も考慮しなければならない。
影響も別の検証対象だ。バッファオーバーフローは深刻に聞こえるが、その位置と周辺の制御が攻撃者に何を可能にするかを決める。欠陥の中には、データや制御を露出させず、隔離されたプロセスを終了させるだけのものもある。
新規性も重要である。自動化システムは、既知の問題を再発見したり、以前に却下された仮説を繰り返したり、同じ根本原因について複数の説明を生成したりできる。それぞれの重複報告も、受け付けとレビューの能力を消費する。
この負荷は専門知識を持つ人々にかかる。経験豊富なメンテナーやセキュリティエンジニアは、モデルが見落としがちなアーキテクチャ上の前提を理解している。彼らを反復的な検証に投入すれば、パッチ適用、監査、設計レビュー、インシデント対応が遅れる。
機会費用はGoogleの外にも及ぶ。オープンソースプロジェクトは、そのコードが広く利用されるサービスを支えていても、メンテナーの人数が少ないことが多い。自動化された報告キャンペーンは、プロジェクト全体のセキュリティ対応能力を超える可能性がある。
チームは、判断、再現手順、過去の発見を検索可能なエンジニアリング知識ベースに保持することで、文脈を維持できる。この実践は調査の重複を減らすが、専門家による検証の必要性をなくすことはできない。
Googleのバグ報奨金制度の停止は、この労働力の制約を可視化した。セキュリティプログラムは、有意な研究者の努力を伴う報告を前提に設計されていた。AIは、その努力の大部分を提出者から受け取り側チームへ移転させることを可能にする。
AIバグ報告が生むのは品質問題であり、AI禁止ではない
中心にある対立は、検証済みの研究と未検証の自動化の間にあるのであって、人間の研究者と人工知能の間にあるのではない。
Googleは、研究者がAIの使用を完全に避けるべきだとは主張していない。同社の立場は、研究を行う際に人がAIの出力を検証しなければならないというものだ。この要件は、AIを説明責任を負う報告者ではなく、道具として扱う。
有用なAI支援報告には、依然として直接的な証拠を含められる。研究者は、影響を受けるバージョン、正確なコマンド、最小化したテストケース、ログ、スクリーンショット、観測結果を提供できる。また、侵害されたセキュリティ境界を説明することもできる。
決定的な問いは、人がその主張を確認したかどうかだ。モデルが生成した仮説は、テストによって関連コードに到達可能であり、結果が機密性、完全性、可用性に影響すると証明されたときに価値を持つ。
この基準は正当な自動化を守る。ファザーは長年、予期しない入力を送り、障害を記録することでセキュリティ上の発見を生み出してきた。その価値は、説得力のある説明ではなく、具体的で再現可能な出力にある。
AIエージェントはこのモデルを拡張できる。ソースコードについて推論し、ハーネスを作成し、クラッシュを調査し、パッチを提案できる。より広い探索空間により、従来のツールが見逃す欠陥を発見できる可能性がある。
しかし、推論システムは別の失敗モードをもたらす。もっともらしい言葉で欠けた証拠を補ってしまうことがある。従来のスキャナーは通常、検出したパターンを報告するのに対し、言語モデルは攻撃の物語全体を作り出す可能性がある。
この違いが、開示プログラムが報告を流暢さだけで評価できない理由を説明する。レビュー担当者には、観測可能な挙動と結び付いた成果物が必要だ。理論上の結果に関する主張は、実証済みの結果より低い信頼度で扱うべきである。
AIの全面的な排除に反対する最も強い根拠は、成功したAIセキュリティ研究にある。AIシステムは、人間のレビュー担当者が見逃していた欠陥を含め、主要なオープンソースプロジェクトで本物の脆弱性を発見してきた。
こうした成果は、AI支援報告をすべて禁止することが近視眼的である理由を示している。防御チームは、とりわけ大規模な依存関係グラフや成熟したコードベース全体で、より広いカバレッジを望んでいる。望んでいないのは、無制限で未検証の推測だ。
Google自身も防御的なセキュリティ研究にAIを利用している。同社のより広範なセキュリティ活動には、AI支援による脆弱性発見とオープンソースのファジングが含まれる。同社の異議は、報告の境界における検証品質に関するものだ。
その境界は、説明責任に関する問いを生む。自律エージェントがレポートを提出した場合、追加質問には誰が答えるのか。誰かが前提を明確にし、再現手順を修正し、観測された挙動と予測された挙動を区別しなければならない。
責任を負う研究者がいないレポートでは、その作業がメンテナーに転嫁される。受け手が、提出者が始めた調査を完了させる責任を負うことになる。
AIの利用を明確に開示することは役立ちうるが、開示だけで品質を保証することはできない。人間が書いたレポートも誤っている場合がある。AI生成のレポートでも、正確で簡潔かつ十分に検証されたものになりうる。
したがって、プログラムには文体検出器ではなく、証拠に基づくゲートが必要となる。AIテキスト分類器は、特に研究者がテンプレートを使ったり第二言語で執筆したりする場合、技術文書を誤分類する可能性がある。
より優れた受付システムは、レポートの中身を検証する。最小限の再現手順、環境の詳細、影響を受けるコミット、到達可能性の証明、攻撃者の能力に関する直接的な説明を求めることができる。
GoogleのOSS VRP停止は、同社にこうしたゲートを設計する時間を与える。一方で、より厳格なシステムが、評判はなくとも有効な発見を持つ有能な新規研究者を締め出すリスクもある。
このトレードオフをなくすことはできない。オープンなプログラムが予想外の発見を呼び込むのは、誰でも参加できるためだ。アクセスを制限すれば平均的な品質は改善するが、無名の研究者が適切なチームに到達する可能性は下がる。
GitHubとオープンソースのメンテナーも同じゲートを厳格化している
Googleの決定は、オープンな受付から、評判、証拠、より限定的な提出経路へと移行する業界全体の流れの一部だ。
GitHubも2026年に、低労力かつAI生成のレポートによるバックログに直面した。同社は報奨金プログラムを再編し、公開研究者と招待研究者向けに別々の経路を設けて対応した。
公開プログラムには、研究者の過去のプラットフォーム上の実績を適格性の指標として用いるHackerOneシグナル要件が追加された。招待プログラムでは、確立された信頼を持つ研究者向けに別の経路が提供される。
GitHubは、真剣な外部研究を維持しつつ、低労力な提出量を減らすことが目標だと述べた。同社の再編に関する発表では、新しい仕組みを2026年7月27日以降に提出されたレポートに適用した。
以前のガイダンスでは、プラットフォームが有用な証拠と見なすものが説明されていた。強力なレポートには、簡潔な要約、裏付け資料を伴う再現手順、攻撃者が実現可能な影響についての明確な記述が必要だった。
GitHubはまた、理論的な説明やAI生成の水増し文がトリアージを遅らせると警告していた。問題は単に内容が不正確なことではない。過剰な説明は実際の発見を埋もれさせ、レビューを遅延させる可能性がある。
GoogleとGitHubは、異なる即時対応を選んだ。GitHubは、より強力な評判および品質ゲートを備えた公開経路を維持した。Googleは他の脆弱性プログラムを利用可能なままにしつつ、OSS VRPの1カテゴリを停止した。
どちらのアプローチも、レビュアーの注意を守る。また、プラットフォーム上の評判を築いていない新規研究者には摩擦を生む。優れた初回レポートは、長い報奨金獲得歴を持たない人からも提出されうる。
オープンソースのメンテナーは、この問題のさらに深刻な形に直面している。多くのプロジェクトには、専任のセキュリティスタッフ、有償のトリアージチーム、正式な提出インフラがない。メンテナーは私的な時間にレポートを確認することもある。
業界のガイダンスは、責任を双方に置く傾向を強めている。Open Source Security Foundationは、研究者に対し、発見を検証し、プロジェクトのポリシーを理解し、AIが作業にどのように寄与したかを明確に開示するよう助言している。
同財団のメンテナー向けガイダンスも、AIが正当な防御的分析を支援しうることを認めている。推奨される対応は、安全な統合と人間によるレビューを中心に据える。
より広いパターンは、スパム対策に似ている。送信がほぼ無料になると、受信者はフィルター、評判シグナル、レート制限、または提出コストを導入しなければならない。そうしなければ、低品質な量が価値あるコミュニケーションを圧倒する。
バグ報奨金プログラムは、通常のスパムフィルターをそのまま複製することはできない。セキュリティレポートには新規の技術的詳細が含まれ、無名の研究者から届くことも多い。異例の内容を過度に積極的に拒否すれば、最も重要な発見を見落としかねない。
プログラムはおそらく、複数の制御を組み合わせることになる。構造化フォームは具体的な回答を強制できる。自動チェックは必須アーティファクトの有無を検証できる。評判は、絶対的な適格性ではなく提出上限を決める要素になりうる。
自律エージェントにとっては、レート制限が特に重要になる可能性がある。人間は複数の機械生成候補を確認し、最も強いものだけを提出できる。監督されていないシステムは、メンテナーがフィードバックする前にプログラムを大量提出で埋め尽くす可能性がある。
保証金や返金可能な提出債はより強いコストを生むが、アクセスに関する懸念を招く。低所得地域の研究者は不均衡な障壁に直面する可能性がある。法的・管理上の複雑さも増すだろう。
非公開または招待制のプログラムは公開経路の量を避けられるが、幅広い参加を失う。信頼が既知の研究者に集中し、特定コンポーネントに関する専門知識を持つ外部者を見逃す可能性がある。
したがってGoogleの再設計は、一企業を超えた意味を持つ。他のプログラム運営者は、新人材への扉を閉ざさずにシグナルを回復できるかを注視するだろう。
厳格なフィルターは実際の脆弱性も隠しうる
AIノイズの削減は必要だが、すべてのフィルターには、有効で馴染みのないレポートが適切なエンジニアに届かない可能性がある。
Googleは停止の理由を説明しているが、完全なパフォーマンスデータは公開していない。外部の人間は、AI導入前後の偽陽性率を比較することも、バックログの実際の深刻さを測定することもできない。
その数字がなければ、複数の解釈が成り立つ。AI生成の提出がキューを支配している可能性もあれば、反復的に報告する少数のグループが負担の大半を生んでいる可能性もある。原因が異なれば、必要な制御も異なる。
基盤となるモデルの品質も重要だ。現在のハルシネーション率を前提に設計されたポリシーは、すぐに古くなる可能性がある。より優れたエージェントは強力な再現手順を作成できる一方、より大量のレポートも生成できる。
プログラム設計は、確信と証拠を区別しなければならない。エージェントが悪用に高い確率を割り当てても、それは悪用を証明したことにはならない。逆に、不完全なレポートでも、フォローアップに値する重大な欠陥を記述している場合がある。
新規研究者は開示の経験が不足しているため、不完全なレポートを提出することが多い。その文章は、根底にある観測が本物であっても、低品質な自動生成出力に似ることがある。
言語とアクセシビリティにも同様のリスクがある。洗練された英語を求めることは、深い技術知識を持つ研究者を不利にする可能性がある。フォームは、文体を信頼性の代理指標にすることなく、具体的な証拠を求めるべきだ。
評判ゲートも過去のアクセスを強化する。確立された研究者はシグナルを築く機会をより多く得る一方、新規参入者は入口に苦しむ。閉じた循環は効率を上げるかもしれないが、多様性を損なう。
受信側の自動化にも別の不確実性がある。Googleはモデルを使ってレポートを要約、重複排除、優先順位付けしている可能性がある。偽陰性は偽陽性とは異なる結果をもたらすため、こうしたシステムには監査が必要だ。
偽陽性はレビュアーの時間を無駄にする。偽陰性は脆弱性を未発見のままにしかねない。したがって、受付システムは最終的な拒否よりも、ルーティングと証拠確認を優先して自動化すべきだ。
異議申立ては一つの安全策となる。拒否された研究者は、どの要素が不十分だったのか、追加証拠によってレポートを再開できるのかを理解できるべきだ。一般的な拒否メッセージは、繰り返しの提出や公の不満を招く。
透明な例も行動改善に役立つ。プログラムは、到達不能なコード、裏付けのない影響主張、重複の根本原因、許容される再現手順を示す匿名化ケースを公開できる。
Googleはすでに、各脆弱性プログラムで報告ガイダンスを提供している。同社の品質フレームワークは、対象情報、再現可能性、影響、コミュニケーションを重視している。
再設計では、これらの基準を機械的に強制される前提条件にするかどうかを決める必要がある。また、正式なフィールドが欠けていても、人間の裁量に委ねるべきレポートがどれかを判断しなければならない。
不要な提出をすべてAIスロップと呼ぶことにも、別の危険がある。このラベルは、脅威モデルをめぐる本当の意見の相違を覆い隠しかねない。研究者とベンダーは、しばしば悪用可能性を異なる方法で評価する。
企業は、攻撃者にユーザー操作が必要だという理由で問題を却下するかもしれない。研究者は、その操作が依然として現実的だと主張するかもしれない。こうした争いは生成AIより前から存在しており、著者検出によって解決することはできない。
同じ注意は通常のコード欠陥にも当てはまる。一部のバグは直ちに影響を持たないが、別の製品変更後に危険になる可能性がある。プログラムには境界が必要だが、その境界を重大度に関する普遍的な判断と取り違えるべきではない。
したがって、この停止はトリアージへの介入であり、対象リポジトリがより安全になったことの証明ではない。一つの報告経路が閉じている間も、脆弱性は存在し続ける。
研究者は別の適切なチャネルを特定するか、関連プロジェクトに直接連絡しなければならない。断片化された開示経路は、遅延、意図しない公開、作業の重複を増やす可能性がある。
Googleは、対象外となったレポートを明確にルーティングすることで、そのリスクを減らせる。同社の公開プログラムディレクトリはすでに、Google、Cloud、Chrome、Android、AI、abuse、オープンソースの対象範囲を分けている。
有効な研究者が正しい送付先を予測できて初めて、再設計は成功する。重大なレポートが重複するプログラム規則の間で消えてしまうなら、キューが小さくなっても意味はほとんどない。
Googleが製品レポートを再開する前に注目すべき点
次の試金石は、Googleがオープンな提出ボックスを、馴染みのない研究者を沈黙させずに証拠を検証するシステムへ置き換えられるかどうかだ。
最初のシグナルは、2027年第1四半期までに予定されている更新だ。Googleは、製品脆弱性の提出が再開されるのか、別の場所へ移るのか、あるいはアクセス制限付きのプロセスを通じて戻るのかを明確にすべきだ。
構造化された証拠要件を伴う再開なら、この停止が一時的なトリアージだったという見方を裏付けるだろう。期限のない閉鎖なら、Googleが従来の公開モデルをもはや持続可能と見なしていないことを示す。
第二のシグナルは、受付ゲートの設計だ。必須の再現手順、影響を受けるバージョン、テスト済みコミット、実行トレース、簡潔な影響説明は、文書化された失敗パターンに直接対処する。
評判のみの制限は異なる選択を意味する。それは迅速に量を減らせるかもしれないが、各レポートに含まれる証拠よりも研究者の経歴に重きを置くことになる。
自律エージェントに対するGoogleの扱いは特に重要になる。同社は、すべての提出が再現されたことを、名前のある人間に証明させることができる。また、機械支援による報告にレート制限を課すこともできる。
意味のあるポリシーは、AI支援と、監督されない大量提出を分けるべきだ。研究者は日常的に、自動化、デバッガー、ファザー、スキャナー、言語モデルを使っている。決定的な問題は、誰が主張を検証し、責任を負うかである。
第三のシグナルは、確認済みの発見を減らさずにバックログが改善するかどうかだ。Googleはその比較に十分なデータを公開していないが、将来の透明性は他のプログラムが再設計から学ぶ助けになる。
有用な指標には、提出量、検証時間、重複率、受理された発見、報告者からの異議申立て、動作する再現手順を含むレポートの割合が含まれる。集計値であれば、機微な詳細を保護できる。
研究者は、Googleの他のVRPにも注意を払うべきです。無効なAIバグ報告がCloud、Chrome、あるいはGoogle全般の窓口へ移行すれば、今回の停止は問題を解決するのではなく、作業負荷を移しただけということになります。
同社のより広範なバグ報奨金制度は引き続き有効です。Googleのプログラムディレクトリでは、対象となるセキュリティ問題が複数の専門プログラムへ引き続き振り分けられています。
Google以外のメンテナーも、最終的なポリシーを待つ必要はありません。受け入れる証拠を定義し、脅威モデルを公開し、自動送信を制限し、観測結果と推定された影響を分けるテンプレートを作成できます。
研究者側も対応できます。報告を提出する前に、挙動を再現し、テストケースを最小化し、影響を受けるリビジョンを確認し、攻撃者に必要なアクセスを説明すべきです。
発見を裏付けない生成済みの背景説明は削除すべきです。不確かな前提を中心に構成された洗練された論考よりも、直接的な証拠を含む短い報告のほうが検証しやすくなります。
AI支援によるセキュリティ研究は、その正当な利点が大きいため、今後も拡大を続けるでしょう。モデルはより多くのコードを探索し、標的を絞ったテストを生成し、調査担当者が不慣れなコンポーネント間の関連を見いだすのを支援できます。
しかし、発見件数はもはや進歩を測る最良の指標ではありません。報告が有用になるのは、メンテナーが行動を起こすために十分信頼できる証拠を提供している場合に限られます。
Google OSS VRPの停止は、この違いを見過ごすことが不可能になった瞬間を示しています。次のプログラム設計では、検証済みの知見に報い、アクセスを維持し、人間の注意を実際のリスクに集中させなければなりません。
次のAI支援による発見を提出する前に、モデルが疑わしいコードを見つけたかどうかよりも難しい問いを投げかけてください。提示した証拠から、別のエンジニアがセキュリティ上の影響を再現できるでしょうか。
