VulnBump：AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるか？

AIエージェントは、ビルドを壊さずに脆弱な依存関係を修正できるでしょうか？修正そのものが難題であることは、ほとんどありません。2026年の6か月間に、Snyk Open Sourceは約30万の組織で4億5,900万件の脆弱性を検出しました。そのうち94%には修正済みバージョンが存在していたにもかかわらず、実際に解消されたのは約10%にとどまりました。

その理由は、安全にアップグレードすることが難しいからです。脆弱なパッケージの大半は間接的に依存関係へ取り込まれています。また、修正の約4分の1にはメジャーバージョンへの更新が必要です。さらに、後方互換性があるはずのマイナーリリースやパッチリリースでさえ、破壊的変更が含まれることは珍しくありません。

VulnBumpは、Snykが発表した最新の研究で、脆弱な依存関係の実際のアップグレード307件を使ってAIエージェントを検証します。脆弱性が解消され、プロジェクトのインストール、ビルド、テストがすべて正常に完了した場合にのみ、アップグレードをPASSと判定します。

新しいポイント：私たちの知る限り、VulnBumpはセキュリティ対応のアップグレードを軸に構築された、AIエージェント向け初のベンチマークです。各タスクは、Snykが実際のプロジェクトで検出した実際の脆弱性から始まり、6種類のパッケージマネージャーを対象としています。従来のアップグレードベンチマークでは、破損の有無だけを確認し、脆弱性が解消されたかどうかは検証していません。

では、AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるのでしょうか？大半はできます。ただし、結果を左右するのはモデルだけではありません。同じモデルClaude Sonnet 5.5を使った場合、SnykのEvo Remediation Agentはアップグレードの90.2%でPASSしました。AnthropicのClaude Codeは、Snykが推奨するアップグレードとスキャン情報を与えた場合（Claude Code + Snyk scan）に77.5%、Snykのデータなしの場合（Claude Code unaided）に59.6%でした。差は30ポイント以上です。参考までに、AIを使わずSnyk推奨バージョンを適用するだけの基準値であるパッケージマネージャーによる更新でも、46.9%がPASSしました。

VulnBumpの主な結果

ビルドを正常に保つことは難題ではありませんでした。3つのエージェントはいずれも約93%の割合でそれを達成しました。難しかったのは、脆弱性の解消です。Claude Code unaidedの124件の失敗のうち70件では、再スキャンで脆弱性が残っていると判明したにもかかわらず、Claude Codeは修正できたと報告していました。

今回の結果は、AIによるセキュリティレビューを評価した6月のベンチマークVulnBenchとも一致しています。VulnBenchでは、ClaudeとSnyk Codeが異なる脆弱性を見逃すことがわかり、両者の組み合わせが最も効果的だと結論づけました。VulnBumpが検証するのは別のタスク、つまり脆弱なオープンソース依存関係のアップグレードですが、同じ傾向が見られます。Snykの推奨バージョンとスキャン情報を与えると、Claude CodeのPASS率は17.9ポイント上昇しました。Evo Remediation Agentは、専用設計のエージェントがさらにどこまで実現できるかを示しています。同じSnykスキャン情報を与えたClaude Codeを12.7ポイント上回りました。またVulnBumpは、5月に発表した修正結果を、新しいモデルと6種類のパッケージマネージャーを使って検証したものでもあります。

VulnBumpの構築方法

本番環境に近い実際のプロジェクトから始めました。人気のオープンソースプロジェクトや、既知の脆弱なパッケージのバージョンを固定しているリポジトリなど、GitHubから候補となるプロジェクトを767件集めました。変更前の状態で、いずれもインストール、ビルドができ、テストの85%以上に合格する必要があり、さらにSnykが少なくとも1件の脆弱性を検出することを条件としました。条件を満たした99件から、エコシステム、脆弱性の深刻度、直接依存か間接依存か、バージョン差分の大きさについて、Snykの本番データに近い43件を選びました。

VulnBumpデータセットとSnyk Open Sourceの本番データとの比較

推奨されるアップグレードをそれぞれタスクにしました。各タスクでは、Snykが推奨する1件のアップグレードをエージェントに適用させます。対象は1つのパッケージで、脆弱性を解消できるバージョンに更新します。各タスクはプロジェクトの新しいコピーから開始し、個別に評価します。43のリポジトリから307件のタスクを用意し、Maven、Gradle、npm、Yarn、pip、Poetryの6種類のパッケージマネージャーを対象に、修正可能な脆弱性2,066件をカバーしました。この6種類で、本番環境の検出結果の約92%を占めます。

エージェントの自己申告を信用しない検証器を追加しました。エージェントの作業が終わったら、変更をクリーンなコンテナにコピーし、最初から検証しました。次の4つのゲートをすべてクリアした場合にのみ、試行をPASSと判定します。

1. 依存関係をインストールできること。CIで実行されるコマンドを使って確認します。

2. Snykの新しいスキャンで脆弱性が解消されたことを確認します。

3. プロジェクトをビルドできること。

