VulnBump：AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるか？
2026年10月15日
0 分で読めますAIエージェントは、ビルドを壊さずに脆弱な依存関係を修正できるのでしょうか？修正そのものが謎であることはほとんどありません。2026年の6か月間に、Snyk Open Sourceは約30万の組織で4億5,900万件の脆弱性を検出しました。これらの脆弱性の94%には既知の修正版があったにもかかわらず、修正されていたのは約10%にすぎません。
その理由は、安全にアップグレードすることが難しいからです。脆弱なパッケージの多くは間接的に取り込まれており、修正の約4分の1にはメジャーバージョンへのアップグレードが必要です。また、後方互換性があるはずのマイナーリリースやパッチリリースでさえ、しばしば破壊的変更を含みます。
VulnBumpは、Snykが発表した新たな調査で、実際の脆弱な依存関係のアップグレード307件を対象にAIエージェントを評価します。脆弱性がなくなり、プロジェクトのインストール、ビルド、テストがすべて成功した場合にのみ、アップグレードは合格と判定されます。
新しい点：私たちの知る限り、VulnBumpはセキュリティ上の必要性から行うアップグレードを中心に設計された、AIエージェント向け初のベンチマークです。6つのパッケージマネージャーを対象に、すべてのタスクは実際のプロジェクトでSnykが検出した脆弱性から始まります。従来のアップグレードベンチマークは、ビルドの破損だけを確認し、脆弱性が解消されたかどうかは検証しません。
では、AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるのでしょうか？おおむね可能ですが、結果を決めるのはモデルだけではありません。同じモデルClaude Sonnet 5.5を使った場合、SnykのEvo Remediation Agentはアップグレードの90.2%に合格しました。AnthropicのClaude Codeは、Snyk推奨のアップグレードとスキャン結果を与えた場合（Claude Code + Snykスキャン）に77.5%、Snykのデータを与えなかった場合（Claude Code単独）に59.6%でした。差は30ポイントを超えます。参考までに、AIを使わずSnyk推奨バージョンを適用するだけのベースラインであるパッケージマネージャーによるアップグレードでも、すでに46.9%が合格しています。
VulnBumpの主な結果
ビルドを成功させ続けることは難題ではありませんでした。3つのエージェントはいずれも約93%の割合で達成しました。難しかったのは脆弱性の除去です。Claude Code単独では、124件の失敗のうち70件で、修正したと報告した脆弱性が再スキャンで検出されました。
今回の結果は、6月に発表したAIセキュリティレビューのベンチマークVulnBenchとも一致しています。同調査ではClaudeとSnyk Codeが異なる脆弱性を見落とすことが分かり、両者を組み合わせるのが最も効果的だと結論付けました。VulnBumpは別のタスク、つまり脆弱なオープンソース依存関係のアップグレードを検証しますが、同じ傾向を示しています。Snykの推奨バージョンとスキャン結果を与えると、Claude Codeの合格率は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つ適用します。対象のパッケージを、脆弱性が修正されるバージョンに更新するタスクです。各タスクはプロジェクトの新しいコピーから開始し、個別に評価します。43のリポジトリから307件のタスクが生まれ、Maven、Gradle、npm、Yarn、pip、Poetryの6つのパッケージマネージャーにまたがる、修正可能な脆弱性2,066件を網羅しました。これら6つは、本番環境で検出される脆弱性の約92%を占めます。
エージェントを信用しない検証器を追加しました。エージェントの作業完了後、変更をクリーンなコンテナにコピーして最初から検証しました。次の4つのゲートをすべて通過した場合にのみ、試行を合格と判定します。
依存関係のインストールが、CIで実行されるコマンドで成功すること。
Snykで再スキャンし、脆弱性がなくなったことを確認すること。
プロジェクトのビルドが成功すること。
変更前に合格したすべてのテストが、引き続き合格すること。
VulnBumpのパイプライン
検証したハーネス。3つのエージェントすべてをClaude Sonnet 5.5で実行し、アップグレードごとに最大110ターン、各言語で同じコンテナを使用しました。
Evo Remediation Agentは、Snykのエージェント型修正エンジンです。Snykのインテリジェンスを活用し、自らスキャン、ビルド、テストを実行して、完了前にエラーを修正できます。自動承認モードで実行したため、ビルドを壊す可能性が高いとSnykが評価したアップグレードも含め、すべての修正を適用しました。
Claude Code + Snykスキャンは、Anthropicの汎用コーディングエージェントにSnykのアップグレード推奨情報を与えたものです。アップグレード対象のパッケージ、更新先のバージョン、修正される脆弱性を伝えます。作業を確認するために、自らSnyk Open Sourceのスキャンを実行することもできます。
Claude Code単独には、更新先のバージョンやSnykへのアクセスを与えず、同じタスクを与えます。たとえばウェブ上の脆弱性データベースを検索するなどして、どのバージョンなら脆弱性が修正されるかを自力で判断する必要があります。
パッケージマネージャーによるアップグレードは、エージェントを使わないベースラインです。プロジェクト固有のパッケージマネージャーでSnyk推奨バージョンを適用し、それ以外は何も変更しません。
リポジトリの選定方法、各エージェントが使える正確なプロンプトとツール、データ漏洩対策の詳細は、研究論文「VulnBump: A Benchmark for Fixing Vulnerable Dependencies in Real Projects While Keeping the Build and Tests Green」に記載しています。限界についても説明しています。検証したモデルは1つ、各アップグレードの実行は1回で、判定にはSnyk Open Sourceを使いました。この判定方法がClaude Code単独に不利になりうるのは、他の2つのエージェントが同じSnykの検出結果に基づいて動作するためです。また、アップグレードによって新たに持ち込まれる脆弱性は減点対象にしていません。
結果1：同じモデルでも、結果は3通り
Evo Remediation Agentはアップグレードの90.2%ですべてのゲートに合格し、2,066件の脆弱性の95.9%を修正しました。これはClaude Code + Snykスキャンを12.7ポイント上回り、アップグレード8件につき約1件多く修正に成功した計算です。Claude Code単独との差は30.6ポイントでした。
順位は、規模の大きなリポジトリが数件あるかどうかだけで決まるわけではありません。リポジトリごとの合格率を平均すると、Evo Remediation Agentは93.1%、Claude Code + Snykスキャンは80.1%、Claude Code単独は68.0%、パッケージマネージャーによるアップグレードは51.3%でした。
重要なポイント:
Evo Remediation Agentは、脆弱性対応に伴うアップグレードの10件中9件をエンドツーエンドで修正します。
結果2：どのバージョンが本当に安全かを知る必要がある
同じモデルでClaude CodeにSnykのスキャン結果と推奨アップグレードを与えると、合格率は59.6%から77.5%へ17.9ポイント上昇しました。
最も明確な違いは、選ぶバージョンです。情報を与えない場合、Claude CodeはSnykが依然として脆弱だと判定するバージョンを64回選びました。Snykのスキャン結果を与えると、その数は13回に減りました。脆弱性データベース間で修正済みとされるバージョンが一致するとは限りません。ある情報源では安全に見えるバージョンも、別の情報源では脆弱性があると判定されることがあります。
Snykのガイダンスが特に役立つのは、プロジェクトが直接宣言していないパッケージの間接依存に潜む脆弱性です。すべてのゲートに合格したアップグレードだけを数えると、Claude Codeが修正した間接依存の割合は28%から59%へと2倍以上になりました。
主な調査結果：
Snykのスキャンと推奨バージョンにより、Claude CodeのPASS率は17.9ポイント向上し、修正された推移的依存関係の脆弱性は2倍以上になりました。
結果3：Snykの推奨だけで約半数を解決でき、残りでエージェントの差が表れる
パッケージマネージャーによるアップグレードでは、307件のアップグレードは2つに分かれます。合格した144件は、Snykの推奨バージョンを適用するだけで十分です。エージェントは簡単な修正を維持するか、失敗させるかしかありません。残る163件は、破壊的変更へのコード対応や依存関係の競合解決など、単なるバージョン更新以上の対応が必要です。
Snykの推奨だけで解決できた144件と、残る163件に対するエージェントの結果
Snykのガイダンスがあれば、エージェントが単純な更新で解決できる問題を壊すことはほとんどありません。一方、Claude Code単独は144件中20件で後退し、そのうち15件ではSnykが依然として脆弱と判定するバージョンを選びました。真の違いが表れるのは難しい半数です。残る163件のアップグレードでは、Evo Remediation Agentの合格率は82.2%、Claude Code + Snykスキャンは61.3%、Claude Code単独は36.2%でした。
重要な調査結果：
バージョンの更新だけでは不十分な163件のアップグレードのうち、Evo Remediation Agentの成功率は82.2%でした。Claude CodeとSnykスキャンの組み合わせは61.3%、Claude Code単独では36.2%でした。
結果4：ビルドが成功していても、脆弱性が残っていることがある
ビルドを成功させる最も簡単な方法は、脆弱性を残したままにすることです。Claude Codeの失敗の大半は、このパターンでした。失敗したゲートが最初に再スキャンだったのは、Claude Code単独の失敗124件中107件、Claude Code + Snykスキャンの失敗69件中48件でした。Evo Remediation Agentでは、失敗30件中9件でした。
失敗した試行ごとに、最初に失敗した検証ゲート
Evo Remediation Agentの失敗は目に見える形で起こります（それは悪いことではありません）。失敗30件中21件でビルドまたはテストが失敗しました。その多くは、他のエージェントが避けることの多かったメジャーアップグレードでした。分かりやすい失敗は、気づかれない失敗よりはるかに安全です。アップグレードに問題が起きても、プロジェクト自身のビルドやテストに表れるため、開発者が把握し、最終的に対処できます。
主な発見：
汎用エージェントは問題を検知できずに失敗しますが、Evo Remediation AgentはCIで検出される箇所で失敗します。
結果5：更新先のバージョンを知っているだけでは不十分
SnykのスキャンによってClaude Codeは大きく前進しますが、アップグレードを正しく行うにはそれ以上のことが必要です。同じ検出結果と更新先のバージョンを与えた場合でも、Evo Remediation AgentはClaude Code + Snykスキャンより39件多くアップグレードに合格し、そのうち23件はメジャーアップグレードでした。
Evo Remediation Agentは、Snykのインテリジェンスに加えて、完了前にプロジェクトをビルド、テストし、問題を修正する反復ループを備えています。今回の設定では、どの要素が差を生んだかを切り分けることはできません。しかし、モデルを取り巻くシステムが結果に大きく影響することを示しています。これは、ハーネスだけを変えることで結果が最大16.3ポイント変わったDepBenchの結果とも一致します。
重要な発見：
同じモデル、同じSnykの検出結果でも、Evo Remediation Agentのスコアは12.7ポイント高いままです。
結果6：メジャーアップグレードと間接依存は依然として最難関
すべてのエージェントが、メジャーなフレームワーク移行には苦戦します。主にSpring、Spring Boot、Dropwizardの移行である23件のアップグレードは、3つのエージェントすべてが失敗しました。
メジャーアップグレードの合格率は、非メジャーアップグレードと比べて、Evo Remediation Agentが96%から81%に、Claude Code + Snykスキャンが88%から61%に、Claude Code単独が70%から42%にそれぞれ低下しました。メジャーアップグレードではコードの変更も必要です。Evo Remediation Agentが合格したメジャーアップグレードの約半数でアプリケーションのソースコードを編集したのに対し、非メジャーアップグレードでは5%でした。
バージョンの変更幅別に見た、すべてのゲートに合格したアップグレード
脆弱なパッケージがマニフェストに直接宣言されていない間接依存は、修正可能な脆弱性の70%を占め、検証したすべてのハーネスでより難しい課題でした。すべてのゲートに合格した試行の修正だけを数えると、Evo Remediation Agentは間接依存の73%、Claude Code + Snykスキャンは59%、Claude Code単独は28%を修正しました。直接依存では、それぞれ91%、71%、62%でした。
依存関係の種類（直接・間接）別の合格率
重要な調査結果：
Evo Remediation Agentは、最も難しいアップグレードやメジャーバージョンへの更新、推移的依存関係の修正で優れた成果を上げていますが、主要なフレームワークの移行は依然としてどのエージェントにも難しい課題です。
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が開発しました。
調査
