GitHubのAIセキュリティエージェントがAndroidの脆弱性24件を発見、それでも重要性を判断するのは人間

GitHubによると、同社のGitHub AI security agentは、位置情報やユーザーアカウントを露出させるバグを含むAndroidの脆弱性24件の発見・報告を支援した。件数は重要だが、より重要なのは手法である。GitHubは単に大規模言語モデルにリポジトリを渡し、セキュリティ上の問題を探すよう求めたわけではない。

Security Labの研究者Kevin Stubbingsは、監査をより小さなAndroid固有の段階へ分割する、対象を絞ったタスクフローを構築した。各段階では、露出したアプリケーションのエントリポイントを特定し、起こり得る脆弱性パターンを分類したうえで、人間によるレビューに向けた発見事項を生成する。

このワークフローは、AIセキュリティ研究に関する二つの一般的な見方に異議を唱える。一つは、自律型モデルを経験豊富な監査担当者の代替とみなす見方だ。もう一つは、誤検知をあまりに多く出す信頼できないコード補完システムとして退ける見方である。

GitHubの結果は、より限定的で有用な立場を示している。研究者が探索範囲を制約すれば、LLMは大規模なコードベースを調べ、不審な挙動のつながりを見いだせる。ただし、理論上の欠陥が実際の攻撃につながるかどうかを判断することには、なお苦戦している。

GoogleのBig Sleepプロジェクトも、モデルに具体的な脆弱性の仮説と分析ツールへのアクセスを与える、関連したアプローチを取っている。したがって競争はGitHub対Googleではない。ガイドされ、ツールに支援された調査と、誘導のないモデル推論との競争である。

GitHub AI Security Agentはプロンプトを監査パイプラインへ変えた

中心的な変化は、GitHubがセキュリティの専門知識を一つの巨大なプロンプトではなく、再利用可能な実行手順としてパッケージ化したことにある。

GitHub Security Labは2026年9月28日に調査結果を公開した。同チームによると、オープンソースのタスクフローはAndroidアプリケーション全体で24件の脆弱性を発見し、報告したという。

基盤となるフレームワークはSecLab Taskflow Agentだ。タスクフローとは、プロンプト、ツール、データ、中間目標をAIモデルに割り当てる構造化された一連の手順である。

このフレームワークは、オーケストレーションシステムと、その内部で実行されるセキュリティワークフローを分離している。これにより研究者は、エージェント全体を再構築せずに監査の一段階を変更できる。

GitHubの調査によると、Stubbingsはgather_mobile_entry_point_info.yamlというタスクフローを追加した。これは混在したリポジトリにおいて、モバイルのエントリポイントをWeb、デスクトップ、その他のインターフェースから区別する。

エントリポイントとは、攻撃者が制御する情報がアプリケーションに入り得る場所である。Androidでは、この攻撃面にexported activity、service、content provider、ディープリンク、JavaScript bridgeが含まれる。

収集段階では、アプリケーションの外部にあるどのコンポーネントが到達可能かを記録する。また、権限、exportの状態、対応する入力、境界を理解するために必要なその他の詳細も追跡する。

次の重要なコンポーネントはclassify_application_local.yamlである。このプロンプトは、各エントリポイントをモバイルソフトウェアに関連する脆弱性クラスに照らして評価するようモデルに求める。

この区別は重要である。Androidの欠陥は、しばしばコンポーネント間の相互作用から生じる。一つの関数は単独で読めば安全に見えても、外部アプリケーションが呼び出せる場合には危険になり得る。

GitHubは、confused-deputyの挙動や安全でないbroadcastなどの問題を考慮するよう、モデルに具体的に指示した。confused deputyは、特権を持つコンポーネントが呼び出し元を適切に検証せず、攻撃者が要求した操作を実行する場合に生じる。

研究者らは、繰り返し実行する中で厳格な検査と、より広範なプロンプトも組み合わせた。厳格な部分は、既知の脆弱性パターンを一貫して網羅することを目的としていた。

