Remediation Agentsの謎を解く：脆弱性の発見より修正が重要な理由

セキュリティ上の新たな問題が 1件修正されるたびに 6件 発生しています。 Snykの調査で明らかになったこの比率を受け、AI Security Engineers Communityは、問題の発見ではなく修正に焦点を当てたライブ配信に1時間を割きました。

Play Video: Remediation Agents Demystified: Your AI Teammate for Fixing Security Bugs

Remediation Agentsの謎を解くでは、炉辺談話とライブデモを実施しました。Snykが運営するAI Security Engineersコミュニティの責任者、Gérald Crescioneが進行役を務め、Snykで修復製品を統括するRyan McMorrowと、Snykの開発者エクスペリエンスおよびAgentic AppSecソリューション担当シニアプロダクトマーケティングマネージャーのBrendan Hannが参加しました。

現在パブリックプレビュー中のRemediation Agentは、増え続ける問題に対するSnykの回答です。Snykは開発を続け、公開の場で改良を重ねるなか、コミュニティから実用的なフィードバックを得ることを条件に、すべての既存顧客にRemediation Agentを追加料金なしで提供しています。フィードバックはコミュニティのサブレディットで共有できます。

修正率が横ばいのままだった理由

開発者が日常的に使うコーディングエージェントは、安全な機能コードではなく、機能するコードの生成を最適化しています。そのため、問題の数は増え続ける一方、修正率は横ばいです。AppSecツールは、決定論的なアドバイスで対応してきました。「バージョン1.0を使っていますが、脆弱性は1.1で修正されています。アップグレードしてください」というものです。そこまではよくても、アップグレードによって何も壊れないことを証明する作業は、依然として誰かが行わなければなりません。その作業を開発者に代わって行うツールはありませんでした。メジャーバージョンを3つ、4つも飛び越えるとなると、多くのチームはマージに必要な確信を持てずにいました。

Hannは、このボトルネックをより大きな変化の一部として捉えています。AIによって、互いに関連する3つの圧力が生まれました。攻撃がAIで自動化され、エージェントはこれまでにない速さでソフトウェアを書き、同じペースで脆弱性を持ち込み、さらにAIが十分なガバナンスなしに本番環境へ導入されつつあります。Hannによれば、修復は以前からボトルネックでしたが、攻撃者のツールも姿を変えた今、その重要性は一層高まっています。最先端クラスのモデルはサンドボックスを突破し、これまで無視できた低深刻度の問題を連鎖させて、未知のゼロデイ攻撃を生み出します。許容されたリスクのバックログそのものが、新たな攻撃対象領域になっているのです。

Agentic AppSecは、予防的なコントロール、最先端レベルの検出、自律的な修復を組み合わせたアプローチです。Hannの言葉を借りれば、チームにエージェントチームを提供し、AppSecプログラムを実際に運用できるようにします。

バックログにLLMを投入するだけではうまくいかない理由

Snykの研究者が最初に試したのは、当然ともいえる方法でした。セキュリティ上の問題が並ぶバックログにLLMを適用し、何が起こるかを確かめたのです。

モデルは非常に意欲的でしたが、正解するのはごく一部でした。開発者は依然として変更を一つずつレビューし、その大半を却下しなければならず、かかる時間は手作業で問題を修正する場合とほぼ変わりません。より大きなモデルを使っても、同じことがさらに増えるだけでした。

転機となったのは、チームが別の問いを立てたことでした。LLMに、Snykが持つすべての知見を与えたらどうなるか。アプリケーションセキュリティのベストプラクティスを10年にわたって蓄積した知見、エコシステムごとのアップグレードに関する知識、そして、どの修正ならマージされ、どれがされないのかを見極めてきた経験です。

こうして生まれたのがRemediation Agentです。McMorrowによれば、これは開発者が選んだモデルと、Snykが追跡するすべての問題やCVEを網羅する、呼び出し可能なインテリジェンスレイヤーとの間に位置する、ハーネスまたはオーケストレーションレイヤーです。必要に応じて、エージェントは次の情報を取得できます。

• 修正による影響の評価：オープンソースのアップグレードでビルドが壊れる可能性をスコア化。すべてのパッケージバージョンと、それぞれの破壊的変更を網羅したデータベースに基づきます。

• パッケージの健全性と到達可能性スコア：脆弱なコードが本番環境で悪用可能かどうかも含みます。

• SASTの修正コード生成：SnykのAgent Fix機能を活用します。

• エコシステム別プレイブック：Snykのセキュリティエンジニアが作成。シニアのセキュリティ実務者が推移的依存関係をアップグレードする方法や、特定の種類のSAST検出結果を解消する方法を網羅します。

McMorrowは、LLMが持ち込み可の試験を受けるようなもので、Snykがその参考書を渡す、と例えました。さらにSnykはエージェントの成果を採点します。スキャンを再実行して問題が本当に解消されたことを確認し、プロジェクト内のユニットテストも実行して、変更によってビルドが壊れていないかを確かめます。

