修正エージェントをわかりやすく解説：見つけるより直すことが重要な理由

6つの新たなセキュリティ問題が、修正された1つの問題ごとに発生しています。 Snykの調査で明らかになった割合です。だからこそ、AI Security Engineers Communityは、問題を見つけるのではなく修正することにライブ配信の1時間を充てました。

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

Remediation Agents Demystifiedでは、炉辺談話とライブデモを組み合わせました。Gérald Crescione（グローバルAI Security Engineersコミュニティ責任者）が司会を務め、Ryan McMorrow（Snykで修正プロダクトを率いる責任者）と、Brendan Hann（Snykの開発者エクスペリエンスおよびAgentic AppSecソリューション担当シニアプロダクトマーケティングマネージャー）が参加しました。

Remediation Agentは現在パブリックプレビュー中で、私たちが直面している問題数の課題に対するSnykの答えです。Snykは、公開の場で構築と反復を続ける一方、コミュニティから実行可能なフィードバックを得ることを条件に、現在Snykを利用しているすべてのお客様にRemediation Agentを追加費用なしで提供しています。このフィードバックはコミュニティのsubredditで共有できます。

修正率が横ばいにとどまった理由

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

Hannは、このボトルネックをより広範な変化の中に位置づけました。AIによって、相互に関連する3つの明確なプレッシャーが生まれています。攻撃がAIで自動化されるようになったこと、エージェントがかつてない速さでソフトウェアを書き、それと同じペースで脆弱性も導入していること、そしてAIがしばしばガバナンスなしに本番環境へ到達していることです。彼は、修正は以前からボトルネックでしたが、攻撃者のツールも形を変えた今、その重要性は増していると主張しました。最先端クラスのモデルはサンドボックスを突破し、以前なら無視できた低深刻度の検出結果を連鎖させて、新たなゼロデイを生み出します。受容されたリスクのバックログは、それ自体が攻撃対象領域になっています。

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はその後、エージェントの宿題を採点します。スキャンを再実行して問題が本当に解消されたことを確認し、プロジェクト内のユニットテストを実行して変更によってビルドが壊れていないことを確認します。

彼が共有した社内結果では、マージ可能なSCA修正が94%、マージ可能なSAST修正が13%改善しました。現在、社内で生成されたSAST修正の大半はそのままマージされており、単純なアプローチよりもトークンコストが大幅に低くなっています。

Hannは、Snykのデザインパートナーが最も成果を上げている3つのパターンを追加しました。

1. バックログ削減キャンペーン。攻撃者が今や連鎖させている低深刻度および情報提供レベルの検出結果を一掃します

2. 組織全体への展開。すべての開発者に修正エージェントを寄り添わせます

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

デモ：IDEとCLI

McMorrowはOWASP Juice Shopに対してエージェントをライブで実行し、2つの入口を示しました。

1. IDEパス

IDEパスには2つの要素が必要です。/snyk-fixスキルとSnyk Studio MCPサーバーで、どちらもSnykのrecipesリポジトリから1つのcurlコマンドでインストールできます。これにより、Cursor、Windsurf、Antigravity、またはClaudeプラグインを備えたVS Code内で、SASTおよびSCAスキャンからインテリジェンス検索、コード変更、再スキャン、テスト実行、レポート、プルリクエストまで、完全なループを実行できます。ステージ上では、脆弱な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は、「バックログゼロ」を現実的な目標として挙げ、開発者マシンおよび組織レベルで悪意のあるパッケージやスロップスクワッティングをブロックすることにも言及しました。McMorrowは、長期的には制御、ガバナンス、信頼が重要だと主張しました。人間がループ内にいる状態から、人間がループ上にいる状態へ移行することです。違いは誰が決定するかにあります。ループ内とはエージェントとのペアプログラミングであり、ループ上とはエージェントが自ら決定し、いつ人間に呼びかけるべきかを理解する状態です。Crescioneはさらに、これが生まれつつある職務内容だと付け加えました。AI Security Engineersが、自分たちに代わってエージェントの群れをオーケストレーションするのです。

実際に使ってみる

始めるには、Snykアカウントと、CLIまたはサポート対象のADEのいずれか、さらに自身のモデルAPIキーが必要です。オープンプレビューではBring Your Own LLMがデフォルトとなっているためです。オープンソースのメンテナーは、Secure Developer Programを通じてプラットフォーム全体を無料で利用できます。これにはエンタープライズライセンス一式が含まれます。

修正が期待どおりでなかった場合は、r/AISecEngでお知らせください。Snykが公開の場で構築と反復を続ける中、皆さまのフィードバックはRemediation Agentの次の展開を形作るのに役立ちます。