AWSのAI脆弱性検出はバグを捉える一方、誤検知が信頼の溝を露呈
AWSは汎用AIモデル12種類をテストし、顕著な矛盾を見いだした。モデルは脆弱性の大半を検出した一方で、安全なコードを危険と判定するケースも多かった。
新たなDeception Benchmarkは、AWSのAI脆弱性検出に関する主張を、別のバグ検出リーダーボードより厳しい形で検証する。疑わしいコードが、実際には機能する緩和策によって保護されている場合をモデルが見分けられるかを問うものだ。直接的なプロンプトでは、テスト対象モデルは安全なサンプルの41%から99%を脆弱と判定した。
この結果は、AIセキュリティツールをめぐる議論の焦点を変える。すべてのアラートがエンジニアリング時間を消費する環境では、疑わしいパターンを見つけるだけでは不十分だ。現在の本当の競争は、高速なパターン認識と証拠に基づく検証の間で繰り広げられており、その差額をセキュリティチームが負担している。
AWSは2026年9月9日、16のプログラミング言語と70を超えるCommon Weakness Enumerationカテゴリにまたがる14,822件のサンプルを含むベンチマークを公開した。テストした構成のうち、誤検知率と見逃し率の双方を10%未満に抑えるというAWSの最低基準を満たしたものはなかった。
AWSは安全なコードが危険に見えるベンチマークを構築した
このベンチマークは、モデルが既知の脆弱性パターンを認識できるかではなく、実際に悪用可能かを理解しているかを測定する。
多くのセキュリティ評価では、脆弱なソフトウェアから始め、AIシステムに欠陥の特定または悪用を求める。このアプローチは有用な攻撃側の能力を明らかにするが、防御性能の全体像を示すものではない。本番環境のレビュー担当者には、実際の攻撃経路を作り出さずに、脆弱性に似ているコードを問題なしとして除外する能力も必要だ。
AWSは、この違いを軸にDeception Benchmarkを設計した。その安全なサンプルには、現実的なフレームワーク、危険に見えるデータフロー、認識しやすいセキュリティ上の兆候が含まれる。巧妙な緩和策が悪用経路を閉じており、モデルは保護が実際に機能するかを判断しなければならない。
ベンチマーク公開記事で説明された例の一つは、ユーザー入力を受け取り、データベースを照会するFlaskエンドポイントに関するものだ。周辺のパターンはSQLインジェクションに似ている。しかし、パラメータ化されたステートメントにより、入力が実行可能なクエリ構文になることは防がれている。
パターンの認識で止まるモデルは、脆弱性を報告するだろう。データフロー全体を追跡するモデルは、そのサンプルを安全と分類すべきだ。この差が、出力が有用な証拠になるか、あるいは手作業の調査を必要とする別のアラートになるかを決める。
ベンチマークには6,988件のコードレベルの課題が含まれる。これらは、巧妙な修正によって異なる脆弱版と安全版を提示する。両方のバージョンが疑わしく見える場合があるが、悪用可能なのは片方だけだ。
さらに2,707件の課題では、デプロイ環境の文脈が加わる。ソースコードは脆弱に見えても、インフラストラクチャの制御によって攻撃が阻止される可能性がある。例には、Kubernetes Network Policyがサーバーサイドリクエストフォージェリを阻止するケースや、ID境界が権限昇格を防ぐケースが含まれる。
こうした環境依存のケースが重要なのは、エンタープライズセキュリティが一つのファイルで完結することはほとんどないためだ。悪用可能性は、設定、ネットワーク到達性、権限、実行時の挙動、補完的統制に左右される。こうした条件を無視するスキャナーは、デプロイ済み環境では発生し得ない、もっともらしい攻撃を記述する可能性がある。
AWSによると、すべてのサンプルはベンチマーク向けに作成され、実際のセキュリティパターンに基づいている。同社は、課題を生成し、最先端モデルでテストし、容易なケースを強化し、このプロセスを繰り返す敵対的な開発ループを用いた。
この手法により、データセットは意図的に難しくなっている。また、結果をすべてのソースリポジトリにおける代表的な失敗率と見なすべきではないことも意味する。このベンチマークは、日常的なコードレビューの無作為抽出ではなく、浅い推論をあぶり出すよう設計されたケースを選んでいる。
その価値は、特定の能力を切り分けている点にある。モデルは、実際の弱点と説得力のあるおとりを区別できるほど長く、攻撃連鎖を追跡できるのか。この問いこそが、信頼できるAWS AI脆弱性検出の中心にある。
公開されたベンチマークリポジトリには、14,822件のサンプルすべてが含まれている。AWSはそのうち9,695件を採点対象とし、5,127件は採点対象外としている。後者には、見解が分かれるケースや意図的に曖昧にしたケースが含まれる。
ラベルは公開されていない。参加者は、AWSが精度およびエラー率の結果を返す前に、説明を含むすべてのサンプルの予測を提出する必要がある。このアプローチは、記憶による回答やベンチマーク専用のチューニングを抑えることを目的としている。
AWSはまた、独立したレビュー担当者がラベルを繰り返し精査したとしている。争いのあるサンプルはラベルを修正するのではなく、採点対象外のプールに移された。同社によれば、無作為に選んだ採点対象サンプル100件を人間がレビューした結果、誤りは見つからなかった。
とはいえ、データセットが批判の余地を超えたわけではない。独立研究者は依然として、その構築方法、カテゴリのバランス、採点プロセス、実世界への転用可能性を検証する必要がある。ただし今回の公開により、外部チームは同じ敵対的条件下でシステムを比較する共通の基準を得た。
AWSのAI脆弱性検出結果は二つの悪い選択肢を示す
直接プロンプトは誤報を増やしすぎる一方、より厳格な証明要件はモデルによる実際の脆弱性の見逃しを増やす。
AWSは、五つのプロバイダーによる12モデルを、二つのプロンプト戦略で評価した。直接プロンプトでは、各モデルにコードを脆弱または安全として分類させた。悪用証明プロンプトでは、脆弱性と宣言する前に具体的な攻撃手法を構築するよう求めた。
このベンチマークは、異なる運用上の失敗を生むため、二つのエラー種別を分けている。誤検知は安全なコードを脆弱と判定することだ。見逃しは実際の脆弱性を安全と分類することだ。
直接プロンプトでは、モデルは概して検出感度を優先した。AWSによると、実際の脆弱性の最大95%を検出した。しかし同時に、安全なコードの41%から99%を脆弱と判定した。
この偏りは、モデルを積極的かつ慎重に見せる場合がある。また、実際に見つけた脆弱性の割合を測る再現率を守る簡単な方法でもある。すべてを脆弱と判定するシステムは脆弱性を見逃さないが、ユーザーを無用なアラートで埋め尽くす。
Mistral Largeは、この失敗モードをよく示している。直接プロンプト構成では、誤検知率99%、見逃し率0%を記録した。ほぼすべての安全なケースを危険と扱うことで、脆弱なケースを見つけていた。
ほかの直接構成も同様の挙動を示した。GPT-5.6 Solは誤検知率92.5%、見逃し率0.9%を記録した。Claude Haiku 4.5は誤検知率92.1%に達し、見逃しは記録されなかった。
Amazon自身のNova 2 Liteも例外ではなかった。直接プロンプトでは、AWSは誤検知率89.2%、見逃し率1.2%と報告した。Amazonのモデルを含めたことで、この公開は外部プロバイダーを狙った比較以上のものになっている。
Claude Opus 5は、掲載されたシステムの中で直接プロンプト時の最も優れたバランスを示した。精度は77.3%、誤検知率は41.5%、見逃し率は5.2%だった。それでも、この結果はAWSが示す本番利用のしきい値を大きく超えていた。
精度だけでは、こうした違いは見えにくい。ベンチマークは安全なケースと脆弱なケースがほぼ均衡しているため、常に「脆弱」と答える分類器でも50%近い精度を記録できる。見かけ上の精度は、すべての安全なサンプルがアラート化される事実を隠してしまう。
そのためAWSは、同社が寛大と呼ぶ最低基準を設定した。本番対応の構成では、両方のエラー率を10%未満に抑えるべきだとした。テストした構成でこの目標に到達したものはなかった。
直接プロンプトの結果は、AI脆弱性検出を再現率だけで評価できない理由を示している。ほぼすべての実際の欠陥を検出できることは安心材料に聞こえるが、安全なコードの大半も警告を発したと知れば話は変わる。
これは表面的な品質の問題ではない。すべての誤報はワークフローに入り込む。誰かがコードを検査し、指摘された経路を再現し、設定を確認し、担当チームに相談し、その指摘をクローズできる理由を記録しなければならない。
エンタープライズ規模では、そのレビューコストが自動化で期待される速度上の優位性を打ち消しかねない。また、過去のアラートの多くが誤りだったために、エンジニアが検出結果を軽視し始めるアラート疲れを招く可能性もある。
セキュリティ上の帰結は不都合なものだ。モデルの再現率が優れていても、誤検知率の高さは間接的にリスクを高め得る。重要なアラートは、数十件の説得力ある誤りと注意を争うことになる。
先行する学術研究でも同じパターンが確認されていた。2024年のセキュリティ評価では、228のコードシナリオにわたり八つの言語モデルをテストし、高い誤検知率を報告した。モデルは、テスト対象コードにパッチが適用された後も脆弱性の指摘を続ける場合があった。
この研究では、非決定的な回答や、単純なコード変更に対して脆弱な推論も確認された。AWSによるより大規模な公開は、より多くの言語、弱点カテゴリ、モデル、そして敵対的に構築された安全な例にわたって、この懸念を拡張している。
悪用の証明はノイズを減らすが、新たな盲点を生む
証拠を求めることで規律は向上するものの、テスト対象モデルはしばしば本物の脆弱性を見落とすことでその精度を得ていた。
悪用証明プロンプトは、モデルに疑いを超える判断を求める。コードを脆弱と判定する前に、攻撃者が利用できる具体的な経路を説明しなければならない。これにより判断のしきい値は、「危険に見える」から「攻撃の仕組みを説明できる」へと変わる。
AWSは、この戦略により誤検知率が17から74ポイント低下したと報告した。これは意味のある改善だ。ただし、より厳格なアプローチでは見逃し率も上昇し、7%から44%の範囲となった。
GPT-5.4は、このトレードオフを最も明確に示している。直接構成では誤検知率81%、見逃し率1.5%だった。悪用証明プロンプトでは誤検知は10.1%に下がったが、見逃しは33.6%に上昇した。
Llama 3.3 70Bも同様のパターンを示した。誤検知率は84.2%から10.2%に低下した。一方、見逃し率は1.1%から44.2%へ上昇し、この構成は採点対象の脆弱性のほぼ半数を見逃したことになる。
Claude Opus 5は、悪用証明プロンプトで最高の総合精度79.3%を記録した。しかし、誤検知率24.9%、見逃し率16.8%であり、いずれもAWSのしきい値を満たさなかった。
この結果は、悪用証明プロンプトが無効であることを意味しない。プロンプトによって、モデルがどの種類の誤りを犯すかが変わることを示している。セキュリティ責任者は、より多くの誤報、より多くの見逃し、あるいは慎重に測定された両者の組み合わせのうち、自らのワークフローがどれを受け入れられるかを判断しなければならない。
その判断はアプリケーションに依存する。インターネットに公開された認証サービスのレビューでは、見逃せる脆弱性はより少ない。一方、低リスクの社内リポジトリでは、小規模なエンジニアリングチームを疲弊させないために精度を優先する可能性がある。
深刻度も、しきい値に影響すべきだ。システムは、高い確信度を伴う重大な検出結果を即時の人手レビューに回し、より弱い警告は低優先度の検証で扱うことができる。単一のグローバル分類しきい値が、すべてのコードベースに適合する可能性は低い。
ここで、ベンチマークの単一ターン設計が重要になる。AWSは、エージェントの足場となる仕組み、外部ツール、反復的な検証ループを意図的に排除した。目的は、完成された商用セキュリティ製品ではなく、基盤モデルに内在する推論能力を測定することだった。
したがって、この結果は、すべてのエージェント型スキャナーが同じ失敗率を示すことを証明するものではない。製品は、言語モデルを静的解析、動的テスト、リポジトリの文脈、ポリシーチェック、決定論的なエクスプロイト検証と組み合わせられる。こうした要素は運用上の特性を変えうる。
AWSもその違いを明確に認識している。同社のベンチマークでは、エージェント型の提出結果を単一ターンのモデル結果とは別に受け付けている。この分離により、ツール支援を受けたシステムが、補助なしのモデル呼び出しと同等であるかのように提示されることを防いでいる。
この留保は、ベースラインの意義を損なうものではない。すべてのエージェント型ワークフローは、基盤モデルの制約をある程度引き継ぐ。弱い判断を繰り返しても、欠けている技術的事実を補うことなく、より精巧な説明が生まれるだけになりうる。
システムには、新たな証拠を得る信頼できる情報源が必要だ。テストを実行し、ファイルをまたぐデータの流れを追跡し、デプロイメントポリシーを調べ、エンドポイントに到達可能かを検証する場合もある。モデル呼び出しを複数回行うだけでは、理解が深まる保証にはならない。
最も難しいのは、安全性を証明することだ。攻撃テストでは、エクスプロイトが成功したか失敗したかという目に見える結果が得られることが多い。試行の失敗は他のエクスプロイトが存在しないことを証明しないため、成功がないことの意味を解釈するのは依然として難しい。
AWSの環境条件付きの例は、この問題をさらに明確にしている。モデルはコードとインフラストラクチャをまたいで推論し、最初に見つけた経路が緩和策によって遮断されていることを認識しなければならない。AWSによれば、モデルは危険なパターンを見つけても、近くにある制御策を見落とすことが多かったという。
この挙動は、セキュリティレビューでよく見られる人間のバイアスに似ている。レビュー担当者が見慣れた脆弱性の形を認識すると、反証より先に確証を得てしまうことがある。言語モデルは、パターン認識が回答生成の中核にあるため、この問題を増幅させる。
購入者にとっての実務的な教訓は明確だ。AIセキュリティ製品が悪用可能性を検証しているか、また両方の誤り率をどのように測定しているかを尋ねるべきである。偽陽性データを伴わない再現率の数値だけでは、製品が生み出す作業負荷についてほとんど分からない。
AWS独自のセキュリティシステムが示す、アーキテクチャの重要性
AWSの本番環境に関する主張は、安全かどうかを補助なしのモデルに判断させるのではなく、多層的なエージェント、決定論的なチェック、人間による承認に依拠している。
このベンチマークは、AWSが2つのエージェント型セキュリティシステムを説明してから数か月後に登場した。これらの先行する開示は重要な対比を示している。Amazonが、今回直接測定された制約をどのように管理しようとしているかを示すからだ。
RuleForgeは、公開されているエクスプロイト例から検知ルールを生成する。AWSによれば、このシステムは2025年の最後の4か月間において、手作業のプロセスと比べてルール作成の生産性を336%向上させた。
そのアーキテクチャは、タスクを専門化された段階に分割している。あるコンポーネントが脆弱性情報を取り込み、優先順位を付ける。生成エージェントが複数の検知ルールを提案する。別の判定役がそれらを評価し、合成テストが検証を行い、トラフィックデータがさらなる検証を支える。
最終承認のゲートはセキュリティエンジニアだ。この人間の役割は重要である。RuleForgeは、AIモデルの確信度だけをデプロイの十分な根拠とは見なしていない。
AWSは、生成モデルに自身の成果物を評価させた場合、ほぼすべてのルールを高く評価したと述べている。同社のRuleForge分析によれば、評価を別のモデルへ移したことで、真陽性の検知数を維持しつつ、偽陽性を67%削減した。
判定役には、領域固有の質問も与えられた。ルールが正しく見えるかを問うのではなく、悪意あるリクエストを見逃す可能性があるかを問うた。また、そのルールが脆弱性の仕組みを捉えているのか、それとも相関する表面的な特徴にすぎないのかもテストした。
この違いはDeception Benchmarkにも通じる。緩い式はシングルクォートを含む入力に一致するかもしれないが、その文字に一致しただけではSQLインジェクションを証明しない。ルールは、エクスプロイトの挙動と、同じ特徴を持つ無害なトラフィックを区別しなければならない。
AWS Security Agentは、自動ペネトレーションテストに関連する戦略を用いる。専門エージェントがアプリケーションを探索して候補となる所見を作成し、検証役が悪用の証拠を要求する。
AWSは、同社のシステムが、キャプチャー・ザ・フラッグの指示と採点者からのフィードバックを受けた場合、CVE Bench v2.0で92.5%の攻撃成功率を達成したと報告している。これらの補助なしでは80%に低下し、学習データのカットオフがベンチマークより前のモデルでは65%に達した。
これらの数値は、防御面での精度ではなく、攻撃の成功を測定している。CVE Benchには脆弱なアプリケーションが含まれ、エージェントが既知の欠陥を悪用できるかをテストする。システムが安全なコードをどの程度の頻度で問題ありと判定するかには答えない。
それでも、エージェントアーキテクチャは、ベンチマークの弱点に対する信頼できる対応を示している。候補となる所見は決定論的なチェックとモデルベースのチェックを受け、レポートには悪用の証拠と技術的な文脈が含まれる。
このことが一見矛盾して見えるのは、「AI脆弱性検知」を単一の手法として扱う場合だけだ。基盤モデルのベンチマークは、単一パスにおける弱い判断を明らかにする。AWSの本番システムは、証拠を集め、その判断を制約するワークフローから価値を得ると主張している。
この比較は、より正確な結論を裏付ける。汎用モデルはセキュリティ自動化の有用な構成要素だが、その出力が運用上信頼に値するかどうかは、周囲のシステムによって決まる。
ベンダーは、繰り返しプロンプトにエージェントというラベルを付けるだけでは、その隔たりを埋められない。重要なのは、ツール、証拠、キャリブレーション、失敗時の処理、人間による監督に関する問いである。購入者は、最初の疑いから最終的な所見に至るまでに何が変わるのかを尋ねるべきだ。
製品は、脆弱とされる経路を実行するのか。インフラストラクチャの制御策を調査するのか。リポジトリ境界をまたいでデータを追跡できるのか。結果を決定論的なアナライザーと比較するのか。レビュー担当者は、なぜ所見が検証を通過したのかを確認できるのか。
チームには、調査中に持続的な文脈も必要となる。アーキテクチャノート、過去の例外、脅威モデル、修正判断は、しばしば文書や会話にまたがって存在する。検索可能なエンジニアリングナレッジベースは、レビュー担当者がその文脈を取り戻す助けになるが、技術的検証の代わりにはならない。
調達評価では、3つの層を区別すべきだ。第1は基盤モデルであり、Deception Benchmarkが共通のベースラインを提供する。第2は検証アーキテクチャで、システムが追加の証拠をどのように収集するかを決める。第3は、レビューの責任者と許容可能なリスクを含む運用プロセスである。
製品は、ある層では優れていても別の層では劣る可能性がある。有能なモデルでも、曖昧なプロンプトや文脈の欠如によって弱体化しうる。能力が低いモデルでも、限定的なツールと厳格な検証が判断を制約すれば、より有用になりうる。
AWSの開示には、本番パフォーマンスに対する独立監査ではなく、同社が報告した結果も含まれている。336%の生産性向上と67%の偽陽性削減という主張は、Amazonの評価下におけるRuleForgeを説明するものだ。無関係なリポジトリや製品に一般化すべきではない。
この不確実性は、公開ベンチマークの必要性をさらに強める。ベンダーは完全なシステムをDeception Benchmarkに提出し、エージェント型の結果を別途報告できる。そうすれば顧客は、互換性のないケーススタディに依存するのではなく、共通のタスクの下で示された主張を比較できる。
偽陽性がAIの速度を人間の作業に変える
ビジネス上のリスクは、AIが何も見つけないことではない。もっともらしい誤りが、本当の所見を確認すべき人々の時間を消費することだ。
セキュリティツールは長年、偽陽性に苦しんできた。従来の静的アプリケーションセキュリティテストは、完全な実行時の文脈がないまま、危険なデータフローや構文をソースコードからスキャンする。AIはより優れた意味的推論を約束するが、AWSの結果は、認識しやすいパターンが依然として強く作用することを示している。
緊急のSQLインジェクション警告を受け取る開発チームを考えてみよう。エンジニアは予定していた作業を止め、担当者を見つけ、クエリの経路を確認し、パラメータバインディングによってインジェクションが防がれていることを確かめる。そして、次回のスキャンで再び開かれないよう、アラートにはクローズに関する記録が必要になる。
一つの誤りなら対処可能に思える。だが、数千のリポジトリと頻繁なスキャンが計算を変える。偽陽性率が高いと、自動検知は繰り返し発生する手動検証の待ち行列へと変わる。
その待ち行列は複数のコストを生む。修正対応が機能提供を中断するため、エンジニアリング作業は遅くなる。セキュリティチームはスキャナーの信頼性を擁護するために時間を費やす。アプリケーションの所有者は、アラートを未検証の提案として扱うようになる。
やがて信頼は損なわれる。本物の脆弱性が同じ経路で届き、同様に懐疑的な反応を受ける可能性がある。検知システムは依然として欠陥を「見つけた」ことになるが、運用上は適時の行動につなげられず失敗している。
偽陰性は逆の危険を生む。より厳格なシステムは、報告する問題を減らすことで中断を減らせるが、本物の欠陥を大きな割合で見逃すなら、その沈黙は信頼しにくくなる。
これが、AWSの二重しきい値が重要である理由だ。適合率だけを測定すれば、ほとんど何も報告しない保守的なシステムが有利になる。再現率だけを測定すれば、ほとんどすべてにフラグを立てる積極的なシステムが有利になる。本番環境での判断には、脆弱性の深刻度とコードの文脈ごとに区分した両方の値が必要だ。
チームは、ベンダーがどのように正解ラベルを確立したかも尋ねるべきだ。コードは可視範囲の関数外にある理由で安全な場合があるため、脆弱性ラベルの判定は難しい。依存関係、構成、認証、ネットワーク制御、デプロイメント状態は、悪用可能性を変えうる。
Deception Benchmarkチームは、繰り返し行う独立レビューと、争いのある事例を採点から除外することで、ラベル誤りを抑えようとした。これは慎重な設計判断だが、別の問いも生じる。明確に裁定されたサンプルは、実際のエンタープライズシステムにある曖昧さとどの程度似ているのか。
実際のリポジトリには、不完全なテスト、文書化されていない前提、古い構成、生成コード、所有者の不在が含まれる。ツールは、脆弱か安全かという二択を強いるのではなく、証拠が不十分であると述べる必要があるかもしれない。
ベンチマークは現在、その二択の判断を求めている。詳細な説明は必須だが、棄権は採点対象の結果として挙げられていない。将来の評価では、較正された不確実性がチームのレビュー作業の配分に役立つかを検討できるだろう。
レイテンシーとコストにも注意を払うべきだ。マルチエージェントシステムは、テストを実行し、より広い文脈を調べることで、偽陽性を減らせる可能性がある。その改善には、より多くの計算資源、長いレビュー時間、機密性の高いコードやインフラストラクチャへのアクセスが必要になる場合がある。
こうしたトレードオフは、エージェント型検証の有効性を否定するものではない。それがどこに属するかを決める。高リスクな変更ではより深い分析が正当化される一方、通常のコードでは、より安価なスクリーニングの後に選択的なエスカレーションが必要になるかもしれない。
セキュリティリーダーは、一つの見せかけの指標を別の指標に置き換えることを避けるべきだ。総合精度スコアは誤りの方向を隠す。劇的な生産性の数値はレビュー負荷を隠しうる。印象的なエクスプロイト成功率は、安全なコードについてほとんど語らない。
信頼できる評価では、少なくとも5つの事項を開示すべきである。偽陽性率、偽陰性率、カバレッジ、検証方法、脆弱性カテゴリ別のパフォーマンスだ。また、拒否や無効な出力を黙って除外するのではなく、それらも明示すべきである。
あるAWSの結果でカバレッジに影響が出た。ほとんどの構成では、少なくとも98%のサンプルで有効な回答が返された。GPT-5.6 Solは、エクスプロイト実証を促すプロンプトでは93%にとどまった。プロバイダーの安全性フィルターが、一部のエクスプロイト構築リクエストを拒否したためだ。
この点は、実運用におけるもう一つの制約を示している。セキュリティエージェントは、防御策を検証するために有害な手法について推論する必要がある場合がある。モデルの安全制御は正当な評価を妨げることがあり、無視すべきではない欠損結果を生む。
企業の購入担当者にとって、短期的に最も適した立場は管理された支援だ。AIには優先順位付け、説明、証拠の収集を任せる。一方で、特にデプロイ環境やビジネスロジックが攻撃の成立を左右する高リスクなコードパスでは、人間による検証を維持すべきである。
そうすると、価値提案はより限定的になるが、より擁護しやすくなる。AIは探索時間を短縮し、仮説を浮かび上がらせることができる。出力に自信に満ちた技術的表現が含まれているというだけで、単独での権限を与えるべきではない。
セキュリティチームが次に注視すべきこと
このベンチマークが重要性を持つのは、ベンダーが完全なシステムをテストし、バランスの取れたエラー率を公表し、その改善が実際のリポジトリでも維持されることを示した場合に限られる。
最初のシグナルは参加状況だ。AWSは開発者に対し、14,822件すべてのサンプルを実行し、検証済みのスコアリングに向けて予測を提出するよう求めている。ツールを用いる複数ステップのシステムは、単一ターンのモデルとは別に評価される。
独立した提出結果によって、エージェント型の検証が測定された差を埋められるかが明らかになる。完全なシステムが両方のエラー率を10%未満に押し下げれば、アーキテクチャが弱いベースライン判断を補えるというAWSの見解を裏付けることになる。そうならなければ、信頼性の問題はさらに根深い。
2つ目のシグナルは再現性だ。研究者は公開されたサンプル、チャレンジの分類、採点対象外のプール、非公開ラベルのプロセスを検証すべきである。独立したグループによる比較可能な評価があれば、モデルの順位や失敗パターンがAWSの構築手法の外でも持続するかを示せる。
3つ目のシグナルは本番環境での証拠だ。ベンダーは、ユーザーが調査、却下、再オープンし、最終的に修正するアラートの件数を開示すべきである。こうしたワークフローの結果は、モデル単体の分類スコアより重要だ。
このベンチマークは、購入者にとってよりよい提案依頼の基準にもなる。ベンダーには、自社システムを提出し、検証済みの偽陽性率と偽陰性率を共有するよう求めるべきだ。さらに、重要なコード、環境条件に左右される検出結果、未対応言語に対して、検証プロセスをどのように変えるのかを確認するべきである。
開発者は、ツールが不確実性をどのように提示するかを注視すべきだ。有用なレビューツールは、確認済みのエクスプロイト経路、もっともらしい懸念、欠けているコンテキストを区別できる必要がある。これらを同一視すると、避けられる作業が増え、システムの実際の確信度も見えなくなる。
AWSのAI脆弱性検出研究は、AIによるセキュリティレビューが役に立たないことを示したわけではない。規律ある検証を伴わない検出が、なぜ高コストでリスクを伴い続けるのかを示したのだ。
次の検証は、プロダクトチームと購入者に委ねられている。検出結果が緊急対応としてエンジニアに届く前に、コードトレース、環境チェック、再現可能な検証を通過するという証拠を求めるべきだ。あなたのセキュリティベンダーは、両方の種類の誤りを公表するだろうか。それとも、その背後にあるレビューキューを開示せず、速度だけを売り続けるのだろうか。
