魔法の箱は存在しない：AI時代のAppSecにスタックが必要な理由

今日、大規模なサイバーセキュリティカンファレンスの会場を歩けば、同じ売り文句を何度も繰り返し耳にします。AIを活用した一つのプラットフォーム。一つのダッシュボード。一つの自律型セキュリティ頭脳。あらゆる脆弱性を見つけ、あらゆる問題を修正し、アラート疲れをなくし、開発者を満足させ、ついでに観葉植物に水までやってくれる、一つの魔法の箱。

美しい物語です。しかし、アプリケーションセキュリティの実際の仕組みはそうではありません。

問題は、完璧な自律型AppSecプラットフォームがまだ存在しないことだけではありません。より大きな問題は、AIだけに頼るセキュリティテストはスケールしないということです。

現代のエンジニアリングチームは、かつてないほど多くのコードを出荷しています。AI支援型の開発によってソフトウェア作成のスピードは上がりましたが、セキュリティチームは依然として、誰の作業も遅らせることなく、すべてのコミット、依存関係の更新、APIルート、クラウド設定、生成されたコードの変更をレビューすることを求められています。

そこで当然生まれる誘惑が、「すべてをAIにテストさせればいい」というものです。

残念ながら、そうしてクラウドの請求書がインシデントと化すのです。すべての変更に対して高価なAIモデルを実行するのは戦略ではありません。非常に洗練された予算の燃やし方にすぎません。仮にコストが問題にならなかったとしても、AIだけでは完全なカバレッジは得られません。既知の脆弱性には脆弱性データベースが必要です。依存関係のリスクにはパッケージインテリジェンスが必要です。シークレットには決定論的な検出が必要です。設定ミスにはポリシーチェックが必要です。ビジネスロジックの欠陥にはセマンティックな理解が必要です。深いエクスプロイトチェーンには攻撃者視点の推論が必要です。

これらすべてをうまくこなせる単一の手法はありません。だからこそ、現代のAppSecは一つの魔法の箱に向かっているのではありません。階層型のモデルへと向かっているのです。

かつての世界はおおよそ次のようなものでした。

スキャナー ──> ペンテスト ──> バグバウンティ

新しい世界は、むしろ次のようなものです。

スキャナー ──> BYOKセマンティックレビュー ──> サイバーモデル

各レイヤーにはそれぞれの役割があります。各レイヤーにはそれぞれのコスト特性があります。各レイヤーは異なる種類の問題を捉えます。目標は、あらゆる場所でAIを使うことではありません。最も安価で信頼できる手法を最初に使い、より多くのコンテキストが必要な場合にのみエスカレーションし、高価なサイバーモデルは本当に深い推論に値する問題のために取っておくことです。

それが、AIコーディング時代にAppSecをスケールさせる方法です。

---

レイヤー1：スキャナーは死んでいない

数か月ごとに、誰かが従来型のスキャナーは死んだと宣言します。SASTは死んだ。DASTは死んだ。正規表現は死んだ。ルールは死んだ。デモの後に都合よく手に入る新しいAIのものを除いて、すべてが死んだというわけです。

これはナンセンスです。

スキャナーが今なお不可欠なのは、高速で安価であり、既知の、繰り返し発生する、構造的な問題を見つけるのが非常に得意だからです。 * ハードコードされたシークレット * 既知の脆弱な依存関係 * セキュリティヘッダーの欠如 * 安全でない関数 * 生のSQL文字列連結 * 露出したデバッグ用エンドポイント * 設定ミス * 既知のCVE * Polyglot XSSのような複雑で構造的なインジェクション攻撃文字列

このレイヤーは、自社のビジネスモデル全体を理解する必要はありません。自社独自のエンタープライズ承認ワークフローについて推論する必要もありません。明白な、パターンマッチで捉えられる問題を、それが全員の問題になる前に捕まえるだけでよいのです。

開発者がAPIキーをコミットした場合、アクセス制御の哲学について思索するフロンティアモデルは必要ありません。必要なのは、「それは出荷しないでください」と言ってくれるスキャナーです。依存関係に既知のクリティカルなCVEがある場合、AIにその脆弱性をゼロから再発見させる必要はありません。必要なのは、脆弱性インテリジェンス、バージョンの照合、そして修復の道筋です。

