AIネイティブアプリが従来のAppSecモデルを崩す理由

AIネイティブアプリケーションは、セキュリティチームがこれまで保護してきたソフトウェアとは異なる動作をします。予測可能なロジックの経路をたどるのではなく、実行時にコードを生成し、ユーザー入力を再構成し、コンテキストに応じて判断します。モデルの振る舞いは、学習データ、ファインチューニング、プロンプト、検索ソースの変数が組み合わさって形作られ、開発者が予測しない形で判断を変化させます。

これにより、攻撃対象領域はコードや設定の枠を超えて広がります。プロンプトによってモデルの推論を誘導でき、汚染されたデータセットによって将来の出力がゆがめられ、制約が不十分なエージェントは開発者がプログラムしていないアクションを実行する可能性があります。これらはいずれも、従来のAppSecツールが依拠する静的で再現可能なパターンには当てはまりません。

その結果、従来のスキャナーでは答えられない疑問が数多く生じています。重要なワークフローを動かしているモデルは何で、どのようなデータがそのモデルを形作ったのでしょうか。検索ソースが変わったとき、RAGシステムはどのように動作するのでしょうか。これらは根本的なセキュリティ上の懸念ですが、従来のツールには答えを導くための可視性がありません。AIネイティブソフトウェアによって問題の構造は変わり、従来の前提はもはや通用しません。 

従来のAppSecは、コードパスが予測可能であることを前提としている

従来のAppSecの手法は、ソフトウェアが予測可能な経路に従うことを前提としています。コードを追跡できるため静的アプリケーションセキュリティテスト（SAST）が機能し、インターフェースが再現可能な動作をするため動的アプリケーションセキュリティテスト（DAST）が機能します。どちらのアプローチも、開発者がロジックを記述し、それが毎回一貫して動作するという考えに基づいています。

AIネイティブアプリケーションは、この基盤を崩します。LLMは、プロンプト、コンテキスト、検索情報に応じて振る舞いが変化するため、似た入力に対して異なる出力を生成する場合があります。この変動はコードの変更によるものではなく、モデル内部の推論によって生じます。

こうした変動は、従来のスキャナーが依拠している予測可能性を損ないます。SASTでは非決定的なロジックをマッピングできず、DASTでは実行時に出力が変わるとインタラクションを再現できません。どちらも、その場で生成されるロジックを評価できません。静的なコードではなくモデルが中核的な動作を形作る場合、従来のツールでは信頼できる評価を提供できません。

AIネイティブの脅威は、従来のカテゴリに当てはまらない

脅威カテゴリそのものを見ても、この不一致は明らかです。従来のスキャナーはコードの脆弱性の特定に優れていますが、AIネイティブのリスクはコードの外部に起因することが少なくありません。こうしたリスクは振る舞いから生じるため、既存ツールの多くでは対処できません。

プロンプトインジェクションは、その典型です。たった一つの入力でモデルの推論を誘導し、ガードレールを回避したり、コードに触れることなく内部データを漏えいさせたりできます。データポイズニングも、ライフサイクルのより早い段階で同様のリスクをもたらします。汚染された学習データによって、有害または悪用可能な出力がデプロイ後も長期にわたって生成される可能性があります。

RAGワークフローでは、検索ソースを改ざんすることで、コードを変更せずにモデルの振る舞いに影響を与えられるため、リスクが生じます。事前学習済みモデル、埋め込み、サードパーティ製エージェントなどを含む、より広範なモデルサプライチェーンにも不透明な依存関係が存在し、チームは全体を把握しないまま導入することが少なくありません。

こうした脅威はいずれも静的なコードではなく実行時に発生し、従来のスキャナーでは検出できない新たな脆弱性を生み出します。その結果、AppSecプログラムの多くが対処を想定していなかった死角が増え続けています。

破綻の原因：AppSecにはモデルレイヤーの可視性がない

