Snyk VulnBench JS 1.0：LLMは同じバグを2回見つけられるか？

同じコード、プロンプト、ハーネスを使ったエージェント型LLMのセキュリティレビューがどの程度再現可能かを測るため、脆弱性検出スキャンを300回実施しました。最大のポイントは、自己参照型のリーダーボードでどのスキャナーが「勝つ」かではありません。LLMのセキュリティ検出結果は一様に再現されるわけではなく、参照セットに一致する検出結果は安定していた一方、モデル独自の追加レポートは実行ごとに大きく変動しました。

簡単に言うと、ClaudeがSnyk Codeの参照リストにないバグを報告した場合、その追加レポートは一貫しないことが少なくありませんでした。250回のモデル実行で、固有の不一致検出結果161件のうち80件は同一条件での5回の反復のうち1回だけで報告され、5回すべてで報告されたのはわずか22件でした。一方、Claudeが参照セットの検出結果と一致した場合、その挙動ははるかに安定していました。固有の参照一致検出結果158件のうち134件が、5回すべての反復で報告されました。この違いがSnyk VulnBench JS 1.0の核心的な結果です。

このベンチマークは、相互補完性も示しています。モデルはよく知られた、シグナルの強いエクスプロイトパターンを一貫して特定し、あるケースではSnyk Codeで見落とされている可能性の高い検出箇所を明らかにしました。Snyk Code SASTは決定論的で、繰り返し現れるデータフローのシンクを体系的に列挙する能力に優れ、脆弱性スキャンの実行時間も大幅に短縮できました。いずれの結果も、片方の手法をもう片方に置き換える根拠にはなりません。データが示すのは、両者を組み合わせることです。

主なポイント：

• 再現率が最も高いLLM構成でも、Snyk Codeの参照脆弱性を検出できたのはわずか81%でした。

• 最も高いスコアを記録したLLM構成のSnyk参照F1は75.4%で、決定論的なSASTによる参照結果の再現との間には24.6ポイントの差がありました。

• LLMのみが報告した脆弱性のほぼ50%は、同一条件の5回のスキャンのうち1回だけで報告されました。

• 再現率が最も高いLLMは、ノイズも最も多い結果となりました。レポートの41%がSnyk Codeの参照セットに含まれていませんでした。

• アプリに近い最大規模のテストケースでは、最も優れたモデルのSnyk参照F1はわずか40.0%で、パストラバーサルとリソース制限の脆弱性を繰り返し見落としました。

LLMによるセキュリティレビューに再現性が必要な理由

コーディングエージェントは、今や開発サイクルの一部です。コードの作成やプルリクエストの変更、変更内容の説明を行い、人が差分を読む前にコードやアプリケーションのセキュリティレビューを実施する用途も増えています。つまり、信頼性はプロダクト上の重要な問いです。同じエージェントが同じ脆弱なコードを2回確認したとき、同じセキュリティ問題を2回とも報告するでしょうか？

従来のSASTツールは、決定論的に動作するよう設計されています。コードとルールが同じなら、出力も同じであるべきです。LLMは異なります。未知のコードについて推論し、リスクをわかりやすい文章で説明し、静的解析ツールが見逃す問題を見つけることもあります。一方で、実行ごとに結果が変わったり、周辺の問題まで過剰に報告したり、繰り返し現れるパターンの代表例を1つ見つけたところで止まったりすることもあります。

Snyk VulnBench JS 1.0は、こうした挙動を定量化するために設計されました。このベンチマークでは小規模なJavaScriptおよびExpressアプリケーションを使用するため、各実行結果を確認できます。目的は、モノレポ全体をシミュレートすることではありません。反復可能で統制された条件下で、モデルの挙動を測定可能にすることです。

ベンチマークの設計：セキュリティスキャンを300回反復

このベンチマークには、Snyk Codeの参照検出結果が44件含まれるJavaScriptのテストプロジェクトが10件あります。各テストケースはExpressベースの小規模アプリケーションで、簡潔な単一ファイルのコードから、サーバールート、データベースの状態、アップロード、フロントエンドJavaScriptを備えた大規模なToDoアプリまで幅があります。

6つの構成を評価しました。

各構成で各タスクを5回実行しました：10タスク × 6構成 × 5回の反復 = 300回の実行。モデル構成では同一の直接監査プロンプトを使用し、検出結果を構造化JSONで返しました。モデルはプロジェクトファイルを読み取れますが、参照ファイルのfindings.jsonは読み取れません。