Polyglot XSSのような複雑なインジェクションパターンが含まれていることが、この点を見事に証明しています。ポリグロットペイロードは、複数の実行コンテキスト（HTML、スクリプトブロック、属性）で同時に悪意のある実行が起きるよう設計された、ひねりの効いたセキュリティエンジニアリングの産物です。複雑に聞こえますが、実行の根本においては完全に構造的な欠陥です。ここで開発者の考え方を分析するために高価なLLMを使う必要はありません。精密で高速なルールベースのスキャナーであれば、コードのコミット段階でこうした構造的な異常を即座に見つけ、処理のオーバーヘッドに大金をかけることなく、エクスプロイトチェーンをその場で食い止めることができます。

レイヤー1は煙探知機です。火事の全容を説明してはくれません。家がポストモーテムの対象になる前に、キッチンが燃えていることを知らせてくれるだけです。鍵となるのはチューニングです。悪いスキャナーはノイズを生みます。良いスキャナーはレバレッジを生みます。

要件	重要である理由
高速	開発者は、コードの記憶が新しいうちにフィードバックを必要としている。
安価	これらのチェックは常時実行されるべきもの。
決定論的	既知の問題は確実に見つけられるべき。
対応可能	検出結果は、何を修正すべきかを説明すべき。
低ノイズ	ダッシュボードの墓場はもう誰も必要としていない。

レイヤー1は、高価な推論を決して必要とすべきでないものを捉えます。

詳細記事はこちら：エンジニアリングチームを誤検知（フォールスポジティブ）で溺れさせることなく、ノイズを排除するために従来型スキャナーを積極的にチューニングする方法を知りたい方は、近日公開予定の技術解説『レイヤー1：ルールの復活、SASTとDASTを味方につける』をお待ちください。

---

レイヤー2：BYOKセマンティックレビュー

明白な問題が取り除かれると、より難しい問いが始まります。 * このユーザーはこの操作を実行することを許可されているか * このOAuthフローはstateを正しく検証しているか * このリダイレクトURIは安全か * 機密データがログに記録されていないか * このプルリクエストは、認可チェックをこっそり回避していないか

これらは必ずしもスキャナーで扱える問題ではありません。コンテキストが必要です。ここでAIが役に立ちますが、非常に重要な注意点が一つあります。自社の独自コードを、公開ツールに安易に貼り付けるべきではないということです。

セキュリティチームにはAIの支援が必要ですが、同時に、プライバシー、コンプライアンス、監査可能性、そしてコードがどのように処理されるかに対する制御も必要です。だからこそ、2番目のレイヤーは単に「AIを使う」ことではありません。BYOK（Bring Your Own Key）アーキテクチャを中心に構築された、プライベートなセマンティックレビューなのです。

BYOKとは、顧客管理の鍵、テナント分離、制限されたログ記録、明確な保持ポリシー、そしてプロンプトと出力の安全な取り扱いを意味します。このレイヤーは、プライベートなAIのピアレビュアーのように機能します。コードをコンテキストの中で調べ、そのロジックがセキュリティの観点から本当に筋が通っているかを問うことができます。

正規表現ベースのスキャナーが見逃してしまうロジックの欠陥を捉えるには、セマンティックなAIのコンテキストがどうしても必要であることを示す実例として、OAuthによるアカウント乗っ取り（「One Scheme to Rule Them All」）の解説をご覧ください。従来型のスキャナーはOAuthの実装を見ても、構文としては完全に正しいと判断します。変数は正しく宣言され、エンドポイントは想定どおりの文字列に一致しているからです。

しかし、安全なBYOK環境で動作する、コンテキストを理解するAIのピアレビュアーは、実際のロジックフローを分析できます。アプリケーションがstateパラメーターを適切に検証していない、あるいはカスタムのリダイレクトURIスキームを安全に扱っていないために、認証フロー全体が傍受やアカウント乗っ取りに対して脆弱になっていることを見抜けます。文字がどう入力されているかだけでなく、アプリケーションが何をしようとしているかを理解しているからこそ、欠陥を捉えられるのです。

