予防は、本質的に解決済みの問題なのでしょうか？

エージェントが生成したコードに含まれる新たなセキュリティ問題のデプロイを阻止することは、アーキテクチャ上は解決済みの問題です。防止とは、機能ブランチへの導入を防ぐことを含め、開発およびリリースプロセスのいずれの時点でも、新たな脆弱性がコードに含まれたまま本番環境に到達しないようにすることです。エージェント型開発のライフサイクルには、セキュリティ上の問題が入り込む可能性のある明確なポイントがあり、それぞれに適した異なる種類の制御があります。それらの対応関係も十分に理解されています。ソフトウェア開発ライフサイクルが現に変化している組織内でこれを適用することが、その対応関係の適用を難しくしています。

プロンプトだけでは包括的に解決できない

エージェント型開発における理想化されたセキュリティの姿は、単一の指示です。エージェントに安全なコードを書くよう伝え、それをシステムプロンプトまたはハーネス設定に入れて、あとは動かすだけです。

図1. 制御のように感じられる指示。

コンテキストウィンドウ内のガイダンスは、エージェントが生成するものを実際に変えます。その効果は、活用の土台にできるほど確かなものです。しかし、指示は制約ではありません。書かれる内容の確率を変えるだけで、それを決定するわけではないのです。これは1行のルールにも、慎重に書かれたスキルにも当てはまります。プロンプトの品質にかかわらず、これはモデルの仕組み（すべての入力を考慮し、それらの相対的な優先度を判断すること）による性質です。

AIが生成したコードも、従来から人間が書いたコードを悩ませてきたものと同じ種類の脆弱性にさらされます。指示だけではそれを変えられませんし、どれほどプロンプトを工夫しても変わりません。したがって重要な問いは、それ以外のすべてをどこに配置するかです。

新たな「シフトイン」は、従来の「シフトレフト」

コードが書かれる瞬間から離れてセキュリティを外側へ移すほど、3つのコストが上昇します。

図2. セキュリティを外側へ移すほど、3つすべてが同時に上昇する。

トークンは明らかなものです。決定論的なスキャンのコストは、モデル呼び出しと比べれば誤差にすぎません。コードベースのより広い範囲を推論するようモデルに求めるたびに、その差は広がります。

人間の注意力が2つ目です。エージェントがまだ作業中に検出された問題は、チケットになることも、トリアージされることも、複数のタスクを抱えた誰かの作業を中断することもありません。

3つ目は、修正を正しく行うことです。内側のループで作業するエージェントは、元のプロンプトと仕様を保持しています。そのため、何かを修正するとき、コードが本来どう動くべきだったかを把握しているので、結果が機能的にも完全で安全でもあることを確認できます。同じ検出結果を外側へ移すと、そのコンテキストは失われます。正しさは、CIの前および実行中にユニットテスト、スモークテスト、統合テストを通じて外部から再確立しなければなりません。

既存機能を拡張するエージェントも、内側のループではテストスイートに依存します。見ていないものを壊していないことを確認する必要があるからです。ただし、プロンプトを保持しており、たまたま通るものから意図を推測するのではなく、変更が何をするはずだったのかを推論できるため、その依存度は低くなります。修正が外側へ移るほど、その負担の多くがカバレッジだけに移っていきます。

これが、セキュリティを内側へ移すべき理由です。自然にそうならないのは、逆方向に働く圧力のほうが強いからです。

セキュリティは摩擦である

これは何も新しいことではありません。セキュリティには時間がかかり、開発者のフローに時間を組み込むことは、常にこの仕事の難所でした。そのため、Snykは10年前にDevSecOpsにおけるシフトレフトを先駆け、成功させたのです。

エージェント時代はそれを変えるのではなく、増幅します。組織は、開発者の生産性が何倍にもなることを前提にAI導入を進めています。スループットが大きく向上することを期待されているとき、ループを遅らせるものはトレードオフの話し合いの対象にすらなりません。取り除かれるのです。

したがって問題は、セキュリティ制御を追加するかどうかではなく、それぞれを、得られる効果を上回るコストなしにどこへ配置できるかです。