こうした新たな脅威は、より根本的な問題を浮き彫りにしています。多くのAppSecプログラムは、モデルレイヤーをほとんど可視化できていません。チームはソフトウェアの依存関係をマッピングできても、本番環境でどのモデルが稼働しているか、またどのようなデータや学習プロセスがモデルを形作ったかを追跡していることはまれです。

重要なインタラクションも不透明です。プロンプトを追跡し、ガードレールを確認し、推論時の判断を監視する標準的な方法はありません。従来のログに記録されるのはAPI呼び出しであり、AIの振る舞いを左右する推論の過程やエージェントのアクションではありません。

その結果、従来のスキャナーではモデルドリフト、予期しないエージェントのアクション、外部データによる変化を検知できません。モデルレイヤーの振る舞いを監視するために作られていないため、新たな可視化手法がなければ死角は避けられません。

AIネイティブアプリには、新たなセキュリティ成果物「AI部品表（AI-BoM）」が必要

この可視性のギャップは、AIネイティブシステムに新しい種類のセキュリティ成果物が必要であることを示しています。AI部品表（AI-BoM）を使えば、使用中のモデル、それらを形作ったデータセット、振る舞いに影響を与えるプロンプトやエージェントを体系的に記録できます。これは、SBOMがソフトウェアサプライチェーンの構成要素を明確にするのと同様です。

これらの要素を一元化することで、AppSecプログラムに欠けているコンテキストを補えます。モデルの出所、データによる影響、変化するリスクを明確に把握できます。AI-BoMは、AIシステムの構成や依存対象を可視化し、ガバナンスやコンプライアンスも支援します。ワークフローが複雑化するなかで、リスクの評価と検出に一貫した基準を提供します。

AI-BoMは、AppSecに必要な基盤を再構築します。これがなければ、チームは見えない振る舞いに後手で対応せざるを得ません。AI-BoMがあれば、ソフトウェアを大規模に保護するために用いられてきた、構造化され説明責任を果たせるセキュリティフレームワークにAIを組み込めます。

エージェント型の振る舞いが限界をもたらす理由

チームがAI-BoMを通じてモデル、データセット、プロンプトの記録を始めると、もう一つの課題を無視できなくなります。AIシステムはもはや出力を生成するだけでなく、アクションを実行するのです。自律型エージェントは、固定されたロジックではなく目標に基づいてツールを呼び出し、ファイルを書き込み、システムを更新し、ワークフローを開始できます。コンテキストや検索情報に応じて振る舞いが変わるため、従来のAppSecでは分析できないレベルの自律性が生まれます。

従来の手法では関数や制御フローを評価できますが、意図を理解したり、エージェントが実行時に形成する分岐したアクションの連鎖をマッピングしたりすることはできません。こうした経路はコードが変わるからではなく、アクションの背後にある推論が変わることで、刻々と変化します。

AIネイティブアプリケーションの保護には、コードだけでなく、時間とともにコードが生み出す振る舞いも追跡する必要があります。エージェントがどのように動作し、何とやり取りし、判断がどう変化するのかを可視化しなければなりません。この動的な自律性が従来のAppSecの限界を示しており、新しいセキュリティモデルが不可欠です。

現代のモデルに即したセキュリティアプローチに必要なもの

従来のAppSecの限界を認識することは、第一歩にすぎません。次に必要なのは、AIシステムの実際の振る舞いに即したセキュリティモデルを定義することです。ロジックが動的で、エージェントが自律的に動作するなら、セキュリティは静的な成果物の分析から、モデルの振る舞いのライフサイクル全体の把握へと移行する必要があります。

その出発点となるのが可視性です。チームは、使用中のモデル、それらを形作ったデータ、推論時の振る舞い、エージェントが開始できるアクションを明確に把握する必要があります。このコンテキストがなければ、その後のすべての対策が後手に回ります。