それが構文とセマンティクスの違いです。レイヤー2が最も適しているのは次の用途です。 * プルリクエストのレビュー * 認可ロジックと認証フロー * 機密データの移動 * カスタムフレームワークの分析 * 社内のセキュアコーディング標準 * 開発者向けの修復ガイダンス

レイヤー1が問うのは、「この既知の悪いものを以前に見たことがあるか」です。レイヤー2が問うのは、「このコードは、このアプリケーションのセキュリティモデルにおいて筋が通っているか」です。こちらのほうが強力な問いです。同時に、より高価な問いでもあります。だからこそ、すべてに使うべきではありません。

詳細記事はこちら：自社環境にこれを安全にデプロイするために必要な具体的なインフラストラクチャ、オープンウェイトモデルの選定、ネットワークアーキテクチャに興味のある方は、次回の記事『レイヤー2：AIピアレビュー、安全なコード分析のためのオープンウェイトモデルとBYOKの実装』をお待ちください。

---

レイヤー3：深い推論のためのサイバーモデル

セキュリティ上の問題の中には、複数のコンポーネントが相互作用したときにしか現れないものがあります。Webhookがキューに書き込みます。ワーカーがペイロードを処理します。内部サービスがそのワーカーを信頼します。管理用エンドポイントがその結果を利用します。個々の部分は単独では問題なく見えます。脆弱性はチェーンの中に現れます。

これは基本的なスキャナーの問題ではありません。攻撃経路の問題です。

レイヤー3は、Mythosのような最先端の推論システムに代表される、専門特化したサイバーモデルが役立つ領域です。これらのモデルは、深いアーキテクチャレビュー、エクスプロイトチェーンの分析、モバイルプラットフォームの悪用、クラウドの権限経路、高リスクなシステムの監査に有用です。

しかし、素のモデルだけでは十分ではありません。構造を持たないまま巨大なコードベースに強力なモデルを向けるのは、天才インターンにリポジトリ全体を渡し、地図も脅威モデルも与えず、エスプレッソを無制限に飲ませるようなものです。何かは起こるでしょう。それが役に立つかどうかは別の話です。

パズルの決定的なピースは、ハーネス、つまりモデルを取り巻くオーケストレーションレイヤーです。

• 素のLLM（エンジン）：ベースとなる推論エンジンです。巨大なフロンティアモデルは、深い推論や、複雑でマルチホップのエクスプロイトチェーンをつなぎ合わせることに驚くほど優れています。一方、小型のモデルはスピードとスケールをもたらします。しかし、Mythosのような最上位のフロンティアモデルを無邪気にコードベース全体へ向けると、たった1回のスキャンで、何万ドルもの計算コストをいとも簡単に燃やしてしまいかねません。
• ハーネス（オーケストレーター）：汎用的なAIを、武器化されたサイバーツールへと変える本当の秘伝のソースです。ハーネスとは、ワークフローのロジック、エージェントのルーティング、コンテキスト管理といったエンジニアリング上のラッパーです。どの専門エージェントをどのタイミングで動かすかを厳密に決め、必要なコンテキストだけを与え、AIの出力に本来備わる予測不能性（非決定性）を管理し、ノイズを容赦なく重複排除して、検証済みで対応可能な検出結果を提供します。

ハーネスは、高価なモデルが本当の価値を生み出せる場所でのみ使われるようにします。

マルチホップの攻撃経路や、深く埋もれたプラットフォームのライフサイクルを追跡するために、なぜこのようにオーケストレーションされた「重火器」が必要なのかをはっきりと示す例として、Androidのインテントリダイレクション：攻撃と修正の解説をご覧ください。複雑なモバイルアプリケーションでプロセス間通信（IPC）の脆弱性を見つけることは、構文ルールや単一関数のセマンティックチェックでは不可能です。オペレーティングシステムのライフサイクル全体をモデル化し、エクスポートされた個別のコンポーネントがどのように互いにメッセージを渡すかを理解し、一見無害な不正な形式のデータパッケージが境界を越えて、アプリケーションレイヤーの奥深くで特権的な動作を引き起こす様子を追跡できるエンジンが必要です。オーケストレーションされたサイバーモデルはここで真価を発揮し、アプリケーションアーキテクチャ全体にまたがる、プラットフォーム固有の深い攻撃グラフを描き出します。

