AppSecの新時代：AI生成コードに動的な攻撃テストが必要な理由

同僚のManoj Nairは最近、AIが構築するものと、セキュリティチームが実際にテストするものとのギャップが拡大していることについて記事を書きました。AIによる開発のスピードが検証を根本的に上回っており、その解決策は開発を遅らせることではなく、テストのあり方を変えることだと論じています。まったく同感です。

ここでは、さらに一歩踏み込んで考えてみたいと思います。私はこの10年近く、動的セキュリティテストエンジンの開発に携わってきました。共同創業したProbelyでの経験を経て、現在はSnykで、私たちのテクノロジーがSnyk API & Webを支えています。ですから、動的セキュリティテストに対する業界の考え方がまもなく一変すると言うのは、市場の予測をしているのではありません。私たちが日々テストするアーキテクチャで起きていることをお伝えしているのです。

コード解析は飛躍的に進化しました。それでもまだ十分ではありません。

まずは、正当に評価すべき点から始めましょう。静的解析は大きく進歩しました。

長年、この分野は硬直的で誤検知の多いパターンマッチングの時代にとどまり、ルールベースのエンジンが大量の検出結果を生み出す一方で、有用な情報はほとんど得られませんでした。

その後、機械学習とシンボリックAIの第一波が登場し、コードベース全体にわたるより深いデータフローを追跡できるようになりました。DeepCode AIを搭載したSnyk Codeのようなエンジンは、静的解析に真の意味的理解をもたらしました。

そして今、まったく新しい能力が生まれつつあります。エージェント型ツールは意味的推論を使い、構文だけでなくコードの実際の意図を理解します。こうしたモデルは、5年前には考えられなかった方法で、複雑なビジネスロジックの欠陥や認可の問題をソースコードから直接検出できます。

これは確かな、意義ある進歩です。実際、あまりに大きく進化したため、業界が今後もこれを「SAST」と呼び続けるのか、それともまったく新しい用語を生み出すのかは、まだ分かりません。

しかし、ここが重要です。どれほど高度なコード解析エンジンでも限界があります。実行できないものはテストできません。

現代のアプリケーションはモノリシックではありません。高度に分散され、組み合わさった多層環境で構成されています。たとえば、数十のバックエンドマイクロサービスと通信するシングルページアプリケーションがあり、それぞれに独自の認証コンテキスト、データアクセスパターン、デプロイライフサイクルがあります。高度なコードスキャナーなら、あるマイクロサービスのコードベースにある認可の欠陥を検出できるかもしれません。しかし、複数のコンポーネントが連携したときにだけ脆弱性が現れるとしたらどうでしょうか。

実際に起こり得るシナリオを考えてみましょう。フロントエンドアプリケーションがトークンを処理する方法、APIゲートウェイがリクエストをルーティングする方法、そして別のバックエンドサービスがユーザーのロールを解釈する方法が重なった結果、認可の問題が表面化するケースです。脆弱性は、どのコードベースにも単独では存在しません。コンポーネント間の連携から生じるのです。どれほど知能的な静的解析でも、コードベースをまたぐコンポーネント間の状態を把握するのは困難です。システム全体を観察することが根本的にできないからです。

まさにそれを実現できるのが動的セキュリティテストです。実環境で異なるコンポーネントがすべて連携している状態で、攻撃者がシステムを実際に悪用できるかどうかを検証できます。

この実行時の死角は、Manojが指摘した最前線の課題にもそのまま当てはまります。AIエージェントが、開発者の想定を超える方法で、大規模に自律してAPIを呼び出すのです。プロンプトインジェクション、目標の乗っ取り、コンテキストポイズニングといったリスクは、ソースコードには存在しません。実行時にのみ発生する、創発的な振る舞いです。複雑なマイクロサービス間の連携と同様、こうした脅威を検証するには、稼働中のシステムと動的にやり取りするしかありません。

誰も名付けていない融合

市場ではもう一つ、もっと正面から注目すべき動きが起きていると思います。

この1年で、「AIペンテスター」という新しい呼び名が登場しました。この呼び名は、実態を捉えています。これらのツールは、アプローチにおける真の変化を示しているからです。見つかったすべての入力に静的なペイロードを送りつける硬直的なスキャナーとは異なり、新しいタイプのツールはアプリケーションの状態を推論し、コンテキストに基づいて次の手順を決めます。まるで人間のセキュリティ研究者のように動作するのです。

しかし、私が見てきたこと、そして市場が誤解していると思うことがあります。これらのアプローチは競合するのではなく、根本的に補完し合うものです。

最近、意図的に脆弱性を仕込んだアプリケーションを、従来型の動的セキュリティテストエンジンと、単体のAI主導型ペネトレーションテストの両方でテストしました。その結果は実に示唆に富むものでした。