ライフサイクルはループの積み重ね

Laurie Vossのループモデルは、現在のソフトウェアの構築方法を最も明快に説明するものの1つです。それぞれが独自のシグナルで完了する、入れ子になったループの集合です。

• 実行ループは指示を完了し、テスト結果、APIレスポンス、ファイルの内容など、環境からのフィードバックを受けて終了します。

• タスクループは仕様を完了します。

• プロダクトループはリリースします。

• システムループは数日から数週間かけて全体を改善します。

• 監督ループでは、人間が目標を設定し、予算を配分し、何が重要かを決めます。

図3. Laurie Vossの「そもそもループって何なんだ？」

実行ループとタスクループの内側では、作業はまだ進行中であり、人間の介入なしにループが完了する前に検出結果を修正できます。プロダクトループ以降では、テストカバレッジへの大きな信頼が必要です。そうでなければ、人によるレビューが必要になります。

これを基盤にする前に、2つ注意点があります。1つ目は、導入状況にはばらつきがあることです。エージェント開発の導入度合いは、同じ会社の中でもさまざまです。これらのループすべてでエージェントを実行しているチームばかりではなく、監督だけでなく内側のループで人が作業しているケースも多くあります。ループが表しているのは、誰が完了させたかではなく、作業がいつ完了するかなので、どちらの場合でも成り立ちます。

そして2つ目は、エージェント関連の用語を取り除けば、これはソフトウェアが長年構築されてきた方法の大部分そのものだということです。変更を反復し、作業単位を完了し、リリースし、システムを改善し、次に何をする価値があるかを誰かが決める。変わったのは速度と、キーボードの前にいるのが誰（または何）なのかです。

事前に名前を挙げられるリスク

SQLインジェクション、クロスサイトスクリプティング、ハードコードされたシークレット、弱い暗号のデフォルト設定、そして最も一般的なInfrastructure as Codeの設定ミスなど、完全に予測できるリスクがあります。何を探すべきかは正確にわかっており、1行書かれる前に、それを避ける方法をエージェントに伝えられます。

制御とは、エージェントのコンテキスト内にあるガイダンスです。システムプロンプト、ハーネス設定、そしてチームが最も阻止したいリスクを扱うスキルが該当します。問題ごとにコストを支払うのではなく、コンテキストウィンドウの容量として一度支払うため、利用できる制御の中で最も安価です。何も実行されず、何も評価されません。ガイダンスがそこにあるだけです。

何もデプロイしなくても、その一部はすでに導入されています。ハーネスには、これらの指示の一部をデフォルトで含むシステムプロンプトがあります。たとえば、Anthropicは各モデルのシステムプロンプトを公開しています。さらに、多くの組織が共有スキルレジストリを構築しており、自社チームの開発方法を説明するアプリケーション固有のスキルを含む場合もあります。つまり、セキュリティスキルは配布する新種のアーティファクトではありません。すでに存在するものへの、もう1つのエントリなのです。

ここでの限界はコンテキストです。すべての指示は、すでにウィンドウ内にある指示と競合します。あらゆる脆弱性クラスをエージェントのコンテキストに読み込むと、ほとんど表面化しないリスクのために、最も重要なガイダンスが薄まります。取捨選択が必要であり、残したものを別の何かが捕捉しなければなりません。そしてコンテキストは制約の半分にすぎません。容量が無制限でも、指示に書き込めないリスクがあります。指示を書いた時点では、誰もその存在を知らなかったからです。

エージェントに伝えようがなかった問題

開発者やエージェントがパッケージを選ぶとき、最新で必要な機能を備えているという理由で、最新バージョンを選ぶことがよくあります。そのバージョンの脆弱性が同じ週に開示されていたとしても、どちらも知る由はありません。モデルはその情報で学習されていません。開示がスキル作成時に存在していなかったため、そのスキルでカバーすることもできません。指示による防止にそれを期待するのは、誰に対しても合理的な要求ではありません。