より広範な部分では、固定ルールでは見逃す可能性のある挙動の関連付けを、モデルが行える余地を与えた。繰り返しの実行は、LLM出力の非決定性に部分的に対処するものでもあった。

この設計は、多層的なレビューのプロセスに似ている。一つの段階で攻撃面を棚卸しし、別の段階で仮説を立て、後続の作業でそれらの仮説が詳細な検証に耐えられるかを試す。

公開されているtaskflow repositoryにより、このプロセスは検証可能かつ再利用可能になっている。そこには、ワークフロー例、支援ツール、Codespaceまたはコンテナ内で監査を実行するためのスクリプトが含まれる。

GitHubによれば、中規模のリポジトリに対するモバイル監査には1〜2時間かかる場合がある。結果はSQLiteに保存され、研究者は脆弱性の可能性があるとしてフラグ付けされた項目を絞り込める。

その出力は判定結果ではない。優先順位付けされた調査キューである。

デフォルト設定でワークフローを実行するには、GitHub Copilotのライセンスも必要となる。プロンプトはpremium model requestを利用し、多数のツール呼び出しを生成する可能性がある。

このフレームワークは設定を通じて別のAIエンドポイントにも対応する。それでもモデルを変更すれば、監査の挙動、出力品質、再現性は変化し得る。

このため、オープンソースでの公開は単なる製品デモではない。研究者はタスク分解を検証し、プロンプトを変更し、モデルを比較し、パイプラインがどこで失敗するかを測定できる。

リポジトリはこのフレームワークを実験的なものと説明している。このラベルは証拠に合致する。報告された24件の発見は実用的な価値を示すが、普遍的な検出率を確立するものではない。

GitHubは、タスクフローが見逃した脆弱性の数を示す完全なベンチマークを公開していない。また、専門家のみのレビューや既存の静的解析ツールとの統制された比較も提供していない。

この結果は、評価に関するあらゆる疑問に答えるものではないが、重要である。慎重に範囲を定めたエージェントが、本番Androidアプリケーションにまたがる実際の脆弱性開示業務に貢献できることを示している。

Androidのエントリポイントがエージェントに扱いやすい攻撃面を与えた

タスクフローが機能したのは、終わりのないコードレビューを、特定の信頼境界を横断する探索へと変換したからである。

脆弱性を見つけるようモデルに一般的に依頼すると、モデル自身が範囲を選ばなければならない。アプリケーションのアーキテクチャを推測し、危険なインターフェースを特定し、どのコードに注意を払うべきかを判断する必要がある。

その自由度は有用に聞こえるが、注意をそらす機会を増やしすぎる。大規模リポジトリには、モバイルアプリケーションと並んで、テスト、ライブラリ、ビルドスクリプト、サーバーコンポーネント、古いコードが存在する。

モバイル向けの収集タスクは、この曖昧さを減らす。別のアプリケーション、ブラウザ、リンク、ファイル、埋め込みWebページからデータを受け取るコンポーネントへと注意を向けるよう指示する。

Android intentは、このアプローチの価値をよく示している。intentとは、Androidコンポーネントに操作の実行を要求するメッセージングオブジェクトである。

Intent extrasは、その要求に追加のキー・バリューデータを載せる。activityがexportされている場合、別のアプリケーションがそれを起動し、独自のextrasを渡せる可能性がある。

Androidのintent documentationはプラットフォームの仕組みを説明しているが、安全な挙動は依然として各アプリケーションの検証ロジックに依存する。コンポーネントは、信頼された内部状態と攻撃者が制御する入力を区別しなければならない。

OsmAndのナビゲーションアプリケーションは、その違いを露呈させた。GitHubは、ディープリンクと設定ファイルのインポートを処理するMapActivityというexported activityを調査した。