レイヤー3は、すべてのコミットのためのものではありません。高リスクな局面のためのものです。

ユースケース	重要である理由
メジャーリリース	大きなアーキテクチャ変更は、システムをまたぐリスクを生む。
重要モジュール	認証、決済、暗号、アイデンティティは、より深いレビューに値する。
エクスプロイトチェーンの分析	連鎖して初めて意味を持つ脆弱性がある。
モバイルセキュリティ	IPC、インテント、権限、ライフサイクルの挙動は非常に複雑。
クラウドアーキテクチャ	IAM、ネットワーク、ストレージ、サービスアイデンティティは微妙な形で相互作用する。
インシデント対応	深い推論によって、関連する未把握の弱点を追跡できる。

レイヤー3は強力ですが、計算負荷が高いものです。歯ブラシのようにではなく、重機のように使ってください。

詳細記事はこちら：フロンティアAIをオーケストレーションし、実際の攻撃者のように考えさせるために設計されたエンジニアリング上のラッパーを構築すると何が起きるのか。近日公開予定の技術解説『レイヤー3：重火器、深いアーキテクチャレビューのためにフロンティアモデルを活用する』をお待ちください。

---

プラットフォームの選択：Web/クラウドかネイティブモバイルか

これら3つのテストレイヤーを理解することは重要ですが、それらを効果的に実装するには、アセットのクラスが根本的に異なることを認識する必要があります。クラウドネイティブなWebアプリケーションを保護するためにテストエンジンを積み重ねる方法は、コンパイルされた低レベルのモバイルバイナリを監査するために構成する方法とはまったく異なります。

自社チーム固有のリスクベクトルとアーキテクチャ上のフットプリントを、適切なプラットフォームのアプローチに対応付けるために、以下の選択マトリクスをご活用ください。

選択基準	Aikido & XBOW （Web、クラウド、リポジトリ重視）	Ostorlab （モバイル、ピンポイントなAI重視）
主なリスクベクトル	Webアプリケーション、SaaSプラットフォーム、API、従来型のソフトウェアコードベース。	ネイティブモバイルアプリケーション（Android .apk、iOS .ipa、HarmonyOS .hap）。
環境の重点	クラウドインフラストラクチャ、コンテナセキュリティ、クラウド設定の衛生管理。	低レベルのOSデバッグプロトコル（JDWP/LLDB）を使用した、実際のモバイルハードウェア環境。
コード評価のスタイル	広範なコードベースの衛生管理（SAST、SCA、依存関係の追跡、オープンソースライセンスのコンプライアンス）。	深いバイナリ解析（バイトコードのリバースエンジニアリング、逆コンパイル、テイント追跡）。
データとシリアライゼーション	標準的なWebのデータフロー（REST、一般的なJSON API、基本的なGraphQL）。	複雑なモバイルのシリアライゼーション（Protobuf、gRPC、モバイルファーストのGraphQL、独自プロトコルのファジング）。
AIスキャンの手法	広範で自律的なWebエクスプロイトの計画と、全範囲のリポジトリスキャン。	個々のアセットに対する、ピンポイントで局所的なAIによるスポットチェック（SVAおよびDig Deeperのインライントリアージによる）。
対象となるエンジニアリングチーム	DevOps、クラウドネイティブのエンジニア、フルスタックのWeb開発者、AppSecのジェネラリスト。	ネイティブモバイル開発者、モバイルセキュリティの専門家、スピードが求められるバグバウンティのトリアージチーム。

自社チーム向けのまとめチェックリスト

• 💡 AikidoまたはXBOWを選ぶべき場合：主な関心事が、Webアプリケーションの保護、リポジトリの依存関係の整理、クラウド設定の監視、広範なソフトウェアサプライチェーンの脆弱性の防止である場合。
• 🎯 Ostorlabを選ぶべき場合：最も重要な資産がモバイルアプリである場合、（SSLピンニングのような）複雑なクライアント側の防御を回避する必要がある場合、あるいはセキュリティチームが大規模なフルスイートのスキャンを実行することなく、特定の個別のバグバウンティの報告を迅速に検証する必要がある場合。