さらに、前の段階で取捨選択したすべてのものがあります。システムプロンプトやスキルに含めるとコンテキストを汚染してしまう一方で、完全に現実的で、完全に検出可能なリスクのロングテールです。エージェントの立場から見ると、この2種類のリスクは同じ問題です。警戒するよう一度も指示されていないのです。

どちらにも、選択的ではなく徹底的に実行し、作業がまだ進行中のうちに作動し、エージェントがその結果に対応できるほど速く返すテストが必要です。そして、発見して終わりにすべきではありません。テストで明らかになった問題をエージェントが修正して再実行できれば、人間を一切巻き込まずにループが完了します。スループットを測定するチームに対しても生き残れるのは、これだけです。

Trusted Output Assurance（Evo Agentic Development Securityの一部）は、フックとCLIを通じてこれを実行します。ファイルが書き込まれるとスキャンが実行され、さらにエージェントが計画した作業を終えたときにも実行されます。これにより、新たに導入された問題が仕様の完了前に明らかになり、修正されます。すべて内側のループで完結します。パッケージ健全性チェック、シークレットスキャン、悪意あるコード対策も同じ経路で実行されます。

渡されたものをすべて修正するエージェントは、実在しなかった検出結果に対応するため、動作しているコードを書き換えてしまうことがあります。これが、この段階を確率的なエンジンではなく決定論的なエンジンに任せる理由の1つです。そのため、何を実行するかを選ぶ際には、誤検知率を検証する必要があります。また、検出結果についてエンジンとエージェントの意見が食い違ったときに何が起きるかも理解すべきです。Snykはその両方を最適化しています。制御が内側のループに置かれるのは、監視なしで対応できるほど頻繁に正しい場合だけです。確信度が低い場合、検出結果はさらに外側に置くべきです。

このような制御の価値は、その導入度合いに正確に比例します。内側のループのセキュリティが常に苦戦してきたのは、各開発者が自分で設定する必要があったからです。今ではその部分も簡単になりました。組織はMDMを通じてTrusted Output Assuranceを配布し、開発者のマシンに導入するとともに、サンドボックスのテンプレートに組み込みます。そのため、コードが生成される場所にはすでに存在し、どのマシンで何が実行されているかも、信頼に頼って確認するのではなく中央で把握できます。

高速で決定論的なエンジンが苦手とすること

認可とビジネスロジックの欠陥は、別の問題です。オブジェクトレベル認可の不備、IDOR、テナント分離の失敗、複数ステップにわたる悪用などです。これらはクラスとしては十分に理解されていますが、ルールベースのエンジンは発見が本当に苦手です。欠陥は構文ではなく意味に関わるものだからです。コード内のどこにも間違って見える箇所はありません。間違っているのは、要素同士の関係です。

ここで機能するのは、組み立てられたコードベースをLLMベースでスキャンする方法です。現在の実務では、組織がモデルに探索を促します。手動で行う場合もあれば、パイプラインでトリガーされるエージェント呼び出しとして行う場合もあります。ベンダー経由のこともあれば、最先端モデルをリポジトリに直接向けることもあります。

同じコードに対して同じセキュリティレビューを5回実行すると、モデルが独自に検出したもののほぼ半分は、5回のうち1回にしか現れません。それが、Snyk VulnBench JS 1.0で、同じレビューを300回実行して測定された結果です。

こうした一度きりの報告が間違っているわけではありません。VulnBenchには、ノイズではなく、カバレッジ上の本物の欠落に見えるものが数多く記録されています。しかし、1回の実行は意思決定ではありません。確信を得るには繰り返しが必要であり、そのため、ここが検出結果あたりのコストが単なる誤差ではなく、実際の項目になる最初のポイントです。