動的セキュリティテストエンジンは、AI主導型のアプローチが見逃した脆弱性を検出しました。従来型のエンジンは、徹底的かつ機械的に網羅するよう設計されており、あらゆるパラメーター、エンドポイント、エッジケースを漏れなくテストするからです。

一方、AI主導型のアプローチは、従来型のエンジンが理解できなかった複雑なロジックの欠陥を検出しました。決定論的なスキャナーにはできない方法で、認可の連鎖やビジネスロジックを推論できたからです。

どちらか一方だけでは不十分でした。両方を組み合わせることで、はるかに全体像に近いものが見えてきました。

この結果から、業界が明らかに融合へ向かっていることが分かります。この分野の将来の製品は、両方の能力を組み合わせることになるでしょう。継続的な保証に必要な、パイプラインを包括的にカバーする網羅モードと、AI生成コードが大規模に生み出す認可の欠陥や連鎖的な脆弱性を見つけるための、深くロジックに踏み込むターゲット型のコンテキスト駆動モードです。

市場が「DAST」という呼び名を使い続けるのか、「AIペネトレーションテスト」に移行するのか、それともまったく新しい用語を生み出すのか、正確な呼び名はまだ分かりません。しかし、この融合そのものは避けられないように感じます。

これから向かう先

今後の最も重要なアーキテクチャの変化を一つ挙げるとすれば、コードレベルのインテリジェンスと動的セキュリティテストが、深く結びつきつつあることです。

動的セキュリティテストは、その歴史の大半においてブラックボックスとして動作してきました。ソースコードについての知識も、アプリケーションの内部ロジックへの理解もありません。外部から検査し、見つけたものを報告する仕組みです。それは、理論ではなく現実をテストできるという強みであると同時に、効果を大きく高め得るコンテキストを把握できないという限界でもありました。

それが変わりつつあります。プラットフォームの成熟に伴い、セキュリティ研究者が以前から「グレーボックス」テストと呼んできたアプローチへと自然に向かっています。これは、稼働中のアプリケーションとやり取りしながら、同時に基盤となるソースコードも理解する方法です。一方では、コードレベルの解析によって隠れたエンドポイントやロジックの欠陥を推測し、動的セキュリティテストで実環境におけるその存在を証明（または反証）できます。もう一方では、実際に熟練した人間のハッカーが行う方法に近いのですが、アプリケーションやAPIの稼働中に動的セキュリティテストで不審な振る舞いを検知し、コードレベルのコンテキストを使って保護がどのように実装されているかを正確に把握できます。総当たりではなく、必要なペイロードを的確に組み立てられるのです。

これにより、動的セキュリティテストで歴史的に最大の課題の一つだった修正対応にも着手できます。動的ツールは、悪意のあるHTTPリクエストとレスポンス、そして悪用の証拠を示すことで、エクスプロイトの存在を証明できました。しかし、欠陥がコードベースのどこにあるのかは開発者自身が推測するしかありませんでした。動的な検証結果とコードレベルのコンテキストを相関させれば、はるかに強力な検出結果が得られます。実行時に悪用可能であることを証明すると同時に、修正が必要なコードを直接示せるのです。

注目すべきは、まさにこの方向性です。単一のベンダーがすでに完全に実現しているからではなく（私たちは実現していますが）、アーキテクチャ上の前提条件が整いつつあり、この融合にいち早く気づいたチームが、最も堅牢なセキュリティプログラムを構築できるからです。

構築者としての確信

最後に、テストするアーキテクチャが増えるたびに、確信が深まってきたことをお伝えします。

動的セキュリティテストを、四半期ごとに実行して結果を保管するだけの、遅くてノイズの多いスキャナーによるコンプライアンスチェックとして扱う時代は終わりつつあります。考え方が間違っていたからではなく、その周囲の世界が変わったからです。

AI生成コードは、人間によるレビュープロセスが想定するよりも速くリリースされます。AIエージェントは、どんなインベントリでも追跡できるよう設計されていた速度を上回る速さでAPIを呼び出します。そして、こうした力がもたらす脆弱性、たとえば認可の不備、ビジネスロジックの欠陥、コンポーネント間の状態不整合は、まさに動的セキュリティテストでしか確実に証明できない種類の脆弱性です。

生まれつつあるのは、コード解析に取って代わるものではなく、方程式のもう半分です。コード解析で分かるのは脆弱性の可能性ですが、動的セキュリティテストでは実際に悪用できるかを検証できます。この2つのシグナルが結びつけば、ノイズが減り、重要な情報が明確になります。開発者は不安ではなく、自信を持ってリリースできるようになります。

AI時代に向けてセキュリティプログラムを構築するなら、その自信こそ投資すべき資産です。