コードは、一部の設定関連extrasが内部service経由で届くことを想定していた。しかし、そのexported activityは無関係のアプリケーションから提供されるextrasも受け取ることができた。

GitHubによると、これらの入力は、警告や確認を表示しないインポート処理、設定の置き換え、インポート対象となる設定の種類を制御していた。したがって攻撃者は、想定された警告や確認なしに設定を変更できた可能性がある。

セキュリティへの影響は、無許可の設定変更にとどまらなかった。研究者らは、攻撃者が地図タイルのソースを自ら管理するサーバーに置き換えられることを見いだした。

各タイルリクエストには、ユーザーが閲覧している地図領域を示す座標が含まれていた。悪意あるサーバーは、正規に見える地図画像を返しながら、それらの座標を収集できる。

GitHubは、同じ弱点によって経路の出発地と目的地も露出したとしている。被害者には地図が正常に表示され続ける一方、位置関連のリクエストは攻撃者に届くことになる。

GitHubの報告によると、Android版OsmAndのダウンロード数は1,000万件を超えていた。この配布規模により、この欠陥は孤立したデモアプリケーションの問題よりも重大なものとなった。

この仕組みはまた、不審な一行だけから深刻度を推測できない理由も示している。初期の問題は攻撃者が制御する設定に関するものだったが、その影響はデータを地図・経路サービスまで追跡することで明らかになった。

従来のルールであれば、exported componentや安全でないintent処理を特定できるかもしれない。タスクフローの価値は、そのエントリポイントと後続のセキュリティ上の影響を結び付けるのに十分な文脈を維持した点にあった。

WikipediaのAndroidケースは異なる経路をたどった。このアプリケーションはwikipedia://のディープリンクスキームを登録しており、ブラウザのリンクからアプリ内のコンテンツを開けるようにしていた。

ホスト名の検証では、想定されるベースドメインで終わるドメインが許可されていた。この種のsuffix checkは、攻撃者が制御するホスト名と正規のWikimedia宛てのホスト名を混同する可能性がある。

GitHubによると、この欠陥により、細工されたディープリンクを通じて、攻撃者が制御するページをアプリケーションのWebView内で開くことが可能だった。WebViewは、アプリ内でWebコンテンツを表示する埋め込みブラウザ領域である。

二つ目の検証上の問題はcookie処理に影響していた。研究者らは、二つの挙動を連鎖させることで、攻撃者が長期間有効なWikipediaのセッション情報を取得できると報告した。

GitHubはこの連鎖をアカウント乗っ取りの脆弱性と位置付けた。盗まれたセッションは、同一の認証コンテキストを使用するWikipediaやその他のWikimediaプロジェクトに影響を及ぼす可能性がある。

この発見には、危険なAPIを認識する以上のことが必要だった。監査では、ディープリンクの解析、WebViewのナビゲーション、ドメイン照合、cookieの露出を関連付ける必要があった。

これらこそ、リポジトリレベルのLLM分析が明らかにすると期待される関係性である。モデルは、複数のファイルにまたがって名前、制御フロー、文書化されたAPIの挙動を追跡できる。

この二つの例はまた、AI監査は単純なインジェクションのミスしか再発見しないという考えを弱める。いずれも、単一の明白に安全でない関数ではなく、アプリケーションロジックと信頼に関する前提に依存していた。

ただし、これらはエージェントがすべての調査手順を独力で完了したことを示すものではない。GitHubの説明には、プロンプト、繰り返し実行、proof-of-concept作業、モバイルセキュリティ専門家によるレビューが記されている。

正確な結論はより限定的である。タスクフローは、研究者が信頼できる報告へと発展させた、実行可能な手掛かりを生み出した。

それでも、この分業は意味のある変化を表している。研究者は、すべてのコンポーネントを列挙する時間を減らし、最も価値の高い攻撃経路の検証により多くの時間を使える。

ガイド付きAI監査は手動レビューと静的解析の双方に圧力をかける