ガードレールも進化させる必要があります。コードの品質や設定の適切さを確認するだけでは、もはや不十分です。最新のガードレールには、モデルの振る舞いを評価し、プロンプトの流れを追跡し、出力が想定されたパターンから逸脱した際に検知する機能が必要です。コードに潜むエラーだけでなく、危険な方向に進む推論にもフラグを立てられる必要があります。

こうしたシステムは適応するため、継続的な監視が欠かせません。ドリフト、データポイズニング、安全でない出力、予期しないツールの使用は、徐々に、あるいは一気に現れる可能性があります。従来の定期スキャンでは、こうした変化を見逃します。AIネイティブシステムでは、変化が重要になった瞬間にチームが検知できるよう、継続的な監視が必要です。

そして最後に、これらすべてを既存の開発ワークフローに統合する必要があります。デプロイ後に初めてセキュリティ対策を講じると、組織はすでに形作られた振る舞いに合わせて、後から対策を付け足すことになります。ライフサイクルの早い段階でこうした機能を組み込めば、リスクが根付く前に対処できます。

モデルに即したセキュリティアプローチは、AppSecに取って代わるものではありません。AIシステムの思考、判断、行動に合わせてAppSecを拡張するものです。

AppSecはAIセキュリティのオーケストレーションへ進化する

モデルに即したアプローチが基盤を築いても、組織にはそれを実践する方法が必要です。ここでアプリケーションセキュリティは、AIシステム全体のオーケストレーションという新たな形へと進化し始めます。モデル、プロンプト、データセット、エージェントを不透明な構成要素として扱うのではなく、それらを連携させ、振る舞いを監視し、稼働中にガードレールを適用する必要があります。

Evoはこの変化を体現します。特化型エージェントをオーケストレーションすることで、コードや設定を超えてセキュリティを拡張し、モデルの振る舞いを監視し、モデルレイヤーの脅威を検知し、リアルタイムでガードレールを適用します。これらのエージェントにより、チームは従来のAppSecでは見えなかったAIシステムの構成要素、つまり推論、検索先の選択、自律型ワークフローが実行するアクションを把握し、制御できるようになります。

Snyk Studioは、ライフサイクルのもう一方の段階を支えます。コード生成時にAIコーディングアシスタントをガイドすることで、後から修正するのではなく、AIが生成するコードを最初から安全にします。Studioは「開発の初期段階から安全」を支え、Evoはモデルの稼働、適応、動作に伴う振る舞いの安全を支えます。

両者が一体となることで、アプリケーションセキュリティの定義が広がります。AIネイティブの世界では、アプリケーションを保護することは、アプリケーションを動かすコード、駆動するモデル、そして代わりに行動するエージェントを保護することを意味します。Evoはこれらすべてを結び付け、AppSecを静的解析ではなくオーケストレーションに基づく未来へと導きます。

従来のAppSecは間違いではない——不完全なのだ

従来のAppSecが失敗したわけではありません。その周囲の環境が変化したのです。AIネイティブソフトウェアは、ロジックの記述方法、システムの振る舞い、リスクの発生源に関する長年の前提を覆します。もはやコードだけが唯一の真実ではありません。振る舞い、コンテキスト、モデルに基づく意思決定がアプリケーションを形作りますが、静的ツールはこうした要素を解釈するようには設計されていません。

この新たな種類のシステムを保護するには、モデルの推論、エージェントの行動、ワークフローの進化を継続的に可視化する必要があります。変化を早期に認識した組織は、開発を遅らせ、隠れたリスクにさらす死角を回避できます。より迅速に、自信を持って構築を進め、AIを制御不能な変数ではなく、開発を加速する力として活用できます。

Snykは、その変化をリードしています。コードからモデル、プロンプト、エージェント型の振る舞いへとセキュリティを拡張し、AppSecをコード中心の規律からAIに即したものへと進化させています。これが業界の進むべき方向であり、私たちが目指している未来です。

ガードレールを組み込んだAIネイティブアプリケーションの構築を始めませんか？エージェント型アプリを保護し、新たな脅威の状況を乗り越えるための決定版ガイドをご覧ください。