海の向こうの“セキュリティ”

AI時代のAppSec――AIセキュリティスキャナーは信頼に足るものなのか?

 AIの普及によって膨大な数の脆弱性が発見されるようになり、脆弱性管理が困難を極める状況に陥っている中、今年8月、セキュリティ企業のContrast Securityはアプリケーションセキュリティ(以降、AppSec)に関する厳しい現状をまとめた調査報告書「AppSec Overflow 2026」を公開しました。

 この報告書が基づいているデータは、Contrast Securityによる「runtime application security platform」から得られたもので、アプリケーションやAPIに組み込んだ軽量なセンサーによって、本番環境におけるソフトウェアの実際の挙動を観測した、すなわちアプリケーションやAPIの内部から直接収集されたデータになります。Contrast Securityは、この「内部からの視点」によって以下のような疑問に答えてくれるとしています。

  • そのアプリケーションの脆弱性はユーザー入力で到達可能か?
  • 実際の実行パス上でその脆弱性をトリガー可能か?
  • 実行時に実際に読み込まれ、外部にさらされているライブラリのバージョンはどれか?

 なお、今回の報告書は、数千ものアプリケーションと、1日あたり数兆件に上るセキュリティ上重要な観測データから得られた匿名化されたテレメトリー(遠隔測定データ)に基づいています。

 報告書の重要な点として「Executive summary」に挙げられているのは、以下の4点です。

1. 攻撃者は日々、実際のアプリケーションの脆弱性に到達している。
平均的なアプリケーションは、毎月42件もの「実際に悪用可能」と確認された攻撃の試みに直面しており、攻撃者は平均して4分に1回、稼働中のアプリケーションやAPIに接触している。外部の調査データによると、こうした攻撃の実行までのスピードも加速しており、脆弱性が公表されてから実際に悪用されるまでの時間は、2018年には数年単位だったものが、2026年にはわずか数時間単位へと短縮されている。

2. 攻撃対象領域(アタックサーフェス)の拡大スピードに、防御側の対応が追いついていない。
平均的なアプリケーションには22件の深刻な脆弱性が存在するが、チームが修正できるのは1アプリケーションあたり月平均3.4件にとどまっている。脆弱性へのパッチ適用には数カ月を要し、カスタムコード内の重大な脆弱性の修正には平均92日かかっている。また、観測されたサードパーティ製コンポーネントの脆弱性の54%は1年以上経過している。このように既に処理能力の限界に達しているチームは、AIによる脆弱性発見の波に飲み込まれそうになっている。

3. AIは状況を改善する一方で、悪化させる要因にもなっている。
セキュリティチームにとって、この問題にAIを導入しても、しばしば謳われるような「銀の弾(特効薬)」にはならない。Contrastの調査によると、AIスキャナーによって検出結果が一致しないケースが見られている。同一のコードベースを分析した3つのスキャナー間で、検出結果の一致率はわずか5%にとどまった。また、あるAIスキャナーでは、繰り返し実行しても、自ら検出した結果の17%しか再現されなかった。AIスキャナーによる新たな検出結果が次々と追加される現状を考えると、AIがこの困難な状況から私たちをすぐに救い出してくれるわけではないことは明らかである。むしろ現時点では、AIは問題をさらに深刻化させている。

