AIにコードを解析させれば、脆弱性を効率よく見つけられる――。こうした期待は、すでに多くの開発現場で現実になりつつあります。一方で、セキュリティ用途のAIを本番運用するには、「脆弱性を見つけた件数」だけでは不十分です。安全なコードを誤って危険と判定していないか、深刻な脆弱性を見逃していないか。この二つを測らなければ、AIの出力を信頼できません。
今回紹介されたDeception Benchmarkは、AIによる脆弱性検出の信頼性を、偽陽性率（FPR）と偽陰性率（FNR）の両面から評価するためのベンチマークです。16のプログラミング言語、70を超えるCWEカテゴリ、14,822サンプル、12モデルを対象に評価した結果、FPRとFNRを同時に10％未満へ抑えられた構成はありませんでした。この結果は、AIが使えないことを意味するのではありません。むしろ、AIの検出結果を無検証で採用することが危険であり、用途に応じた運用設計が不可欠であることを示しています。
「見つけた数」だけではAIの性能は分からない
脆弱性検出では、実際に脆弱なコードを正しく検出した結果を真陽性、安全なコードを安全と判定した結果を真陰性と呼びます。一方、脆弱性がないコードを危険と判定するのが偽陽性、脆弱性があるコードを見逃すのが偽陰性です。
FPR（偽陽性率）は、安全なコードのうち誤って警告した割合です。FPRが高いと、開発者は大量のノイズを確認することになり、重要な警告が埋もれます。いわゆるアラート疲れが進めば、最終的には警告そのものが無視されるリスクがあります。
FNR（偽陰性率）は、実際に脆弱なコードのうち見逃した割合です。FNRが高いAIは、検出件数が多く見えても、攻撃可能な問題を取りこぼす可能性があります。特に認証、認可、入力検証、暗号処理、機密情報の扱いに関わるコードでは、少数の見逃しが重大なインシデントにつながります。
つまり、AIセキュリティツールの評価では、再現率や検出件数だけでなく、「どれだけ見逃すか」と「どれだけ誤って止めるか」を同時に確認する必要があります。Deception Benchmarkの意義は、AIが巧妙に用意された安全なコードや脆弱なコードをどの程度正しく見分けられるかを、広い言語・脆弱性カテゴリで比較しようとした点にあります。
実務ではFPRとFNRのバランスが重要
FPRとFNRは、単純に低ければよいという関係ではありません。検出感度を高める設定にすると、脆弱性を拾いやすくなる一方で、誤検出が増えることがあります。逆に、警告を厳しく絞ると開発者の負担は減りますが、見逃しが増える可能性があります。
そのため、導入時には「最も精度の高いモデルはどれか」ではなく、「どの工程で、どのリスクを、どの程度の誤差で扱うか」を定義する必要があります。たとえば、プルリクエストの初期レビューではFPRを抑えて開発者の作業を妨げないことを重視し、リリース前や重要システムの監査ではFNRを抑えるために広めの検出結果を人が確認する、といった使い分けが考えられます。
モデルや製品を比較する際は、ベンダーが示す精度だけでなく、次の情報を確認すべきです。
・評価対象の言語、フレームワーク、CWEカテゴリ ・データセットの構成と、実際のコードに近いかどうか ・FPR、FNR、適合率、再現率の定義と測定方法 ・重大度別、脆弱性タイプ別の性能 ・コード修正案を提示した場合の安全性と検証方法 ・モデル更新後に性能を再評価できる仕組み
特に、単一のサンプルやベンチマーク結果だけで製品を選ぶのは危険です。自社のリポジトリから匿名化した代表的なコードを抽出し、過去に人手で確認済みの脆弱性や誤検出事例を含む評価セットを作ることが有効です。
JavaやSpring Bootでは「文脈」の確認が欠かせない
JavaやSpring Bootのアプリケーションでは、脆弱性の有無が一つのメソッドだけでは決まらないケースが少なくありません。たとえば、入力値が危険かどうかは、Controllerで受け取った後にどのバリデーションを通り、サービス層やRepository層でどのAPIへ渡されるかによって変わります。
SQLインジェクションの判定でも、文字列連結によるクエリ生成は明確な危険信号になり得ますが、独自のラッパーや共通ライブラリを経由している場合、AIが安全性を正しく追跡できるとは限りません。同様に、Spring Securityの設定では、認証の有無だけでなく、URL単位の認可、メソッドセキュリティ、例外処理、CSRF対策などを組み合わせて評価する必要があります。
AIが「問題あり」と指摘した場合、開発者は指摘箇所だけを修正するのではなく、データの入口から危険な処理までの経路を確認しなければなりません。反対に、「問題なし」と判定されたコードについても、重要な認証・認可処理や外部入力を扱う部分は、レビューやテストを省略すべきではありません。
Human-in-the-loopを前提にした検証フロー
現実的な運用では、AIを最終判定者ではなく、優先順位付けと調査支援を担う仕組みとして位置付けるのが安全です。基本的なフローは次のようになります。
- AIと従来型の静的解析、依存関係スキャン、テストを組み合わせて候補を抽出する
- AIに脆弱性の根拠、攻撃経路、影響範囲、該当CWEを説明させる
- セキュリティエンジニアまたは担当開発者がコードと実行経路を確認する
- 再現テストや単体テスト、統合テストで検証する
- 修正後に再スキャンし、別の不具合や回帰がないか確認する
- 真陽性・偽陽性・偽陰性の結果を記録し、ルールやモデルの評価に反映する
ここで重要なのは、誤検出を単に無視して終わらせないことです。誤検出の理由を分類すれば、除外ルールの改善、コンテキスト情報の追加、プロンプトやモデル設定の見直しにつながります。見逃しが判明した場合は、なぜ検出できなかったのかを分析し、同種のコードを回帰テストへ追加します。
導入効果は「警告数」ではなく業務指標で測る
AI導入後に見るべき指標は、検出件数だけではありません。重大な脆弱性の検出率、レビュー完了までの時間、誤検出の割合、修正に要した時間、再発率、リリース後に発見された脆弱性数などを継続的に計測する必要があります。
また、チームごとに許容できるFPRとFNRは異なります。金融、医療、認証基盤などでは見逃しを極力抑える設計が必要ですが、開発初期のフィードバックでは多少の誤検出を許容して広く候補を拾う価値があります。工程ごとに閾値と人手確認の条件を分けることで、AIの利便性と安全性を両立しやすくなります。
Deception Benchmarkが示す最も重要なメッセージは、AIセキュリティ製品を「賢そうか」「多く検出できるか」だけで評価してはいけないということです。安全なコードを誤って止める頻度と、危険なコードを見逃す頻度を測り、自社の技術スタックとリスク許容度に照らして判断する必要があります。
AIは、セキュリティエンジニアや開発者の代替ではなく、調査範囲を広げ、判断を支援するための強力な補助線です。FPRとFNRを継続的に測定し、Human-in-the-loopの検証フローと組み合わせること。それが、AIを便利なデモから、信頼できるDevSecOps基盤へ進化させるための現実的な第一歩です。
出典： AWS公式ブログ