GitHubのアプローチが既存のセキュリティワークフローに圧力をかけるのは、固定ルールと完全な手動調査の間を占めるからである。

静的解析ツールは、チームが危険なパターンを正確に記述できる場合に優れている。繰り返しスキャンでき、ビルドに統合でき、すべてのcommitで一貫した結果を出せる。

その弱点は、影響がアプリケーション固有の意味論に依存する場合に現れる。ルールは、到達可能な操作が意味のあるデータを露出させるかどうかを知らずに、exported activityをフラグ付けできる。

人間のレビュアーは、そうした意味論を判断できる。信頼境界を見極め、攻撃チェーンを組み立て、不可能な条件に依存する指摘を除外できる。

しかし、手作業によるレビューは依然として高コストで、拡張も難しい。大規模なモバイルアプリケーションでは、多数のコンポーネントが公開され、それぞれが複数のハンドラやストレージパスに接続されている場合がある。

GitHubのAIセキュリティエージェントは、その隔たりを埋めようとしている。プロンプトに専門家の着眼点を組み込みながら、固定ルールとして記述されていない関係性をモデルが調査できるようにする。

このモデルは、静的解析を不要にするものではない。CodeQL、リンター、依存関係スキャナー、プラットフォーム検査は、既知のパターンに対して引き続き決定論的なカバレッジを提供する。

ペネトレーションテストや手作業のソースコードレビューを不要にするものでもない。到達可能性、実機上での実際の挙動、ビジネス上の影響を検証するには、こうした手法が依然として必要だ。

その代わり、このエージェントはトリアージの経済性を変える。多数の候補パスを調査し、人間による評価に向けて説明、コード参照、概念実証の草案を作成できる。

この能力は、大量の未処理案件を抱えるアプリケーションセキュリティチームに圧力をかける。エージェント支援監査が初期レビュー時間を確実に短縮するなら、それを無視することは正当化しにくくなる。

また、不透明なAIセキュリティスキャナーを販売するベンダーにも圧力をかける。GitHubはワークフロー層を公開し、研究者が結論に至った経緯を検証できるようにした。

オープンなプロンプトが、すべての結果を再現可能にするわけではない。モデルのバージョン、コンテキストの選択、ツール出力、サンプリングはいずれも、検出結果を変える可能性がある。

ただし、研究プロセスへの異議申し立てや改善は容易になる。専門家は脆弱性クラスを追加し、仮定を修正し、同じタスク構造に対して別のモデルを試験できる。

GoogleのBig Sleepは、最も明確な歴史的な参照例を示している。2024年、このプロジェクトは、LLM支援によるバリアント解析を通じて発見された、悪用可能なSQLiteのメモリ安全性バグを報告した。

Big Sleep researchは、調査者が具体的な脆弱性仮説を提示した場合、現在のモデルはより優れた性能を発揮すると論じた。これにより、自由形式の調査に伴う曖昧さが減少する。

GitHubのAndroidタスクフローは、より広いワークフローの水準で同様の原則を適用している。既知の単一脆弱性ではなく、構造化されたインベントリと明示的なクラスをモデルに与える。

技術的なアプローチは異なるが、いずれも、無制限の自律性こそが進歩の主な源泉だという考えを退けている。利点は、機械による探索と慎重に選定された制約を組み合わせることから生まれる。

これが、AIセキュリティ研究で台頭している主要な競争軸だ。誘導型エージェントには、ツール、攻撃対象領域のデータ、検証可能な目標が与えられる。

非誘導型エージェントには、リポジトリと大まかな指示が与えられる。分析を行う前に、プロセス自体を考案しなければならない。

誘導型の手法は演出的ではないが、評価しやすい。研究者は、どのステップがコンポーネントを特定し、どのプロンプトが仮説を生み出したかを確認できる。

また、段階的な改善も支援する。重大度評価の失敗は、より強い推論を求める別の曖昧な要求ではなく、より良い検証ステージにつながり得る。

