Snyk VulnBench JS 1.0은 같은 JavaScript/Express 코드, 같은 프롬프트, 같은 하네스에서 LLM 보안 리뷰를 반복 실행했을 때 취약점 결과가 얼마나 안정적으로 재현되는지 측정한 벤치마크다. 핵심 결론은 LLM과 SAST 중 하나가 이긴다는 이야기가 아니라, 두 방식이 서로 다른 실패 모드를 가진다는 점이다.

벤치마크 설계

벤치마크는 10개의 작은 JavaScript fixture 프로젝트와 44개의 Snyk Code 기준 취약점으로 구성된다. 여섯 설정을 각 태스크에 5회씩 실행해 총 300회 스캔을 만들었다.

모델은 프로젝트 파일을 읽을 수 있지만 reference findings 파일은 볼 수 없다. 점수는 Snyk Code reference set과의 일치도를 기준으로 한 Snyk-reference F1이다. 이 점수는 독립적인 완전 정답률이 아니라, Snyk Code 기준 결과를 얼마나 반복적으로 재현하는지 보는 좁은 지표다.

주요 결과

• 최고 recall LLM 설정도 Snyk Code 기준 취약점의 81%만 찾았다.
• 최고 점수 LLM 설정의 Snyk-reference F1은 75.4%로, deterministic SAST 기준 재현과 24.6포인트 차이가 났다.
• LLM-only 취약점 보고의 거의 절반은 동일 조건 5회 중 1회만 등장했다.
• 기준 취약점과 매칭된 LLM 결과는 훨씬 안정적이었다. reference-matched findings 중 85%가 5회 모두 반복됐다.
• LLM은 command injection, SQL injection, SSRF, hardcoded credentials, prototype pollution처럼 신호가 큰 패턴에 강했고, repeated path traversal, resource limit, framework information exposure, sanitization/type validation 같은 체계적 열거에는 약했다.

해석

LLM 보안 리뷰의 강점은 낯선 코드에서 의미를 추론하고, SAST 규칙이 놓친 가능성을 설명하는 데 있다. 반대로 SAST는 같은 규칙·같은 코드에서 같은 결과를 내는 결정성이 강하다. VulnBench 결과는 “LLM을 SAST 대신 쓴다”보다 “SAST로 deterministic baseline을 만들고 LLM으로 보완 신호를 얻는다”는 운영 모델을 지지한다.

특히 LLM-only finding은 두 부류로 나눠야 한다. 일부는 실제 취약점처럼 보이지만 실행 가능한 sink가 없는 과잉 보고다. 다른 일부는 Snyk Code reference set이 놓친 실제 gap일 수 있다. 반복 횟수와 독립 검증을 함께 봐야 triage 비용을 줄일 수 있다.

사용 대상 및 케이스

• AppSec 팀: LLM 보안 리뷰를 PR 게이트에 넣기 전 반복 가능성과 triage 비용을 측정할 때
• 에이전트 평가 팀: 보안 리뷰 에이전트가 한 번만 맞히는지, 반복 실행에서도 안정적인지 분리해 보고 싶을 때
• 개발 플랫폼 팀: SAST와 LLM 리뷰를 함께 배치하는 정책을 설계할 때

관련 문서

• cybersecurity-evals — AI 에이전트 보안 능력을 측정하는 벤치마크 설계 패턴
• ai-code-review-tips-agentic — 에이전트 시대의 코드 리뷰 병목과 위험 기반 리뷰 시스템
• agent-harness — LLM 보안 리뷰를 반복 가능한 하네스로 만드는 방법론

참고 자료

• Snyk VulnBench JS 1.0: LLM Bug Repeatability — Snyk Blog (2026-06-29)