---

コストこそがスケールの問題

コストは些細な話ではありません。コストによって、セキュリティ制御が現代の開発のスピードで実際に動作できるかどうかが決まります。チェックが安価であれば、あらゆる場所で実行できます。高価であれば、いつ実行するかを選ぶ必要があります。非常に高価であれば、それ相応の十分な理由が必要です。

だからこそ、AIだけに頼るテストは破綻します。現代のソフトウェアチームは、コミット、パッケージ、コンテナ、API、設定、生成されたコードを絶えずプッシュしています。そのすべてに深いAI分析を実行するのは持続可能ではありません。スケーラブルなAppSecプログラムは、設計段階からコストを意識したものでなければなりません。 1. 安価なチェックを常時実行する。 2. コンテキストが重要な場合にセマンティックレビューを実行する。 3. 深い推論がコストに見合う場合にサイバーモデルを実行する。

雰囲気ではなく、リスクに基づいてエスカレーションしてください。最良のセキュリティシステムとは、最も高級なモデルをあらゆる場所で使うシステムではありません。適切なレベルの分析を適切なタイミングで使うシステムです。

レイヤー	得意なこと	得意ではないこと
スキャナー	シークレット、CVE、設定ミス、既知のパターン	ビジネスロジック
BYOKセマンティックレビュー	認証フロー、データの移動、独自ロジック	システム全体にわたるエクスプロイトチェーン
サイバーモデル	深い攻撃経路、アーキテクチャレビュー	安価な継続的スキャン

これらのレイヤーは競合するものではありません。AIモデルがパッケージをインポートするコードを読むためにサイクルを無駄にする前に、スキャナーが既知の脆弱なパッケージを捉えるべきです。BYOKセマンティックレビュアーは、スキャナーが明白な問題を片付けた後で認可ロジックを分析すべきです。サイバーモデルは、一つの関数、一つのファイル、一つのプルリクエストよりも大きな問いのために取っておくべきです。

こうして、2つの典型的な失敗パターンを避けることができます。 * スキャナーだけのAppSec：安価で高速だが、浅すぎる。 * AIだけのAppSec：部分的には強力だが、高価で、不完全で、ノイズが多い。

答えは、スキャナーかAIかではありません。まずスキャナー、次にプライベートなAIレビュー、そして正当化される場合にはサイバーモデルです。

---

魔法の箱はない。あるのはスタックだけ

あらゆる脆弱性クラス、あらゆるビジネスルール、あらゆるCVE、あらゆる依存関係、あらゆるクラウドの権限、あらゆるモバイルのライフサイクル、あらゆるエクスプロイトチェーンを、完璧な精度と許容できるコストで理解する単一のAIプラットフォームは存在しません。それは製品カテゴリーではありません。調達部門向けのおとぎ話です。

AppSecの未来は、「AIがすべてをスキャンする」ことではありません。未来は階層型のテストです。可能な場所では高速に、必要な場所ではプライベートに、正当化される場所では深く。

正直に言えば、当社は魔法の箱を作ったわけではありません。そんなものは存在しないとわかっていますし、それを売りつけて皆さんの知性を侮辱するつもりもありません。その代わりに当社は、まさにこの3層の現実のために明確に設計された、現実的なエンジニアリングのワークベンチとしてプラットフォームを設計しました。単一のモデルや単一のツールにすべてをやらせることはしません。ノイズを早い段階で排除するための、非常に高速で堅牢なレイヤー1のルールエンジンを提供します。知的財産を危険にさらすことなく、プライベートでコンテキストを理解したレイヤー2のレビューのためにBYOK（Bring Your Own Key）を利用できる、分離されたアーキテクチャを提供します。そして、クラウドの予算を溶かすことなく、Mythosのようなレイヤー3のモデルが持つフロンティアの力を武器として活用するために必要な、精密なマルチエージェントのオーケストレーションハーネスを設計しました。

当社が売るのは銀の弾丸ではありません。当社が提供するのはスタックです。