このベンチマークの参照セットはSnyk Codeが定義します。そのため、Snyk Codeのスコアが100%であることは、プロジェクト内で考えられるすべての脆弱性に対する精度を主張するものではありません。繰り返し実行した際に、Snyk Codeが独自の参照検出結果を決定論的に再現したという意味です。この参照セットを使って、モデルとの一致度、モデルのばらつき、モデルの挙動との相違を測定します。

スコアリングは意図的に寛容にしています。参照検出結果と同じ種類の脆弱性を報告すれば、モデルの検出結果としてカウントされます。同じファイル、行、重大度、ソースからシンクまでのパスに一致する必要はありません。Snyk参照F1として、Snyk Codeの検出結果を参照セットとした場合の適合率と再現率の調和平均を報告します。一致度の指標としては有用ですが、最も重要な結果ではありません。

このベンチマークでは、独立した網羅的な判定済みの正解セットを使用していないため、Snyk参照F1を真の脆弱性検出精度と解釈すべきではありません。Snyk Codeの参照セットとの一致度が低いモデルでも、不一致の検出結果が有効であったり、参照セットが過大評価する問題を避けたりしていれば、独立した正解セットではより高いスコアを得る可能性があります。このレポートでSnyk参照F1が答えるのは、より限定的な問いです。モデルの検出結果は、Snyk Codeの参照検出結果とどの程度一致し、どの程度再現されるのか？

結果1：LLMの再現性はモデル構成によって異なる

構成ごとに見ると、再現性はスコアとばらつきの関係に表れます。右上ではなく左上に近いほど、参照セットとの一致度が高く、反復実行時のばらつきが小さい、より良い結果です。Snyk Code SASTは、参照セットを決定論的に再現したため、Snyk参照F1が100.0%、標準偏差が0.0ポイントで、この領域に位置します。Claudeの各モデル構成は右下方向に広がり、Claude Sonnet 4.6 Highが3.5ポイントと、見出し指標のばらつきが最も大きくなりました。

図1：Snyk参照F1と、見出し指標であるSnyk参照F1の標準偏差。左上に近いほど、参照との一致度が高く、反復実行時のばらつきが小さいことを示します。Snyk Code SASTは、ばらつきゼロの紫色で表示しています。

この散布図から、2つの点が同時にわかります。まず、このベンチマークでのSnyk Codeの役割は、確率的なレビューではなく、決定論的な参照結果の再現です。次に、モデル構成の結果はコストや新しさの順には並びません。Claude Opus 4.6 MediumとHighは近い位置にあり、ばらつきが小さく、モデルのF1が最も高い一方、Claude Opus 4.7 MaxとClaude Sonnet 4.6 Highはより右側に位置し、反復実行時の変動が大きいことを示しています。

すべてのモデル構成を通じて、固有の不一致検出シグネチャ161件のうち80件は、反復実行5回のうち1回だけで出現しました。これが全体としてのばらつきの一因ですが、モデルごとの内訳を見ると、さらに有用な傾向がわかります。

図2：各モデル構成で、固有の不一致検出シグネチャのうち、反復実行5回中1回だけに出現した割合。シグネチャ = タスク + 脆弱性の種類 + ファイル + 行。モデル構成ごとに集計。

以下の表には、前のグラフの正確な値に加え、特に重要な2つの安定性指標を示しています。

モデル間で不安定さに偏りがあります。Claude Sonnet 4.6 Mediumは不一致シグネチャが60件と最も多く、そのうち37件は5回中1回だけで出現しました。Claude Sonnet 4.6 HighとClaude Opus 4.7 Maxも同様の傾向を示し、多くの追加レポートが一度だけ出現し、再度報告されませんでした。対照的に、グラフで0.0%を示すClaude Opus 4.6 Mediumは、安定性が高く、一度だけの検出結果が少ないことを表しています。追加レポートはすべて2回以上で検出されましたが、反復5回中1回だけのものはありませんでした。

Opus 4.6の構成は異なる挙動を示しました。不一致検出結果がはるかに少なく、追加レポートもより安定していました。すべての追加レポートが正しいという意味ではありませんが、運用上の捉え方は変わります。予想外の検出が減り、一度きりの指摘が減り、トリアージの負荷も軽減されます。