4. 防御側は優先順位付けに関する危機に直面している。
AppSecチームが脆弱性修正の優先順位を決定する際に使用する指標は、リスクの全体像を不完全に、あるいは時に誤解を招くかたちで示している。CVSS、EPSS、KEVは有用だが、互いに矛盾する結果を示すこともあり、AI時代に防御側が必要とする「的を絞った精密な対応」を可能にするものではない。

 この結果を踏まえてContrast Securityは、「進むべき道は、不完全な予測指標に基づいて盲目的にパッチや制御策を適用することではなく、客観的なランタイム(実行時)の観測結果に基づいて確信を持って行動することである」とまとめることで、自社サービスに誘導しています。

 今回の報告書の目的の1つは明らかに自社サービスの宣伝であり、その点を意識した上で読むべきものではあります。また、実際に脆弱性管理に携わっている方々にとっては当たり前のことを確認しただけの内容かもしれません。それでも、実態を調査分析した上で具体的な数字で説明しているだけでも十分に価値があると言えますし、中でも、上記4点のうちの3点目はAIスキャナーの結果を鵜呑みにすることの危険性を具体的に示しており、注目に値します。

 そこで、ここからはこの3点目をもう少し深掘りして紹介します。

 実はこの3点目は、今回の報告書が初出ではなく、Contrast Securityが今年5月に公開したブログ記事「The Hidden Cost of AI Security Scanners(AIセキュリティスキャナーの隠れたコスト)」の内容を要約して掲載したものです。このブログ記事では、さまざまな実験結果が掲載されていますが、ここでは報告書「AppSec Overflow 2026」の「Executive summary」に掲載された内容に相当する部分のみを簡単に紹介します。

 まず、報告書に掲載された比較実験で使用された「3つのスキャナー」は以下です。

  1. シンプルモード
    標準のClaude Sonnet 4.6を使用して基本的なアプリケーションセキュリティチェックを実行し、モデルがコードを解析して結果を返すようにした。これは、善意のAppSecアナリストがサイドプロジェクトとして独自にまとめ上げる作業を模倣するように設計されている。
  2. マルチエージェントモード
    それぞれ特定の脆弱性クラスに特化した専用エージェントを基盤として構築された。これは、知識豊富なセキュリティチームの支援を受けた思慮深い実務家が、実際にAIを活用したレビューを構成する方法に近いものである。このアプローチでも、Claude Sonnet 4.6が利用されている。
  3. Claude Security
    Claude Opus 4.7をベースとしてAnthropicが開発した専用のアプリケーションセキュリティスキャナー「Claude Security」のベータ版を採用した。

 これらの3つのスキャナーを50,000行のJavaアプリケーションに対して同時に使用した実験の結果によると、この3つのスキャナーで検出されたのは合計59件でしたが、そのうち42件は1つのスキャナーでのみ検出され、他のスキャナーでは検出されませんでした。3つのスキャナー全てで検出されたのはわずか3件(5%)でした。内訳を示したのが以下の図です。

Simple scan = シンプルモード
Specialized agents = マルチエージェントモード
(Contrast Securityの2026年5月20日付ブログ「The Hidden Cost of AI Security Scanners」より)

 さらに同じ50,000行のJavaアプリケーションに対して同じスキャナーを3回実行した結果は以下のようになっています。

  • シンプルモード(Claude Sonnet 4.6ベース)
    - 3回の実行でそれぞれ45件、47件、47件が検出され、ばらつきは4.4%に
    - 約35件の検出結果のうち、3回の実行全てで確認されたのはわずか6件(再現率は17%)
    - 全検出結果のほぼ半数(49%)は、1回の実行でのみ検出され、再検出されず
    - あるスキャンで「重大(Critical)」と判定された2件の問題が、別のスキャンでは「高(High)」の深刻度に引き下げられた
  • Claude SonnetをClaude Opusにアップグレード
    - 3回の実行でそれぞれ32件、36件、28件が検出され、ばらつきは28.6%に
    - 約28件の検出結果のうち、3回の実行全てで検出されたのはわずか7件(再現率25%)
    - 検出件数の安定性は低く、検出結果の一貫性もシンプルモードよりわずかに向上したのみ
    - 完全に同じコードに対して、あるスキャンでは「重大」と判定された項目が3件だったのが、別のスキャンでは2件に

 この結果を見ると、「AIスキャナーは信用できない、使っても意味がない」と考える方もいるかと思うのですが、Contrast Securityは、AIスキャナーには精度や一貫性の面で問題があるとしつつも、開発サイクルの適切な場所に、ツールの1つとして組み込むべきだとしています。要は「使いよう」であり、危険なものは何でも検出できるなどと過信してはいけないということです。その上で、AppSecで本当に重要なのは実行時の可視性であると結論づけることで自社サービスに誘導しています。

 AIは日進月歩で進化しているため、今回のContrast Securityの報告書の内容が陳腐化するのは時間の問題かもしれません。また、そもそもAIに対する指示については概要が紹介されているのみで、具体的な指示内容が示されていないため、本当にAIに適切な指示を与えていたのかも分かりません。

 それでも、「あるセキュリティ企業が2026年の時点で実験した結果」としては意味のあるものですし、「AIを過信してはいけない」との注意喚起としては十分なものと言えるでしょう。

山賀 正人

CSIRT研究家、フリーライター、翻訳家、コンサルタント。最近は主に組織内CSIRTの構築・運用に関する調査研究や文書の執筆、講演などを行なっている。JPCERT/CC専門委員。日本シーサート協議会専門委員。