同じcodeとpromptでも、security reviewの結果は揺れる。 Snykが2026年6月29日に公開したVulnBench JS 1.0は、agentic LLM security reviewが同じ脆弱性を繰り返し見つけられるかを測定した。焦点は単純な順位ではない。coding agentやCIに入るレビュー結果が、実行のたびにどれだけ安定しているかだ。

ベンチマークは10個のJavaScript / Express fixture projectと、44個のSnyk Code reference findingで構成された。評価対象はSnyk Code SASTと、Claude Opus 4.6 Medium、Opus 4.6 High、Opus 4.7 Max、Sonnet 4.6 Medium、Sonnet 4.6 Highの各configurationだ。各configurationが各taskを5回実行し、合計は10 tasks x 6 configurations x 5 repetitions、つまり300 runsとなる。モデルはproject filesを読めるが、reference fileは見られない。

最良のLLM configurationはClaude Opus 4.6 Mediumで、Snyk-reference F1 75.4%、recall 68.0%、precision 91.5%だった。同じ表でSnyk Code SASTは、自身のreference setに対して100.0% F1と0.0 percentage-point standard deviationを示した。Snykはこの数字を「全脆弱性を100%検出した」という意味ではなく、agreementとvarianceを測るためのdeterministic baselineとして説明している。

再現性の差はunmatched model findingで目立った。全model configurationsを合わせると、unique unmatched finding signatures 161件のうち80件、つまり49.7%が5回中1回だけ現れた。一方でreference-matched findingは、158件中134件が5回すべてで繰り返し報告された。既知の脆弱性形状に一致する場合は比較的安定するが、モデルだけが追加で出す報告はかなり不安定になる。

コストと性能も単純には対応しない。Claude Opus 4.7 Maxは平均95,969 tokens、$0.3559 per sessionを使ったが、Snyk-reference F1は68.8%だった。Claude Opus 4.6 Mediumは平均51,574 tokens、$0.0628 per sessionで75.4%を出した。fixtureが小さいため金額は小さく見えるが、pull requestやCIで反復実行されると、費用とtriage負荷は無視できない。

結論はLLMかSASTかの二択ではない。モデルはcommand injection、hardcoded credentials、SQL injection、SSRF、open redirect、prototype pollution、ReDoSのような見慣れたexploit shapeに強かった。一方で、repeated path traversal flows、resource-limit findings、improper sanitization、type validation、insecure transport、framework information exposureではsystematicなdata-flow analysisが効く。次に見るべきなのは、より大きいapplication fixture、独立したground truth、そしてLLM+SASTを組み合わせたworkflowである。

#snyk

Snykの300回反復テスト、LLMセキュリティレビューの揺れを可視化