保守担当者にとって、これはセキュリティ知識が実行可能な成果物になり得ることを意味する。専門家のチェックリストは、文書や個人の記憶の中だけに留める必要がなくなる。

タスクフローには、何を収集し、どの脆弱性クラスを検討し、いつ概念実証を求めるかを記録できる。その後、チームはコード変更のたびにそのロジックを再実行できる。

このアプローチは、再現可能なエンジニアリング知識へ向かうより大きな動きに適合する。すでに検索可能なナレッジベースを構築しているチームは、検証済みの監査手順を運用知識として扱える。

リスクは、コード化された専門知識が古くなることだ。Androidのセキュリティ境界、アプリケーションフレームワーク、防御的なデフォルト設定は変化し続けている。

ワークフローには、作成者の盲点も反映される。タスクフローが新しいインターフェースや攻撃クラスについて一度も問わなければ、モデルはそれを一貫して調査しない可能性がある。

オープンな協業はこの問題を軽減できるが、解消することはできない。セキュリティチームには依然として、オーナーシップ、レビュー日、各ワークフローが有用であり続けることを示す証拠が必要だ。

24件の検出結果がエージェントをセキュリティの判定者にするわけではない

GitHubの最も強力な証拠は同時に、このシステムの主な限界も示している。疑わしいコードを見つけることは、悪用可能な影響を測定することより容易だ。

Stubbings氏は、モデルが低影響の問題を頻繁に返したと書いている。一部の検出結果では、攻撃者が作り出すのに苦労するような稀なアプリケーション状態が必要だった。

エージェントは重大度も誤って推定した。アプリケーションの別の場所にある緩和策によって、影響が小さくなったり、脆弱性自体が完全になくなったりする場合があった。

GitHubは例としてパストラバーサルを挙げた。パストラバーサルでは、攻撃者が制御する入力が意図されたディレクトリを抜け出し、別のファイルの場所を参照できる。

このパターンは深刻に聞こえるかもしれないが、Androidのストレージ境界は、攻撃者が到達できる範囲を大幅に制限し得る。外部ストレージ内に限定されたパスでは、機密性の高い内部データが露出しない可能性がある。

アプリケーションの優先順位ルールも別の落とし穴を生む。実際にはプログラムが保護された内部ストレージを優先するにもかかわらず、エージェントが攻撃者制御の外部データがアプリケーション状態を上書きすると仮定する場合がある。

その場合、疑わしいデータフローは主張された挙動を生まない。コードの整理が必要な場合はあっても、必ずしも悪用可能な脆弱性ではない。

GitHubは、モデルに概念実証を作成させることで評価が改善したとした。この要件は、もっともらしい説明で止まるのではなく、エージェントに仮定を検証するよう促す。

このステップには追加の時間とモデルリクエストが必要になる。また、エージェントにデバッガー、完全なビルド環境、実機での挙動、必要な実行時状態が欠けている場合には、依然として失敗する可能性がある。

フレームワーク自身のデプロイメントガイダンスも、この慎重さを強調している。そのDockerイメージは、セキュリティ境界ではなくデプロイメントの利便性として説明されている。

この警告が重要なのは、セキュリティエージェントが信頼できないリポジトリを処理するためだ。ソースコード、ビルドスクリプト、依存関係、ツール出力はいずれも、自動化されたワークフローに影響を及ぼし得る。

チームは監査を本番認証情報や機密システムから隔離すべきだ。また、エージェントが呼び出せるツールと、生成データの保存先も確認すべきである。

偽陽性は、別の運用上のリスクを生む。説得力はあるが無効な報告を大量に生成するパイプラインは、保守担当者や研究者の注意を消耗させかねない。

偽陰性は依然として見えにくい。GitHubは発見件数を公表したが、監査対象アプリケーションについて完全なグラウンドトゥルースの集合は存在しない。