McMorrowが共有した社内の結果では、マージ可能なSCA修正が94%、マージ可能なSAST修正が13%向上しました。社内で生成されたSAST修正の大半は、そのままマージできるようになり、単純なアプローチに比べてトークンコストも大幅に低減しました。

Hannは、Snykのデザインパートナーが特に成果を上げている3つの活用パターンも紹介しました。

1. バックログ一掃キャンペーン：攻撃者が連鎖させて悪用するようになった、低深刻度および情報レベルの検出結果を解消する

2. 組織全体への展開：すべての開発者に修復エージェントを提供する

3. エージェント型開発環境（ADE）で修復エージェントを使い、新たな問題がコードベースに入り込むのを防ぐ

デモ：IDEとCLI

McMorrowはOWASP Juice Shopを使ってエージェントを実演し、2つの利用方法を紹介しました。

1. IDEでの利用

IDEで使うには、/snyk-fixスキルとSnyk Studio MCPサーバーの2つが必要です。どちらもSnykのレシピリポジトリから、curlコマンド1つでインストールできます。これにより、Cursor、Windsurf、Antigravity、またはClaudeプラグインを備えたVS Codeで、SASTやSCAのスキャンからインテリジェンスの参照、コード変更、再スキャン、テスト実行、レポート、プルリクエストまで、一連の作業をIDE内で完結できます。デモでは、脆弱なmulter依存関係をメジャーバージョンをまたいでアップグレードし、ディスクストレージの利用に影響する破壊的なAPI変更がないことを確認して、ロックファイルを更新しました。

2. CLIでの利用

CLIのsnyk fix --agentic --experimental --scaは、より対話的に利用できます。アップグレード可能と判断した各パッケージについて、現在のバージョン、最も多くの重大および高深刻度の問題を解消するためにSnykが推奨する移行先バージョン、そして修正による影響のスコアが表示されます。開発者は次の操作を行えます。

• すべて修正する

• 影響が小さい項目だけを修正する

• 特定の検出結果を選択する

• エージェントに質問する

McMorrowは、Globのメジャーバージョンアップが高リスクと評価された理由を尋ねて、最後の機能を実演しました。エージェントは、PromiseベースのAPIへの移行、コールバック形式の廃止、パス区切り文字がエスケープ専用文字になること、そしてGlobクラスがイベントエミッターではなくなることを説明しました。また、このアップグレードで解消できる推移的脆弱性も一覧で示しました。そのうえで、最新バージョンに移行する際には同じ影響分析の情報を活用し、補完するコード変更を加えることで、高リスクのアップグレードを低リスクに変えます。

判断の根拠について質問されると、McMorrowは、オープンソースエコシステム全体のリリースノートや破壊的変更を分析して、修正による影響を判断していると説明しました。デザインパートナーからの報告では、誤検知はほとんどありません。誤検知が主に懸念されるのはSAST側ですが、エージェントは既存のSnyk Codeエンジンを利用してそれらを除外します。

人が関与する段階から、人が監督する段階へ

デモでは、どの利用方法もプルリクエストの作成で終わりました。Hannの言葉を借りれば、「無謀なコード変更を勝手に加えるわけではありません」。エージェントに十分な信頼が寄せられ、誰もが成果物を気軽にマージできるようになるまでは、開発者が最終承認を行います。

現在、Snykの社内チームはCLIからエージェントを実行しており、自律型の機能も積極的に開発中です。Snykがサンドボックスを起動してエージェントをインストールし、アプリケーションコードを取り込んで、完成したPRを返します。これまでSnykのCIパイプラインは、新たな脆弱性を検出すると処理を止め、問題を開発者に差し戻していました。今では修正を自動生成し、開発者は自分のコミットと合わせてエージェントの変更をマージできます。McMorrowによれば、エンジニアは修正のために何度も手を戻さずに済むことを喜んでいます。

Hannは、「バックログゼロ」は現実的な目標だと指摘しました。また、開発者のマシンと組織の両方のレベルで、悪意のあるパッケージやslopsquattingをブロックすることにも言及しました。McMorrowは、長期的に重要なのは制御、ガバナンス、信頼であり、人が関与する状態から人が監督する状態へ移行することだと述べました。違いは、誰が判断を下すかです。「関与する」状態ではエージェントとのペアプログラミングを行い、「監督する」状態ではエージェント自身が判断し、いつ人に相談すべきかを把握します。Crescioneは、これが新たに生まれつつある職務像だと付け加えました。AI Security Engineersが、自分たちに代わってエージェントの群れを指揮するのです。

実際に試してみる

利用を始めるには、SnykアカウントとCLIまたは対応するADEに加え、独自のモデルAPIキーが必要です。オープンプレビューでは、独自のLLMを持ち込む方式がデフォルトとなっています。オープンソースのメンテナーは、エンタープライズライセンス一式を含むSecure Developer Programを通じて、プラットフォーム全体を無料で利用できます。

期待外れの修正を見つけましたか？r/AISecEngでお知らせください。皆さんのフィードバックは、Snykが開発を続け、公開の場で改良を重ねるなか、Remediation Agentの今後を形づくる助けとなります。