以下のグラフは、Opus 4.6以外のほとんどの構成で、反復実行時に追加の（不一致）検出結果が不安定だったことを示しています。Claude Sonnet 4.6 MediumとHighはいずれも再現性が低く、5回すべてで継続して検出された不一致結果は、それぞれわずか8.3%と9.3%でした。Claude Opus 4.7 Maxも安定性は低く、わずか16.7%でした。対照的に、Opus 4.6 MediumとHighは不一致検出結果の安定性がはるかに高く、それぞれ60.0%と50.0%でした。これは、Sonnetと新しいClaude Opus 4.7 Max構成による不一致検出結果が、より予測しにくくノイズが多いことを示しています。

図3：各モデル構成で、固有の不一致検出シグネチャが反復実行5回すべてに出現した割合。

参照と一致する側では、異なる結果が見られます。モデルがSnyk Codeの参照検出結果を見つけた場合、その検出結果はたいてい繰り返し報告されました。Claude Opus 4.6 Mediumは固有の参照検出結果25件と一致し、その25件すべてが5回の実行で再現されました。Claude Opus 4.6 Highは26件中25件を再現しました。ノイズの多いSonnet構成でも、参照と一致した36件中29件が繰り返し検出されました。

図4：各モデル構成で、固有のSnyk Code参照検出結果が反復実行5回すべてで検出された割合。

図4は、再現性のうち参照と一致した側を示しています。すべてのモデル構成を通じて、固有の参照一致検出結果158件のうち134件が、5回すべての反復で出現しました（84.8%）。つまり、モデルが既知のSnyk Code参照検出結果に気づいた場合、通常は安定して検出しました。図5との対比が主要な結果です。真陽性は概ね安定していた一方、参照セットにない追加レポートははるかに不安定でした。

図5：同じタスクとモデル構成で5回反復した際に、同じ検出シグネチャが出現した頻度別に見た、モデルによる固有の不一致検出結果の分布。シグネチャ = タスク + 構成 + 脆弱性の種類 + ファイル + 行。

モデルによる固有の不一致検出結果のほぼ半数は、条件が同一の5回の反復のうち1回だけで出現しました。これは実務上の信頼性の問題です。どの実行が行われたかによって、開発者が受け取るレビュー結果が大きく異なる可能性があります。

グラフの元になった正確な分布は次のとおりです。

結果2：LLMエージェントとSASTは異なるセキュリティ上の見落としを検出

最も有用な捉え方は「LLM対SAST」ではありません。「LLMとSASTを組み合わせることで、異なる種類の見落としを検出できる」です。

これを最も明確に確認できるのは、脆弱性の種類ごとの比較です。以下のヒートマップは、脆弱性の種類と構成ごとに、Snyk Codeの参照セットに対する平均再現率を示しています。Snyk Codeは参照セットを定義し再現するため、100%と表示されています。モデルの行からは、エージェント型レビューが参照セットと一致する点、またどこで見落とすかがわかります。

図6：脆弱性の種類と構成ごとに見た、Snyk Codeの参照セットに対する平均再現率。Snyk Codeは決定論的な参照結果の再現として表示し、モデルの行は脆弱性の種類ごとにエージェント型レビューが一致する点と見落とす点を示します。

モデル構成が最も得意としていたのは、よく知られた、明確な兆候のある攻撃パターンです。コマンドインジェクション、コードインジェクション、ハードコードされた認証情報、SQLインジェクション、SSRF、オープンリダイレクト、プロトタイプ汚染、ReDoSは、多くの場合、正確に検出されました。一方、リソース制限に関する問題、不適切なサニタイズ、型検証、安全でない通信、フレームワークに関する情報漏えい、繰り返し発生するパストラバーサルのフローは苦手でした。

この傾向はjs-project-tigerteamに表れています。すべてのモデル構成で、25回のモデル実行すべてにわたり、ハードコードされたデータベースパスワード、反射型XSS、パストラバーサル、コマンドインジェクションが一貫して検出されました。

