継続的な攻撃的セキュリティ：私たちが歩んできた道

AIペネトレーションテストが注目を集めています。

いや、実際には何度も注目を集めています。隔週のように、あるベンダーが何かを発表し、別のLLM駆動型ペネトレーションテストツールが、誰も聞いたことのない標的でベンチマークのトップに立つ。また別のプレゼン資料が、ついに新たな「ゴールドスタンダード」が覆されると主張する……。慌ただしい状況です。

しかし、騒がしさの裏には、これが一斉にあらゆる場所で起きている本当の理由があります。AIペネトレーションテストを商用化できるようにしたのと同じ推論能力を、今や攻撃者も手にしているのです。自律型の攻撃者はすでに、アプリケーションの攻撃対象領域をマシンスピードで継続的に調査しています。防御側が追いつけないペースです。

今の競争は、攻撃者の攻撃AIより先に、自社の攻撃的セキュリティテストが脆弱性を見つけられるかどうかです。ベンダーの発表が本当のニュースなのではありません。すでに起きている問題に、市場が追いつこうとしているにすぎないのです。

当社の動的セキュリティテスト製品であるSnyk API & Webに数年間携わってきた私は、SnykがContinuous Offensive Securityを発表したことを、感慨深く感じています。この投稿では、発表だけで終わらせず、動的セキュリティテストからAIペネトレーションテストへと続く道を、私たちが何年も歩んできた理由、そして前者の基盤なしに後者を構築しようとする人たちは、私の率直な意見では、すぐに限界に突き当たる理由を説明したいと思います。

ヒューリスティックで検出可能な脆弱性と、コンテキスト依存の脆弱性

ここでの主張全体を理解するうえで重要な、基本的な違いから説明しましょう。

ヒューリスティックで検出可能な脆弱性は、決定論的なツールで検出できるものです。SASTはソースコード自体のパターンを照合します。一方、DASTは異なるアプローチを取り、稼働中のアプリケーションやAPIにペイロードを送信して、エラーメッセージ、応答時間の変化、挙動の違いなどを観察します。試し、観察し、推測するのです。SQLインジェクション、クロスサイトスクリプティング、APIの誤用、典型的なインジェクションパターンは、いずれもヒューリスティックで認識可能な挙動として確実に表面化します。スキャナーやDASTツールは、長年にわたってこの検出能力を大きく高めてきました。このカテゴリには何百もの脆弱性クラスがあり、今ではSDLC全体で確実に検出されています。これは大きな成果です。

コンテキスト依存の脆弱性は、まったく別のものです。BOLAやIDOR、テナント間のデータ漏えい、認証の回避、そして特に、複数の中程度・高程度の脆弱性が組み合わさって重大な攻撃経路になる脆弱性チェーンが該当します。こうした脆弱性には、調査で検出できるヒューリスティックな特徴がありません。「ユーザーAがユーザーBの請求書を読めてはならない」というルールを、SASTにもDASTにも書くことはできません。そのルールは、アプリケーションが本来どのように動作すべきかに依存するからです。脆弱性は、意図された挙動と実際の挙動との間に潜んでいます。外部から調査しても、意図を推測できるプローブも、ペイロードも、シグネチャもありません。

だからこそ、ペネトレーションテストは常に人間主導で行われてきました。最近まで、この2つ目の脆弱性クラスを見つけるために必要なコンテキストの理解を得られるのは、人間だけでした。ヒューリスティックはシグネチャや挙動を見つけ、ペネトレーションテスターはコンテキストを通じて初めて明らかになるものを見つけます。格好いい標語に聞こえるかもしれませんが、これは単なる宣伝文句ではありません。この分野が成立して以来、実際に続けられてきたやり方です。

そして今、AIがその一線を越えました。

本当に重要な系譜

実はそれほど秘密でもない、業界の裏話があります。この10年間に開発された信頼できるDASTエンジンは、いずれもペネトレーションテストの経験者によって作られています。Snyk API & Webのエンジンも例外ではありません。開発チームは長年、手作業で脆弱性を見つけてきた経験を持ち、ペネトレーションテスターが実際に行うこと、つまり情報収集、調査、観察、推論、攻撃の拡大、検証という一連の流れを中心に設計しました。ただ当時は、ペネトレーションテスターの仕事をすべて再現することはできませんでした。欠けていたのは推論能力です。LLMがコンテキストを理解し、推論できるようになった今、私たちはそれを実現できます。

この実績があるからこそ、昨年リリースしたBOLA検出は今のように機能します。BOLAにはシグネチャが存在しないため、シグネチャのリストとパターンを照合するものではありません。APIオブジェクトとアイデンティティの関係について構造的に推論しながら、認可を検証するプローブを連続して実行します。これは、「コードは何をするのか？」から「本来何をするはずなのか、そしてその意図を覆せるか？」へと踏み込む、自動化された脆弱性探索です。