この分母がなければ、読者は再現率を計算できない。24件の検出結果は、強力なカバレッジを示すかもしれないし、利用可能なバグのごく一部にすぎないかもしれない。その中間である可能性もある。

公表された例も、選定された事例だ。GitHubは、多くの検出結果がパストラバーサルなど比較的単純な問題に関係しており、重大な影響を持つものは少数だったと述べている。

この選定は手法を説明するうえで妥当である。ただし、読者が2つの見出し事例を典型的な出力として扱うことはできない。

分析担当者の工数、モデル消費量、再現作業、却下された検出結果を網羅するコスト比較も公開されていない。GitHubは、監査で多くのプレミアムリクエストを使用する可能性があると警告している。

実行時間が1時間または2時間であることは、修正に1時間または2時間しかかからないことを意味しない。エンジニアは依然として問題を再現し、影響を受けるバージョンを評価し、修正を書き、開示を調整しなければならない。

したがってAIセキュリティエージェントが変えるのは、ファネルの入口部分だ。脆弱性管理のライフサイクル全体を自動化するものではない。

重大度はデプロイメントの文脈に依存するため、依然として人間の責任である。同じコードでも、権限、Androidのバージョン、アプリケーション構成によって異なる結果をもたらし得る。

開示の判断にも判断力が必要だ。保守担当者が修正を検証し、更新版を配布する間、研究者はユーザーを危険にさらさないようにしなければならない。

GitHub Security Labのアドバイザリは、個別の事例が公開されるにつれて証拠を提供する。読者は、この作業を評価する際、見出しの数字だけではなく、それらの記録を用いるべきだ。

独立した評価があれば、この主張はさらに強化される。有用なテストでは、タスクフローを静的アナライザー、支援なしのモデル、経験豊富なモバイルレビュー担当者と比較するだろう。

研究者は、確認された検出結果、却下された候補、分析担当者の時間、モデル構成、既知の見逃された脆弱性を報告すべきだ。これらの指標により、ワークフローが監査全体の効率を改善するかどうかが明らかになる。

より広範な研究文献も、この慎重な姿勢を支持している。LLMセキュリティエージェントは計画を立て、ツールを利用できるが、その評価手法は研究間で依然として一貫していない。

洗練されたエクスプロイトの説明を生成するエージェントは、証拠が保証する以上に確信的に見えることがある。セキュリティチームは、流暢さを検証ではなく表現として扱わなければならない。

この限界は結果を無効にするものではない。適切な役割を定めるものだ。

エージェントは、コードとAPIに関する有用な知識を備えた、疲れを知らない仮説生成器として機能する。資格を持つ研究者は、その仮説が現実に耐えられるかを判断する責任を引き続き負う。

次のAndroid監査で証明すべきこと

次の試金石は、別のエージェントが検出結果を生み出せるかではなく、チームがカバレッジ、コスト、検証品質を測定できるかどうかだ。

まず注目すべきシグナルは、残るAndroid脆弱性の開示記録である。GitHubは24件の問題を発見し報告したと述べたが、すべての事例が公開されているわけではない。

追加のアドバイザリにより、影響を受けるアプリケーションと脆弱性クラスの分布が明らかになる。また、保守担当者が報告をどの程度受け入れ、修正をリリースしたかも示される。

開示によって、独立して確認された高影響のチェーンが複数明らかになれば、GitHubの主張は強まる。残りの検出結果の大半が低重大度であれば、この手法は専門家レビューを変革しなくても役立つ可能性がある。

2つ目のシグナルは、再現可能なベンチマークである。GitHubまたは独立した研究者は、既知で過去に修正された脆弱性を含むアプリケーションに対し、固定されたタスクフローのバージョンを実行すべきだ。

有用なベンチマークでは、発見率、偽陽性率、反復実行間のばらつき、モデル消費量、分析担当者の検証時間を測定する。また、どの失敗がコンテキスト不足に起因したかも記録すべきである。

