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

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つの要素が必要です。1つは/snyk-fixスキル、もう1つは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の既存エンジンを使ってフィルタリングします。

Human in the loop、そしてhuman on the loopへ

デモのすべてのパスは、プルリクエストで終わりました。Hann氏の言葉を借りれば、「無茶なコード変更を行うわけではありません」。開発者は、エージェントが誰でもその成果物を無謀にマージしてよいほどの信頼を得るまで、最終承認権を保持します。

Snyk自身のチームは現在CLIからエージェントを実行しており、自律型のバリアントも積極的に開発中です。Snykはサンドボックスを起動し、エージェントをインストールしてアプリケーションコードを取り込み、完成したPRを返します。以前のSnykのCIパイプラインは、新たな脆弱性が見つかると停止して問題を開発者に戻していました。今では代わりに修正を生成し、自分のコミットとともにエージェントの成果物をマージできます。McMorrow氏によると、エンジニアは問題に戻って対応する必要がないことを喜んでいます。

Hann氏は、「バックログゼロ」を現実的な目標として挙げ、開発者のマシンおよび組織レベルで悪意のあるパッケージやスロップスカッティングをブロックすることにも言及しました。McMorrow氏は、長期的なテーマは制御、ガバナンス、信頼であり、人間がループ内にいる状態から、ループ上にいる状態へ移行することだと主張しました。違いは誰が決定するかです。in the loopはエージェントとのペアプログラミングであるのに対し、on the loopはエージェントが自ら決定し、いつあなたに相談すべきかを把握する状態です。Crescione氏はさらに、これが新たに生まれつつある職務内容だと付け加えました。AI Security Engineersが、自分たちに代わって働くエージェントの群れを統率するのです。

実際に試す

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

修正が期待どおりにいかなかった場合は、r/AISecEngでお知らせください。Snykが公開の場で開発と改善を続けるなか、皆さまのフィードバックがRemediation Agentの今後の方向性を形作る助けになります。