すでに数か月にわたり、お客様の本番環境で稼働しています。DASTから推論ベースのテストへと続く道が実現可能であることを示す証拠です。また、「AIペネトレーションテスト」が資金調達の対象となるカテゴリになるずっと前から、私たちがそのAI版の構築を考えていたのも、偶然ではありません。

何が変わり、なぜ今なのか

変わったのは目標ではなく、コストです。

大規模な推論には、かつて人間のペネトレーションテスターが必要でした。1回の契約で2万～5万ドル。平均で2週間の期間がかかります。レポートを納品した瞬間に終わる検査対象期間。その頃にはアプリケーションはすでに、さらに3回リリースされています。

これが手動ペネトレーションテストの現実でした。かけがえのないものですが、職人仕事と同じ制約、つまり人間の時間に縛られます。年に15日間のペネトレーションテストで、残りの350日間に何が起きているのでしょうか？

AIは計算を変えますが、テストの手法は変えません。ペネトレーションテスターにしかできなかった推論を、十分な能力を持つモデルも実行できるようになりました。繰り返し実行でき、コストも大幅に抑えられます。

さらに、AI自体が生み出した3つ目の攻撃対象領域があります

ここまで述べてきたのは、Webアプリケーションとともに存在してきた攻撃対象領域の話です。従来のコード、従来のAPI、従来のアーキテクチャにおける、ヒューリスティックで検出可能な脆弱性とコンテキスト依存の脆弱性です。AIはテストモデルを変えますが、標的は変えません。こうした脆弱性は、20年前からペネトレーションテストの対象でした。

AI自体が生み出した、まったく新しい攻撃対象領域もあります。わずか5年前には存在していなかったものです。

LLMを組み込んだアプリケーション、ツールを呼び出すAIエージェント、顧客データと連携するチャットボット。攻撃者が汚染したり、プロンプトインジェクションや不正利用を仕掛けたりできる情報源からデータを取得するRAGパイプライン。モデルの出力を通じたデータの窃取や、カスタマーサービスのエージェントを、本来持つはずのないアクセス権を持った特権的な存在に変えてしまうジェイルブレイク。Manojの記事では、メールアドレスというごくありふれた情報をきっかけに、十分な負荷テストを受けていないAPIをAIエージェントが呼び出す事例を紹介しています。

こうした攻撃はスキャンで検出できるものではなく、従来のアーキテクチャにおける意味での脆弱性でもありません。LLMが指示されたことと、攻撃者がLLMに信じ込ませて実行させられることとの間に潜んでいます。見つける唯一の方法は、攻撃者と同じように、LLM統合レイヤーを調査し、攻撃を拡大し、データを窃取し、不正利用することです。

これがContinuous Offensive Securityの3つ目の機能、エージェントのレッドチーム演習です。LLM、AIエージェント、そしてそれらが呼び出すツールに対する、多段階の敵対的シミュレーションです。AI自体が生み出した攻撃対象領域に特化して構築されたツールです。

その仕組みで特に気に入っている点が1つあります。別途スケジュールを組んで実行するスキャンでも、別途購入する製品でもありません。評価中に情報収集エージェントが、標的にLLM統合コンポーネントが含まれているかを検出し、含まれていればレッドチーム演習モジュールが自動的に起動します。アプリケーションがどのような攻撃対象領域を持つか、事前に把握しておく必要はありません。システムがそれを判断し、適切なレイヤーに適切なテストを実行します。

一見した以上に、これは重要なことです。今では多くの組織がアプリケーション群のどこかでAIを利用していますが、セキュリティチームはその場所を明確に把握できていません。まず情報を収集し、見つかったものをテストする。これは「本番環境のどこでAIが稼働しているのか？」という問いへの答えが絶えず変化する状況で、唯一スケールできるモデルです。

これが攻撃対象領域の全体像です。従来のアーキテクチャに存在する脆弱性と、その上にAIが新たに生み出した領域。より難しいのは、企業規模で、この両方を継続的に効果的にテストするには何が必要かという問いです。LLMに標的のURLを渡し、何も知らない状態から自由に調べさせるのは答えではありません。行き当たりばったりのテストと一線を画す要素は4つあります。

プラットフォームのコンテキスト

AIペネトレーションテストの素朴なアプローチは、ゼロから始めることです。LLMにURLを渡し、クロールさせ、推測させ、重要でない列挙に計算リソースを浪費させ、いつか何かを見つけることを期待します。さらに悪いことに、自社のコード、依存関係、過去のスキャン結果、デプロイ環境、信頼境界が見えないため、理論上の検出結果と、実際に自社のスタックで悪用可能なものを区別できません。それがデモの繰り返しなら通用しますが、本番環境レベルのセキュリティテストのあり方ではありません。