この段階で変わるのは、スキャンにかかる時間ではなく、調べる対象です。これより前の各制御は段階的に適用されます。エージェントがあるパターンに手を伸ばすと、スキルが作動します。セッション中に触れられた数十個のファイルではなく、直前に書き込まれた1つのファイルをスキャンします。それぞれが、すでに進行していた作業に吸収されます。組み立てられたコードベースの意味解析はそうはいきません。構成要素が揃うまで推論するものがないため、独立したステップとして実行され、そのコストがループ内に吸収されるのではなく追加されます。そのループにすでにかかった時間はエージェントが作業していた時間であり、待機に充てられる余裕ではありません。完全なパスによって、その長さが簡単に倍になることもあります。しかもこれは、結果がクリーンであることを前提としています。検出されたものはすべて修正し、分析を再実行する必要があるため、コストは加算ではなく複利的に増えます。だからこそ、これはエージェントが先へ進んだ後の段階に位置付けられるのです。

これらのサイクルはいずれも、テストスイートへの依存度がさらに高まります。その頃にはプロンプトはなくなっているため、セキュリティ修正と壊れた機能の間に立ちはだかるのはカバレッジだけであり、再実行のたびに、再びそれを支えることが求められます。ほとんどの組織では、修正を人手の介入なしに適用できるほどカバレッジの水準は高くないため、最終的には人がレビューすることになります。

Snykがエージェント型AppSecの未来に向かって進んでいるのは、まさにこの方向です。近いうちに、さらに詳しくお伝えします。

（本番前の）攻撃で初めて明らかになるもの

最後のカテゴリーは、何かが実行されているときにのみ現れます。複数ステップにわたるエクスプロイトチェーン、ワークフローの悪用、デプロイ済みエージェントに対するプロンプトインジェクション、そして環境内で3つのコンポーネントがたまたま相互作用する方法によってのみ存在するデータ流出経路などです。

ここで用いるコントロールは、実際のアプリケーションに対するペネトレーションテストとAIレッドチームによる敵対的テストです。検証対象となる弱点の種類は既知ですが、作業自体は探索的です。アプリケーションを出発点とし、あらかじめ境界を固定しないため、明らかになるのは、そのシステムが実際に許容するものです。

ここにEvo Continuous Offensive Securityがあります。何が作業を担っているのかを具体的に説明する価値があります。これは、モデルを後付けしたスキャナーではありません。オーケストレーションを担うペネトレーションテストエージェントが、稼働中のターゲットに対して専門のサブエージェントを実行します。別のバリデーターエージェントが他のエージェントの報告に反証を試み、実際に悪用できるエクスプロイトを構築して、それが事実であることを証明します。この最後の部分が重要です。探索的なモデル駆動型テストは、何かに裏付けられない限り、もっともらしい調査結果を生み出してしまうからです。そのため、すべての調査結果は仮説ではなく、実行可能な概念実証として提供されます。

これらのサブエージェントのうち3つ（ビジネスロジック、アクセス制御と認可、エクスプロイトチェーン）は、前のステージが必要とするものと同じ意味的カテゴリーに取り組んでいます。これらのエンジンや類似のエンジンを前のステージのワークフローに組み込み、ワークフローが定着するにつれて製品化していく作業は、すでに進行中です。

本番前環境に対するリリースゲートとして実行することも、リリース直後に実行して次に取り組むべき内容を判断することもできます。従来、これは年1回または半年に1回のコンプライアンス対応でした。現在、組織はこれをはるかに頻繁に実行しています。これは正しい判断です。なぜなら、攻撃者は監査スケジュールに従わないからです。

何かが実行されるまで攻撃する対象は存在しません。だからこそ、これをそれより早い段階で行うことはできないのです。

エージェントが知っていたこと、そして行動できたタイミング

上記のすべてのコントロールは、同じ2つの点にかかっています。エージェントがコードを書く前にそのことを伝えられたかどうか、そしてエージェントがまだプロンプトを保持している間に答えが届くかどうかです。この2つの問いによって、4つすべてのコントロールの位置が決まり、なぜこの順序が好みの問題ではないのかが説明できます。各コントロールは、以下の4つのボックスのいずれかに当てはまります。

図4. 2つの問いへの答えによって配置された、4つのコントロールの順序。

実際にはこれが難しい理由

設計図はシンプルです。しかし、実際の組織内で運用するのはそう簡単ではありません。その理由の多くは、セキュリティとはほとんど関係がありません。