4. 変更前に合格していたテストがすべて引き続き合格すること。

VulnBumpのパイプライン

検証したハーネス。3つのエージェントはいずれもClaude Sonnet 5.5で実行し、アップグレード1件あたり最大110ターン、各言語で同じコンテナを使用しました。

• Evo Remediation Agentは、Snykのエージェント型修正エンジンです。Snykの脅威インテリジェンスを活用し、自らスキャン、ビルド、テストを実行できるほか、完了前にエラーを修正できます。自動承認モードで実行したため、ビルドを壊す可能性が高いとSnykが評価したアップグレードも含め、すべての修正を適用しました。

• Claude Code Snyk scanはAnthropicの汎用コーディングエージェントです。アップグレード対象のパッケージ、更新先のバージョン、解消される脆弱性を含むSnykの推奨情報を与えました。作業の確認にSnyk Open Sourceのスキャンを自ら実行することもできます。

• Claude Code unaidedには、更新先のバージョンもSnykへのアクセスも与えず、同じタスクを渡します。脆弱性を修正するバージョンを自力で特定する必要があり、たとえばウェブ上の脆弱性データベースを検索します。

• パッケージマネージャーによる更新は、エージェントを使わない基準値です。プロジェクトのパッケージマネージャーでSnykの推奨バージョンを適用し、それ以外は何も変更しません。

リポジトリの選定方法、各エージェントに与えた正確なプロンプトとツール、データ漏えい対策の詳細は、研究論文「VulnBump: ビルドとテストを正常に保ちながら、実プロジェクトの脆弱な依存関係を修正するベンチマーク」をご覧ください。限界についても説明しています。1つのモデルのみを検証し、各アップグレードを1回だけ実行しました。また、評価にはSnyk Open Sourceを使用しました。そのため、他の2つのエージェントは同じSnykの検出結果に基づいていることから、Claude Code unaidedにのみ不利な条件となる可能性があります。アップグレードによって新たに持ち込まれた脆弱性も減点対象にしていません。

結果1：同じモデルでも、結果は3通り

Evo Remediation Agentはアップグレードの90.2%ですべてのゲートに合格し、脆弱性2,066件のうち95.9%を修正しました。Claude Code + Snyk scanを12.7ポイント上回り、アップグレード8件につき約1件多く修正に成功したことになります。Claude Code unaidedとの差は30.6ポイントでした。

順位は一部の大規模なリポジトリだけで決まるわけではありません。リポジトリごとに平均したPASS率は、Evo Remediation Agentが93.1%、Claude Code + Snyk scanが80.1%、Claude Code unaidedが68.0%、パッケージマネージャーによる更新が51.3%でした。

結果2：安全なバージョンを知ることが重要

同じモデルでも、Claude CodeにSnykのスキャン結果と推奨アップグレードを与えると、PASS率は59.6%から77.5%へ17.9ポイント上昇しました。

最も明確な違いは、選ぶバージョンです。Snykの情報を与えない場合、Claude CodeはSnykが依然として脆弱性ありと判定するバージョンを64回選びました。Snykのスキャン情報を与えた場合は13回に減りました。どのバージョンで脆弱性が修正されるかは、脆弱性データベースによって一致しないことがあります。そのため、ある情報源では安全に見えるバージョンでも、別の情報源では依然として問題ありと判定される場合があります。

Snykのガイダンスが特に重要なのは、プロジェクトが直接宣言していないパッケージに含まれる間接的な脆弱性です。すべてのゲートに合格したアップグレードだけを数えると、Claude Codeが修正できた間接的な脆弱性の割合は28%から59%へと2倍以上に増えました。

結果3：Snykの推奨だけで約半数は解決し、残りでエージェントの差が出る

パッケージマネージャーによる更新では、307件のアップグレードは2つに分かれます。PASSした144件では、Snykの推奨バージョンを適用するだけで十分で、エージェントは簡単な修正を維持するか、失敗させるだけです。残りの163件では、破壊的変更へのコード対応や依存関係の競合解決など、バージョン更新以外の作業が必要です。

Snykの推奨で解決できる144件と、残りの163件におけるエージェントの結果

Snykのガイダンスがあれば、エージェントがバージョン更新だけで解決できる問題を悪化させることはほとんどありません。一方、Claude Code unaidedは144件のうち20件で以前より悪い結果となり、そのうち15件ではSnykが依然として問題ありと判定するバージョンを選びました。本当の差が明らかになるのは難易度の高い半分です。残りの163件では、Evo Remediation Agentが82.2%、Claude Code + Snyk scanが61.3%、Claude Code単独が36.2%でPASSしました。

結果4：ビルドが成功しても、脆弱性が残っている場合がある

ビルドを正常に保つ最も簡単な方法は、脆弱性をそのまま残すことです。Claude Codeの失敗は、主にここで起きました。Claude Code unaidedの失敗124件のうち107件は再スキャンが最初に失敗したゲートで、Claude Code + Snyk scanでは69件中48件でした。一方、Evo Remediation Agentでは30件中9件でした。