しかし、Snykのアプローチは異なります。Continuous Offensive Securityは、SASTの検出結果、SCAの依存関係、アセットのインベントリ、過去のDASTスキャン、プラットフォーム全体のリスクシグナルなど、プラットフォームがすでに把握しているアプリケーションの情報をすべて活用します。AIペネトレーションテスターは、最初のリクエストを送る前に、そのすべてを受け取ります。

これにより、初日からAIの動きが変わります。「このアプリケーションがどんなものか把握して、脆弱性を見つける」という指示ではなく、「このアプリケーションには、これらのコンポーネント、依存関係、過去の検出結果、到達可能なエンドポイント、リスクプロファイルがある。では、まだカバーされていない箇所を調べる」という指示になります。LLMは推測をやめ、実際の作業を始めます。

今週の発表から、そのまま引用します。「Snykが他と異なるのは、お客様のコードをすでに把握しているからです」。これが、わずか7語で表したプラットフォームの強みです。他のAIペネトレーションテストツールはすべてゼロから始めます。私たちは、お客様が既存のツールで到達した地点から始めます。

だからこそ、このカテゴリの単機能型ソリューションには長い成長余地がないと私は考えています。このレイヤーは、新しい製品に後付けできないからです。実際のお客様の環境で実際の脆弱性を発見してきたエンジンから、10年かけて蓄積されたコンテキストが流れ込む必要があります。

ハイブリッド動的テストとLLMによる検出

これは、新規参入企業の多くが見過ごしているエンジニアリング上の重要点です。資金が尽きるまでの期間とトークンの請求額が同時にのしかかるとき、多くの企業が苦戦すると私は思います。

AIペネトレーションテストを構築する際の、もうひとつの素朴な方法は、純粋なLLMを標的に向け、すべてを自力で解決させることです。デモでは機能しますが、持続可能なコスト構造にはなりません。

LLMがXSSのエンドポイントに試すペイロードは、1つごとにトークンを消費します。総当たりで試すパラメーターも、バリエーションも、再試行も、すべてトークンを消費します。動的テストなら、こうした処理を網羅的かつ決定論的に、わずかなコストで実行できます。バグのカタログを調べるために最先端モデルのトークンを浪費するのが、「赤字覚悟の補助金付き」モデルの実態です。今、その戦略を取っているベンダーも、利益を出さなければならない日が来れば、ユニットエコノミクスの意味を思い知るでしょう。

アーキテクチャとして正しいのは、2つのレイヤーを並行して動かすのではなく、LLMが評価の頭脳として動き、動的テストを利用可能なツールの1つとして使うモデルです。XSS、SQLインジェクション、設定ミスを調べる必要があれば、LLMが自分でペイロードを列挙するのではありません。長年にわたって網羅的かつ決定論的に、わずかなコストでそれを実行してきた動的テストを呼び出します。

これによりLLMは、LLMにしかできないこと、つまりビジネスロジックの推論、認可の不備の発見、個々の検出結果をつなぎ合わせて実際の攻撃経路を見つけることにトークンを使えます。計算リソースの大半はここに使われます。すでに十分に調査された領域は決定論的に処理し、推論が必要な領域には、それに見合う計算リソースをすべて投入します。

これは初日から備わっているアーキテクチャであり、現在開発中のロードマップではありません。だからこそ、基盤となるDynamic Security Testingエンジンなしでこれを構築するのは、外から見える以上にはるかに難しいと私は考えています。

アラート一覧ではなく、攻撃シナリオを

従来のスキャナーが出力するのは、脆弱性を深刻度スコア順に並べ、スタックトレースやHTTPリクエストを添えた一覧です。セキュリティチームは何年もこうした一覧に追われてきました。CVSS 9.8、次にCVSS 9.6、さらにCVSS 9.4……その中のどこかに、2つの脆弱性と、チームが数カ月前にトリアージで除外した低深刻度の検出結果を組み合わせた、実際に悪用可能な経路が隠れています。

先ほど説明した、コンテキストに依存する種類の脆弱性は、単独の検出結果として現れることはほとんどありません。現れるのは組み合わせです。あるエンドポイントの認可の不備、APIが識別子を発行する際のロジックの欠陥、そしてクリーンアップジョブが見落とした古いセッション。個別に見ればありふれた3つの検出結果でも、組み合わさるとデータ侵害につながります。

Continuous Offensive Securityは、検出結果を一覧として提示するのではなく、攻撃チェーンとして提示します。初期アクセスから影響に至る実際の経路を、証拠となるリクエスト／レスポンスの記録とともに示します。すべて再現可能で、監査にも対応。金曜の午後に誰かがトリアージしなければならない400行のスプレッドシートではなく、攻撃者が実際にこのアプリケーションに対して何を行えるかを物語として示します。