そのようなテストにより、Android固有のプロンプトが汎用的な監査指示を一貫して上回るかが明らかになる。また、その改善が異なるモデル間でも持続するかも示される。

ワークフローが非決定的なシステムを使用するため、再現性は特に重要だ。2回の実行で異なるパスを探索したり、同じ証拠に異なる重要度を与えたりすることがある。

GitHubが示唆するように、反復実行はカバレッジを向上させる可能性があるが、コストも増加する。ベンチマークでは、追加の実行が有益な検出結果を生まなくなる時点を特定すべきだ。

3つ目のシグナルは、より深い実行時統合である。GitHubは、デバッガーと概念実証の実行を、誤った重大度評価を減らす方法として明示的に挙げている。

アプリケーションをビルドし、エミュレーターを起動し、コンポーネントをトリガーし、ストレージの挙動を観察できるエージェントは、より多くの仮定を検証できる。そのアクセスは封じ込めのリスクも高める。

したがって将来のタスクフローには、より良いツールと並行して、より強力な安全管理が必要になる。サンドボックス化されたビルド、制限されたネットワーク、記録される操作、使い捨てのテスト環境が標準となるべきだ。

実行時フィードバックによって偽陽性が大幅に減少すれば、誘導型エージェントは継続的なセキュリティテストに近づく。エントリーポイントや信頼に敏感なコードが変更された際、対象を絞った調査を再実行できるようになる。

偽陽性が高止まりするなら、この技術は研究支援に近い位置に留まる。その結果でも有用ではあるが、無監督での利用は制限される。

Android開発者は、すべてのベンチマーク結果を待つ必要はありません。エクスポートされたコンポーネント、ディープリンクの検証、WebViewブリッジ、ファイル処理、アプリケーション間のデータフローは、今すぐレビューできます。

オープンソースのワークフローを試すチームは、理解しているコードから始めるべきです。未知の本番リポジトリよりも、既知の脆弱性のほうが安全なキャリブレーションセットになります。

研究者は、受け入れたすべての検出結果について、モデル、プロンプト、コミット、ツール設定、証拠を保存すべきです。その記録があれば、モデルの挙動が変化した際にも後からレビューできます。

また、検出と深刻度の評価は分けるべきです。一方の段階で疑わしい経路を提示し、もう一方の段階で実行時の証拠を求め、緩和策を文書化することができます。

最も重要なのは、保守担当者がクリーンな結果を安全性の証明として扱わないことです。エージェントが検出しなかったという事実は、ある設定における特定のワークフローの探索結果を示すにすぎません。

GitHubのAIセキュリティエージェントの取り組みが説得力を持つのは、自律性と懐疑主義の間に誤った二者択一を設けていないからです。構造化されたエージェントは、最終的な権威にならずとも、実質的なセキュリティ価値を生み出せます。

Androidの24件の脆弱性は、研究者が暗黙知の専門性を再利用可能なタスクへと変換したときに何が起こるかを示しています。同時に、検証が依然として決定的な工程である理由も示しています。

エンジニアリングリーダーにとって、当面の問いは実務的です。最終判断を必要とせずに専門家の時間を消費しているレビュー工程はどれでしょうか。そうした工程こそ、ガイド付き自動化の最適な候補です。

セキュリティ研究者にとっての機会は、調査手法を検査可能で、再現可能で、共有しやすいものにすることです。オープンなタスクフローは、その目標に向けた一つの道筋を提供します。

保守担当者にとって、次の一手はよりシンプルです。公開されたワークフローを調べ、隔離環境でテストし、既存のセキュリティプロセスによる検出結果と比較してください。

見出しの数字は、評価の出発点であって終着点ではありません。GitHubはエージェント主導のワークフローでAndroidの脆弱性を24件発見しましたが、どの検出結果が真に重要かを確立したのは人間でした。