失敗した各試行で、最初に不合格となった検証ゲート

Evo Remediation Agentの失敗は表面化します（それは悪いことではありません）。失敗30件のうち21件はビルドまたはテストを壊しており、その多くは他のエージェントが避けがちなメジャーアップグレードで起きました。失敗が明確にわかるほうが、気づかれない失敗よりはるかに安全です。アップグレードがうまくいかなくても、プロジェクトのビルドやテストに異常が現れるため、開発者が気づき、いずれ対処できます。

結果5：更新先のバージョンを知るだけでは不十分

Snykのスキャン情報があれば、Claude Codeは大きく前進します。しかし、アップグレードを正しく完了するには、それだけでは足りません。同じ検出結果と更新先を与えた場合でも、Evo Remediation AgentはClaude Code Snyk scanより39件多くアップグレードを修正し、そのうち23件はメジャーバージョンへの更新でした。

Evo Remediation AgentはSnykの脅威インテリジェンスに加え、プロジェクトをビルド、テストし、修正するループを完了前に実行します。今回の実験設定では、どの構成要素が差を生んだかを切り分けられません。しかし、モデルを取り巻くシステムが結果に大きく影響しうることを示しています。これは、ハーネスだけを変えて結果に最大16.3ポイントの差が出たDepBenchとも一致します。

結果6：メジャーアップグレードと間接依存関係が依然として最難関

メジャーなフレームワークの移行は、すべてのエージェントにとって依然として困難です。Spring、Spring Boot、Dropwizardの移行を中心とする23件のアップグレードは、3つのエージェントすべてが失敗しました。

メジャーアップグレードとそれ以外のアップグレードを比べると、PASS率はEvo Remediation Agentが96%から81%へ、Claude Code + Snyk scanが88%から61%へ、Claude Code unaidedが70%から42%へ低下しました。コード変更が必要になるのもメジャーアップグレードです。Evo Remediation Agentがメジャーバージョン更新でPASSしたケースの約半数ではアプリケーションのソースコードを編集していましたが、メジャー以外の更新で編集した割合は5%でした。

バージョン差分の大きさ別に見た、すべてのゲートに合格したアップグレード

脆弱なパッケージがマニフェストに直接宣言されていない間接的な脆弱性は、修正可能な脆弱性全体の70%を占め、検証したどのハーネスにとっても難易度が高い項目です。すべてのゲートに合格した試行の修正のみを数えると、間接的な脆弱性の修正率はEvo Remediation Agentが73%、Claude Code + Snyk scanが59%、Claude Code unaidedが28%でした。直接依存関係では、それぞれ91%、71%、62%でした。

依存関係の種類（直接依存と間接依存）別のPASS率

VulnBumpとVulnBenchの関係は？

VulnBenchは、AIコーディングエージェントが自分で書いたコードの脆弱性をどのように検出するかを評価します。複数回の実行で同じ問題をどれほど一貫して検出するか、また検出結果が決定論的なSASTの基準とどれほど一致するかを調べます。VulnBumpは、依存しているコードの脆弱性を修正できるか、つまりビルドやテストを壊さずに脆弱なオープンソース依存関係をアップグレードできるかを評価します。

2つのベンチマークを合わせて見ると、同じ傾向が浮かび上がります。モデルには、決定論的なツールにはない推論能力があります。しかし、モデルだけでは実行ごとに異なる検出結果を出し、修正まで至らないことも少なくありません。プラットフォーム全体に通じる教訓を、私たちはこう表現しています。生成するものを検証役にしてはならない。

エージェントにセキュリティ業務を任せるチームにとって、これは何を意味するのでしょうか？

• エージェントが生み出していない証拠で修正を評価しましょう。エージェント自身による修正報告はあくまで主張です。再スキャン、ビルド、テストの実行結果こそが証拠になります。エージェントにバックログの修正を任せる場合も、同じ検証を徹底してください。

• 脆弱性とビルドを合わせて評価しましょう。どちらか一方だけでは失敗を見逃します。ビルドの成否だけを確認すると、修正が行われていない問題を見逃し、脆弱性だけを確認すると、プロジェクトを壊す修正を見逃します。

• エージェントにセキュリティデータを提供しましょう。同じモデルを使った汎用エージェントでも、Snykのスキャン結果と推奨アップグレードによって、スコアが17.9ポイント向上しました。

Evo Remediation AgentはSnykのエージェント型修復エンジンで、Snyk CLI経由またはクラウドサービスとして利用できます。本日ローンチするEvo Agentic AppSecを構成するエージェントの1つです。

VulnBumpでエージェントをテストする

VulnBumpのハーネスと43件すべての評価ケースは、github.com/snyk-labs/snyk-vulnbumpでオープンソースとして公開されています。

評価方法の全容、失敗の分析、制約については、研究論文をご覧ください。独自の修復エージェントを開発している方は、VulnBumpでテストし、結果をぜひお聞かせください。

VulnBump はGabija Pasiunaite、Ryan McMorrow、Brian Clark、Liran Tal、Luke Tuによって開発されました。