Emburseのシニアディレクター兼情報セキュリティ責任者であるColleen Carroll氏は、発表に際して、需要側の視点からこの点を次のように述べています。

「セキュリティチームが求めているのは、アラートをさらに管理することではなく、実際のリスクの優先順位付けを支援するソリューションです。SnykのContinuous Offensive Securityは、悪用可能な脆弱性と、それらがどのようにつながるかをより明確に可視化します。これにより、チームは迅速に対応し、リスクへの露出を減らし、自信を持ってイノベーションを推進できます。」

それが、「検出した内容はこちらです」と「これが攻撃に利用される方法です」の違いです。

エンタープライズ向けAIハーネス

高度なエンジニアリングが必要でありながら、ほとんど話題にならないのが、本番環境までネットワークホップが1つしかないシステムに対して、AIエージェントを責任を持って実行することです。

ガバナンス、スコープの適用、長時間にわたる操作でのコンテキスト維持、そして検出結果を検証・再検証できる再現性。結論に至った過程をセキュリティチームが監査できるようにする推論トレース。こうしたすべてのレイヤーが、「LLMが試行錯誤している状態」を、企業のセキュリティ組織が実際にアプリケーションに対して実行できるものへと変えます。

私たちはこれをAI Security Harnessと呼んでいます。Continuous Offensive Securityの中核を支えるレイヤーであり、実際の難しさの大部分がここにあります。そして、ここでも経験の蓄積が重要です。このレイヤーの構築は、その上で動くAIを作るよりも困難です。ペンテストやDynamic Security Testingをエンタープライズ規模で何年も運用してきた組織は、今参入したばかりの組織に対して、大きな先行優位を持っています。

また、ソリューションが簡単には再現できない、意図的なアーキテクチャ上の選択も行いました。Continuous Offensive Securityは、単一のフロンティアモデルでは動作しません。AI Security Harnessは、最先端モデル、防御側のモデル、その他のオープンモデルや独自モデルを、時間をかけて調整しながらオーケストレーションします。私たちにとってこれは、エンタープライズグレードのAIシステムをどのように構築すべきかを定めるアーキテクチャ上の決断です。

Continuous Offensive Securityは、エンタープライズのペンテスト専用に構築された、複数モデルによるオフェンシブセキュリティシステムを実行します。フロンティアモデルがSnykのオフェンシブハーネスのもとで評価を実施し、専用の検証モデルが独立した判定役となって、検出結果を提示する前に悪用可能性を確認します。さらに、Snykのプラットフォームインテリジェンスが、各攻撃を実際のアプリケーションコンテキストに根付かせます。その結果、ノイズを抑え、精度を重視するシステムが実現します。

この先にあるもの

YaloのスタッフセキュリティエンジニアであるGabriel Brolo氏は、最近、私が伝えたいことを明快に語ってくれました。

「AIが生成するコードの量とペースは、私たちの多くが何年も続けてきたペンテストのモデルを根本から上回っています。リスクが絶えず変化する状況を、スケジュール調整で解決することはできません。今のソフトウェア開発の実態に追いつくオフェンシブテストが必要です。本当に悪用可能なものに焦点を当て、理論上の可能性にとどまらないだけのコンテキストも備えたテストです。こうした機能によって、チームは脅威の全体像と実際のリスクをより深く理解し、より適切な緩和策を講じられるようになります。」

Snyk API & Webをご利用のお客様にとって、Continuous Offensive Securityは別途購入する製品ではありません。Dynamic Security Testingですでに実施している外部視点のテストを、次のレイヤーへと拡張するものです。スキャナーがヒューリスティックに検出できる問題、AIが検出するコンテキスト依存の問題、そして偵察によってスタック内のLLMが見つかった時点でレッドチーミングが検出するAI固有の攻撃対象領域をカバーします。現在のアプリケーションを構成する要素全体にわたり、同じセキュリティ態勢を拡張します。

市場における問いは、「AIペンテストは必要ですか？」（もちろん、必要だと私たちは考えています）から、「どのAIペンテストを選ぶべきか？」へと変わります。

今週、Continuous Offensive Securityを発表するにあたり、私たちが目指しているのは、選択肢を比較し、デモに参加し、誰を信頼すべきかを見極めようとしているAIペンテストソリューションの評価中のお客様に、その答えの一つが、まだ部屋と呼べる場所さえなかった頃からこの領域に携わってきた人々から生まれたものだと知っていただくことです。

AIが生み出す攻撃対象領域についてのManojの投稿と、それに対応するためにダイナミックテストがどう進化すべきかについての私の前回の記事を読んでくださった方には、今回が3つ目の節目となります。つながりは明らかでしょう。もともと一貫した流れがあり、私たちはこれまでずっと、その兆しを示してきました。

Black Hatでさらにお話しします。会場でお会いしましょう！