ほとんどの組織では、エージェント型開発のライフサイクルがまだ確立されていません。標準化を進めているツール、ハーネス、アーキテクチャは今も変化しており、その変化が四半期ごとに起こることさえあります。ベンダーの状況も同じ速さで変化しているため、選択が済んでいる場合でも、一方向にしか進めない決定に近いものへコミットすることには、実際のためらいがあります。その結果として現れるのが、責任の所在の不明確さです。ライフサイクルの形がまだ流動的であれば、そのどの部分を誰が担うのかという問いも流動的だからです。認可やロジックの欠陥は、インシデントによって誰かに割り当てられるその瞬間まで、特定の誰の責任でもない状態になりがちです。

このどれも、すべてを白紙から始める必要があるという意味ではありません。ここは押さえておくべき重要な点です。ほぼすべての組織には、すでにデプロイ前のセキュリティゲートがあり、そのゲートは実際に機能しています。残りの部分を整理する間に、取り除くべきものではありません。これらの挿入ポイントは既存の仕組みの上に重ねて導入でき、ライフサイクルが実際に定着している状況に合わせて、一度に1つずつ、任意の順序で採用できます。決定論的スキャンをループ内に組み込むために、敵対的テストの責任者を決めておく必要はありません。

2つ目の点は、見過ごされがちです。内側のループでは、作業を人に差し戻すコントロールはすでに失敗しています。誰かがレビューするための、AIが作成したプルリクエストのキューを生み出すコントロールも同様です。どちらもセキュリティチェックを誰かのバックログに変えてしまいます。コントロールがひっそりと無効化されるのは、まさにそこです。

より外側では、人を避けるのが難しくなります。ほとんどの組織では、テストカバレッジは自律的な修正を信頼して適用できる水準には到底達していないため、誰かがレビューします。これはツールの失敗ではなく、今日の正直な現状です。ハーネスは、プロンプトなしでテストスイートを実行する能力を高めており、エージェントがテストも作成する場合にはカバレッジも向上します。しかし、どちらもすでに実現していることを前提に計画すべきではありません。エージェントがまだプロンプトを保持している間に、できる限りのことを検出するべき理由が、もう1つ増えます。人が介在しなくてよいのは、そこだけだからです。

1つ目と3つ目の点があるからこそ、状況がまだ変化している間でも、これを安全に始められます。午後のうちに構築でき、中央で再構成でき、あるいは完全に取り除くことができるコントロールであれば、ライフサイクルがどのようなものになるかを決める前に採用できます。現時点では、その特性は個々の機能よりも価値があります。

Trusted Output Assurance自体はMDMを通じて配布され、構成を一元管理するため、実行内容を変更する際にJamfやIntuneのポリシーを編集したり、デプロイスクリプトを書き直したりする必要はありません。Continuous Offensive SecurityにはアプリケーションのURLと一連の認証情報が必要なだけなので、何かを返す前に大規模な構築を行う必要はありません。どちらも、まだ確定していないアーキテクチャにコミットすることを求めません。

今は防止、次に修復

重要な意味において、防止は解決済みです。ポイントもコントロールも存在し、どの場所にどのコントロールを配置すべきかも分かっています。しかし、実行には作業が必要であり、(AI)SDLCは私たちの足元で進化し続けています。

修復は別の話です。ループ内の決定論的スキャンは、既知の脆弱なバージョンのパッケージを採用する瞬間に、その採用を阻止します。しかし、8か月前（あるいは8年前）に採用したパッケージに先週CVEが付与された場合、そのことには何も対処しません。このバックログは同時に2つの方向から膨らみます。修正されないまま蓄積した何年分もの調査結果と、すでに本番環境にあるコードに対して継続的に発生する新たな脆弱性情報です。優れた防止策はバックログを減らしませんが、悪化させることは防ぎます。

この問題には、独立した議論が必要です。当面、防止の側面は今すぐ利用でき、最初の一歩は見た目ほど大きくありません。ライフサイクルの中で最も安定しているポイントを選び、適切なコントロールを追加してください。