Googleが一部のバグバウンティ報告の受け付けを一時停止しました。この措置は、企業が直面する幅広い問題を浮き彫りにしています。AIによって脆弱性の発見は安価かつ高速になりましたが、機械が生成する大量の発見事項を検証し、優先順位を付け、修正する作業に、セキュリティチームが追われているのです。
AIはソフトウェアの脆弱性発見を加速させています。その一方で、防御側には新たなボトルネックが生まれました。機械が生成した発見事項のうち、どれを調査する価値があるのかを見極める作業です。Googleは、自動生成された報告のほとんどが無効だったことを受け、一部のバグバウンティ報告の受け付けを一時停止すると決めました。AI駆動の脆弱性発見が人間による検証能力を上回り始めており、セキュリティチームにとって課題が拡大していることを示しています。
バグバウンティプログラムの停止に先立ち、Googleはセキュリティチームに届く低品質な報告を減らすため、すでに対策を講じていました。同社は3月、AIが生成した報告が急増したと公表し、オープンソースの脆弱性プログラムのルールを厳格化しています。Googleによると、脆弱性を引き起こす方法について誤った主張をする報告や、実際のセキュリティ上の影響がほとんどないコーディング上の欠陥を指摘する報告がありました。
Googleは一部の種類の脆弱性について、再現可能な結果や受理されたパッチなど、より強力な証拠を求めるようになりました。その後は、下位に位置付けられる一部の製品脆弱性報告への報奨金の支払いも取りやめています。
ただし、報告件数が多いからといって、発見事項の価値が低いとは限りません。たとえばVercelは9月、Sandbox環境を対象とした2週間のセキュリティチャレンジで1,285件の脆弱性報告を受け取ったと明らかにしました。同社はトリアージの一部を自動化しており、最終的に数十件の報告が有効と認定されたといいます。
AIを活用した脆弱性研究は、実務上重要な発見も生んでいます。Anthropicの脆弱性探索モデル「Mythos」の支援で見つかったRejetto HTTP File Serverの重大な欠陥は、その後、悪用の試みの標的になりました。
問題はバグバウンティプログラムにとどまりません。企業がアプリケーションセキュリティのワークフローにAI支援ツールを取り入れるにつれ、脆弱性の発見件数が、その検証と修正を行う能力を上回る可能性があります。
CISOにとっての問いは、既存の脆弱性管理プロセスがこの量を吸収できるかどうかです。価値の低い発見事項に、確認済みのリスクへの対応に必要なリソースを奪われてはなりません。
検証にかかる負荷
主な懸念は、AIによって報告の件数が、チームの検証能力の拡大を上回る速さで増えかねないことです。
「説得力のある報告は、短時間で生成できます」と、Kanerikaの最高収益責任者（CRO）であるBhupendra Chopra氏は話します。「ところが、それを確かめるには、エンジニアがコードを追い、主張された攻撃条件を試す作業が依然として必要になる場合があります」
IDCの情報・データセキュリティ担当リサーチディレクターであるSakshi Grover氏は、Googleの事例は脆弱性報告の経済性に対する警告と捉えるべきだと指摘します。同じ問題がすでに企業全体に広がっている証拠ではないという見方です。
「AIは、研究者が本物の脆弱性を発見する助けになります。一方で、説得力はあるものの根拠が乏しい報告を、安価に量産することも可能にします」とGrover氏は述べます。「報告を受け取ったチームは、該当するコードが存在するのか、主張された攻撃経路に到達できるのか、セキュリティ上の意味のある影響があるのかを、結局は自分たちで見極めなければなりません」
これは企業に直接的なコストを課すことになります。十分に評価されないままアプリケーションの担当者に届いた発見事項は、該当するソフトウェアのバージョンが使われていなくても、あるいは脆弱なコードが自社環境から到達できなくても、エンジニアの時間を消費しかねません。
Chopra氏は、報告された欠陥が自社の環境に実際に影響するかどうかを確認してから、緊急の修正対象として扱うべきだと助言します。Grover氏は、CISOはAI支援のセキュリティツールを、検出した脆弱性の総数ではなく、対処可能な発見事項をどれだけ生み出すか、そしてその検証にどれだけの労力がかかるかで評価すべきだと述べました。
「発見事項のダッシュボードが大きくなったからといって、それだけでセキュリティが向上した証拠にはなりません」とGrover氏は語ります。
CISOのSunil Varkey氏は、企業はトリアージそのものをセキュリティ機能として扱う必要性が今後ますます高まると述べます。人間のレビュー担当者に届く前に、証拠要件、到達可能性のスコアリング、自動フィルタリングを適用するという考え方です。
積み上がる未対応案件への対処
次に大きな懸念となるのは、確認済みの脆弱性でさえ、限られたエンジニアリングの人員を奪い合うことです。
「報告が増えても、エンジニアリングの人員やメンテナンスの時間枠が増えるわけではありません」とChopra氏は言います。
Grover氏によると、技術的には有効な欠陥でも、展開済みの環境からは到達できないことがあります。逆に、深刻度スコアが低い脆弱性でも、外部に公開されたビジネス上重要なシステムに影響するなら、より迅速な対応が必要になる場合があります。そのため、優先順位付けでは、スキャナーが出力する深刻度評価だけに頼るよりも、展開状況や悪用の証拠のほうが役立ちます。
Confidisの創業者兼CEOであるKeith Prabhu氏は、スキャナーの検出結果は、悪用可能な脆弱性の証拠ではなく仮説として扱うべきだと指摘します。該当コードが存在し、到達可能かどうかを確認し、問題を再現して、自社環境での影響を評価する作業は、やはりチームが行う必要があります。
有用な指標のひとつは、アナリストが根拠の弱い発見事項の却下に多くの時間を費やし、その間に確認済みの高リスク脆弱性が長く未解決のまま残っていないかどうかだ、とChopra氏は付け加えました。そうなっていれば、報告プロセスそのものが、本来ならリスク低減に充てられるはずの能力を消費している可能性があります。
Grover氏は、CISOはツールが報告する問題の件数に注目するのではなく、検証にかかる労力と、確認済みの高リスクの露出がどれだけ長く放置されているかを追跡すべきだと述べました。
標的となるトリアージ
もっともらしい脆弱性報告を安価に作れることは、悪用の機会も生み出しかねません。Chopra氏は、Googleが製品脆弱性の報告受け付けを停止した判断は、同社が意図的な攪乱キャンペーンの標的になった証拠ではないとしながらも、そうしたシナリオは起こり得ると警告しました。
「フィルタリングされていない報告窓口は、攻撃者に、システムに侵入することなくセキュリティ部門の能力を消耗させる手段を与えかねません」と同氏は述べます。
たとえば攻撃者が、同じ主張のバリエーションを複数のサービスに提出する手口が考えられます。セキュリティチームは、すべて同一の問題に関するものだと判明するまで、1件ずつ調査に時間を費やすことになります。
Prabhu氏は、組織は低品質な報告が大量に届く状況を、レジリエンスとワークフローのリスクとして扱うべきだと述べました。ただし、質の低い報告がすべて意図的な攻撃の一部だと決めつけるべきではないとしています。
Chopra氏によると、再現可能な証拠を必須とし、重複する報告をまとめ、不正利用のパターンが現れたら提出を制限することで、このリスクを減らせます。
トリアージにAIを活用する機会が増えれば、新たな攻撃経路も生まれる可能性があります。Grover氏は、悪意ある脆弱性報告にプロンプトインジェクションの指示が仕込まれる恐れを挙げました。AIエージェントの評価を操作したり、連携したツールを通じて不正な操作を実行させたりすることが狙いです。
このため、提出されたテキストやコードは信頼できない入力として扱うべきだと同氏は述べます。脆弱性のテストは本番システムから切り離して行い、重要な操作は独立して確認する必要があるといいます。
「次の競争優位は、より多くの脆弱性をより速く見つけることからは生まれません」とVarkey氏は話します。「どれが本当のリスクで、どれが違うのかを、いかに素早く見極めるか。そこから生まれるのです」
Prasanth Aby Thomasは、半導体、セキュリティ、AI、EVを専門とするフリーランスのテクノロジージャーナリストです。DigiTimes Asiaやasmag.comなどに寄稿しています。
キャリアの初期には、ロイターの特派員としてエネルギー分野を取材しました。その前は、International Business Times UKの特派員として、アジアと欧州の市場やマクロ経済の動向を取材していました。
ボーンマス大学で国際ジャーナリズムの修士号、ロヨラ・カレッジでビジュアルコミュニケーションの修士号、マハトマ・ガンジー大学で英語の学士号を取得しています。また、国立台湾大学で中国語を学びました。