1app.get("/greet", (req, res) => {
2  const name = req.query.name;
3  res.send(`<html><body><h1>Hello, ${name}!</h1></body></html>`);
4});
5
6app.get("/file", (req, res) => {
7  const filename = req.query.filename;
8  const basePath = "/var/app/public/";
9  fs.readFile(basePath + filename, "utf8", (err, data) => {
10    if (err) return res.status(404).send("Not found");
11    res.send(data);
12  });
13});
14
15app.get("/ping", (req, res) => {
16  const host = req.query.host;
17  exec("ping -c 1 " + host, (err, stdout, stderr) => {
18    if (err) return res.status(500).send("Error");
19    res.send(`<pre>${stdout}</pre>`);
20  });
21});

しかし、同じフィクスチャには、SQLに似たモックヘルパーが含まれていました。

1function dbQuery(sql) {
2  console.log("Query:", sql);
3  return [];
4}
5
6app.get("/users", (req, res) => {
7  const username = req.query.username;
8  const sql = "SELECT * FROM users WHERE username = '" + username + "'";
9  const results = dbQuery(sql);
10  res.json(results);
11});

モデルはjs-project-tigerteamの25回の実行すべてでSQLインジェクションを報告しました。このフィクスチャでは、報告しなかったSnyk Codeの判断が正解でした。dbQuery()は文字列をログに記録して空の配列を返すだけで、実行可能なSQLのシンクはありません。これは、LLMが脆弱性に見えるコードを、悪用可能な脆弱性と誤認することがある例です。

js-project-nightowlからは、逆の教訓が得られました。25回すべてのモデル実行で、Snyk Codeの参照セットにはないSQLインジェクションが報告されており、今回はモデルの検出が有用である可能性が高いと考えられます。

1deleteTodo: (id) => db.prepare("DELETE FROM todos WHERE id = " + id).all(),

この検出結果はSnyk Codeの参照セットに含まれていなかったため、一致しない結果として集計されました。幻覚として片付けるべきではありません。調査すべき実際の製品上のギャップである可能性が高いものです。このケースを明らかにしたことで、ベンチマークの価値は高まりました。検出機能を強化するため、こうした知見を社内に取り入れています。

図7：脆弱性の種類とモデル構成別に見た、モデル1回あたりの平均不一致レポート数。モデルの誤検知、関連するレビューコメント、Snyk Codeの参照セットに含まれない製品上のギャップ候補が含まれます。

この2つ目のヒートマップは、補完性のもう一面を示しています。モデルによる追加レポートは、ひとくくりにできるものではありません。js-project-tigerteamの実行不能なSQL風モックヘルパーのように、誤検知の可能性が高いものもあります。参照セットの対象外となる、関連するセキュリティレビューコメントもあります。また、js-project-nightowlのSQLインジェクションの報告のように、有効な検出結果であり、Snyk Codeのカバレッジに反映すべきものもあります。

補完性は逆方向にもあります。js-project-nightowlは、JS 1.0で最も実際のアプリケーションに近いフィクスチャです。server.jsは198行で、db.jsとpublic/app.jsを合わせると、JavaScriptはさらに183行あります。ルーティング、アップロード、添付ファイルの削除、ダウンロード、データベース状態を含みます。Claude Opus 4.6 Highはこのフィクスチャで非常に安定していましたが、Snyk参照F1スコアはわずか40.0%でした。5回の反復実行を通じて、パストラバーサルに関する参照セットの検出結果をすべて見逃し、リソース制限に関する検出機会3件のうち2件も見逃しました。

図8：複数ファイルからなる大規模フィクスチャのベンチマークスコアの平均値。エラーバーは、反復実行における標準偏差を示します。

見逃しは、繰り返し発生する添付ファイルの処理フローに及んでいました。

1if (req.file) {
2  if (existing.attachment_stored_name) {
3    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
4  }
5  updates.push("attachment_original_name = ?", "attachment_stored_name = ?");
6  values.push(req.file.originalname, req.file.filename);
7} else if (req.body.removeAttachment === true || req.body.removeAttachment === "true") {
8  if (existing.attachment_stored_name) {
9    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
10  }
11}

モデルは代表的な問題をいくつか検出した後、繰り返し現れる脆弱なシンクを網羅的に列挙できませんでした。まさにこのようなケースで、決定論的なデータフロー解析が役立ちます。SASTのカバレッジとモデルによるレビューは重複するものではなく、それぞれ異なる盲点を持つ別の手段です。

結果3：LLMの実行コストが高くても、カバレッジが向上するとは限らない

今回の実行で最も高コストだったモデル構成はClaude Opus 4.7 Maxですが、最も高い性能を示したわけではありません。モデルセッションあたりの平均トークン数は95,969、コストは0.3559ドルでした。一方、Claude Opus 4.6 Mediumは、モデルセッションあたり平均51,574トークン、コストは0.0628ドルでした。つまりOpus 4.7 Maxは5.67倍のコストと1.86倍のトークンを要しながら、スコアは低く、Snyk参照F1スコアは68.8%でした。Opus 4.6 Mediumは75.4%です。

図9：モデル単体でのコストと品質のトレードオフ。左上に近いほど、推定モデルセッションコストが低く、Snyk参照F1スコアが高いことを示します。

フィクスチャが小さいため、金額自体はわずかです。しかし、規模を拡大した場合の問題は小さくありません。実際のセキュリティチェックは、これらのコードスニペットより桁違いに大きなリポジトリで、コーディングエージェントのセッション、コミット、プルリクエスト、CIジョブのたびに実行されます。推論コストが高くても、セキュリティカバレッジが自動的に向上するわけではありません。

Snyk Code参照セットとの一致スコア

Snyk参照F1スコアは、意味を正確に説明する限り有用です。この指標が測定するのは、Snyk Code参照セットとの一致度です。この指標では、Snyk Code SASTは参照セットを再現し、Snyk参照F1スコア100.0%、スコアの標準偏差0.0パーセントポイントを達成しました。最も高いスコアを示したモデル構成はClaude Opus 4.6 Mediumで、Snyk参照F1スコア75.4%、再現率68.0%、適合率91.5%でした。

この表を「SnykがSnykの精度を100%と証明した」と解釈すべきではありません。Snyk Codeが決定論的な参照セットを生成し、モデルはその一部と一致したこと、そしてその差異から再現性、コスト、カバレッジのトレードオフを測定できることを示しています。

このベンチマークがLLMによるセキュリティレビューに意味すること

参照セットはSnyk Codeに基づいています。透明性が高く再現可能である一方、普遍的な正解として扱えば循環論法になります。このレポートは、そのような主張を避けています。ベンチマークでは、モデルとSnyk Codeの検出結果の一致度を測定し、差異を用いて再現性と補完性を検証します。

スコア判定は寛容です。ファイル、行、深刻度、ソースからシンクへの識別情報が完全に一致するかではなく、脆弱性の種類で照合します。より厳密な判定では、モデルの一致スコアは低くなり、重複するフローに関する誤りもさらに明らかになるでしょう。

フィクスチャは、小規模なJavaScriptおよびExpressアプリケーションです。管理された条件下での測定には有用ですが、大規模なモノレポ、フレームワークを多用するTypeScriptアプリケーション、マルチサービスアーキテクチャ、ビジネスロジックに関する脆弱性は対象としていません。js-project-nightowlはすでに、アプリケーションに近い構造がモデルの挙動を変えることを示しています。

再発分析では、正規化した検出結果のシグネチャを使用しています。モデル別の不一致チャートでは、各モデル構成ごとに、タスク＋脆弱性の種類＋ファイル＋行をシグネチャとしてグループ化しています。正規化の方法が異なれば正確な割合も変わるため、シグネチャはチャートの引き継ぎ資料と再現性に関する注記に記載しています。

次の展開：より幅広いフィクスチャとLLM＋SASTの統合ワークフロー

次回のSnyk VulnBenchでは、小規模な自己完結型のコードスニペットにとどまらない内容を目指します。より実際のアプリケーションに近い構成、LLM由来の脆弱性、ビジネスロジック、BOLAの分類を追加し、BaxBench形式の参照データのような独立した正解データを採用する予定です。

ベンチマークの評価トラックも分けるべきです。一方のトラックでは、引き続きSnyk Codeとの一致度を測定し、決定論的なSASTを参照してモデルの挙動を比較できます。もう一方では、独立して外部から検証できる正解データを用い、主要な結果がSnyk独自の検出結果に左右されないようにします。

最後に、今後のレポートでは、モデル単体のレビュー、SAST単体の解析、SASTのコンテキストを加えたLLMレビューなど、統合ワークフローを評価すべきです。JS 1.0のデータは、すでにその方向性を示しています。モデルとSASTは同じ形で失敗するわけではありません。だからこそ、両者を組み合わせるのです。