SAST 82% vs AI 보안 에이전트 79%: 함께 써야 보이는 취약점들 — VulnBench 2.0 리뷰

원문 정보

Liran Tal, Chris Liu, Charlotte Fereday, Sebastian Roth, Brian Clark, "How Deterministic SAST and AI Security Agents Divide the Work: Coverage, Harness Policy and Cost in Snyk VulnBench 2.0", arXiv:2610.38617 [cs.CR], 2026-10-28 제출. 소속: Snyk. 벤치마크·채점기·실행 기록 전체 공개(github.com/snyk-labs/snyk-vulnbench), Apache License 2.0.

동료심사를 거치지 않은 프리프린트입니다. 저자 전원이 Snyk 소속이고 비교 대상 중 하나(Snyk Code)가 자사 제품이라는 이해상충이 명확하지만, 벤치마크 하니스·채점기·전체 실행 기록을 공개해 외부에서 재채점할 수 있게 열어 두었습니다.

연구 개요

질문은 단순합니다 — AI 코딩 에이전트가 보안 리뷰에 쓰이는 지금, 결정론적 정적분석(SAST)이 놓치는 것을 AI 에이전트가 잡아내는지, 또 그 반대인지입니다. 전작(JS 10개 앱, Snyk Code 기준 재현율만 측정)을 보완해 Go·JS/TS·Python·Java 20개 오픈소스 웹앱에 108개의 공격자 도달 가능 취약점을 직접 심었습니다(62개는 파일 경계를 넘는 흐름). 평가 대상은 팀이 실제로 쓰는 패키지화된 도구 9종 — Snyk Code CLI(SAST), Claude Code 내장 /security-review(Opus 5 xhigh·Sonnet 5 xhigh·Opus 5 medium+Snyk MCP), Codex Security(GPT-5.6 Luna/Terra/Sol), DeepSec(Opus 5·GPT-5.6 Sol 백엔드)입니다. 채점은 취약점의 유입 지점(source)과 호출 지점(sink)을 각각 2줄 이내로 짚어야 정답인 '엔드포인트 규칙'을 쓰고, 모델이 아니라 하니스+모델+버전 전체 조합에 결과를 귀속시킵니다.

핵심 결과

주 지표는 매크로 재현율(앱 20개의 재현율을 동일 가중 평균 — 앱마다 취약점 수가 2~10개로 달라 전체 비율과는 값이 약간 다릅니다)이고, '적중'은 108개 중 몇 개를 맞혔는지 보여 주는 수치입니다. 둘이 정확히 비례하지 않는 것은 저자들이 명시한 설계입니다.

*DeepSec은 source·sink 역할을 보고하지 않아 '클래스 일치 + 2줄 이내 위치 보고'라는 느슨한 기준(국소 재현율)으로 따로 채점되며, 위 7개 구성과 직접 비교할 수 없습니다.

가장 중요한 결과는 개별 순위가 아니라 합집합입니다. Snyk Code와 Opus 5 xhigh를 합치면 101/108로 7개 구성 전체를 합친 것과 같습니다 — 다른 구성은 새 취약점을 더하지 못했습니다. 둘은 28개에서 갈렸고(Snyk만 16, Opus만 12), McNemar p=0.57로 우연과 구분 못 할 만큼 샘플이 작습니다. Snyk Code는 오픈 리다이렉트·프로토타입 오염 등 6개 클래스에서 AI가 못 맞힌 10개를 혼자 잡았고, Opus 5 xhigh는 12개(7개가 파일 경계를 넘는 흐름, 권한 클래스 포함)를 혼자 잡았습니다. AI 구성들은 참고 정답에도 없던 실제 취약점 7개도 추가로 찾아 저자들이 직접 재현 확인했습니다.

하니스 정책의 영향도 뚜렷합니다. Claude Code의 /security-review는 ReDoS를 제외하고 프로토타입 오염·오픈 리다이렉트는 '극도로 높은 확신'에서만 보고하도록 프롬프트에 명시돼 있습니다. 이 3개 클래스 20개 취약점에서 Snyk Code는 18개, Opus 5 xhigh는 9개를 맞혔지만 나머지 81개에서는 비슷했습니다(Opus 71, Snyk 67) — 정책 하나가 전체 격차 대부분을 설명합니다. 이를 검증한 대조 실험(같은 모델에 /security-review 대신 일반 감사 프롬프트, 19/20개 앱, 2026-10-01)에서 정책 제거 후 정책 클래스 20개 중 16개를 맞혔습니다(정책 적용 시 9개). 전체로도 93/105 대 83/105로 올랐고 비용은 0.63배, 소요시간은 0.52배였습니다 — 모델이 아니라 정책이 격차를 만든 셈입니다.

비용과 성능이 항상 비례하지는 않았습니다. Codex Security 안에서 GPT-5.6 Sol은 Luna보다 35.0배 비용을 쓰고도 11개를 더 적게 맞혔습니다. 반대로 Claude Code 안에서는 Opus 5가 Sonnet 5보다 4.2배 비용을 쓰고 12개를 더 맞혔습니다. Codex Security의 또 다른 약점은 위치 정밀도입니다 — GPT-5.6 Sol은 파일 수준에서 108개 중 80개를 짚었지만 '2줄 이내' 기준에서는 34개만 인정받았는데, 못 맞힌 57건 중 53건은 자신이 이미 '싱크'로 지목한 위치 바로 근처(39건은 평균 6줄 위)였습니다 — 함수는 찾고 줄을 놓친 패턴입니다.

신뢰도 평가

동료심사 전 프리프린트이고, 저자 전원이 Snyk 소속이며 비교 대상 중 하나(Snyk Code)가 자사 제품이라는 이해상충이 뚜렷합니다. Snyk Code 제품 책임자가 공동저자로 참여했고, 공개 전 AI 구성이 찾은 신규 취약점을 Snyk 팀에 미리 공유해 1건에 대한 규칙 업데이트가 발표 전인 2026-10-28에 배포됐습니다(본문 수치는 업데이트 전 실행 결과). 저자들은 편향 가능성을 양방향으로 짚습니다 — 참고 정답을 GPT-5.6 계열로 심은 것이 같은 계열인 Codex Security에 유리할 수 있지만 정작 최저 점수를 받았고, 반대로 Snyk 어휘·Snyk 데모 앱 5개 포함은 Snyk Code에 유리할 수 있는데 이 5개를 빼도 순위·합집합 관계는 그대로였습니다(Snyk 74/87, Opus 72/87, 합집합 83). 전작은 LLM 재현율이 SAST 재현(100%)에 24.6%p 못 미쳤다고 보고했는데 이번 격차(3.1%p)가 더 작은 것은 상반 증거로 볼 만합니다 — 벤치마크 설계 차이로 달라질 수 있습니다. 한계로는 샘플이 작아 근소한 순위를 가르지 못하는 점, 구성당 1회 실행이라 재현 변동성을 못 측정하는 점, Snyk Code가 유일한 SAST 엔진이라 결론이 'SAST 일반'이 아니라 'Snyk Code'에 한정된다는 점이 명시돼 있습니다.

관련 연구

• Tal et al.(2026). Snyk VulnBench JS 1.0: Can LLMs Find the Same Bugs Twice? — 같은 저자팀의 직접 선행 연구(prior). JS 10개 앱·Snyk Code 기준 재현율로 LLM 보안 리뷰의 '반복 안정성'만 측정했고, 최고 LLM이 SAST 재현(100%)보다 24.6%p 낮은 75.4%였습니다. 이번 VulnBench 2.0은 그 한계(단일 언어, 도출된 정답)를 보완한 후속작입니다.
• Priyanshu et al.(2026). Vulnerability Localization Benchmark — 같은 시기의 확장형 연구(extension). 500개 실제 취약점·290개 레포·27개 LLM+4개 SAST 도구로 '파일 단위 위치 정확도'를 측정해 최고 구성의 File F1이 0.229에 그쳤다고 보고했습니다. 줄 단위로 엄격히 채점하는 VulnBench 2.0과 달리 규모를 키우고 기준을 낮춰 같은 질문에 접근합니다.

두 연구 모두 "AI 리뷰만으로는 SAST를 대체하지 못한다"는 방향은 일치하지만, VulnBench 2.0은 하니스 정책이 모델 자체보다 더 큰 변수일 수 있다는 점을 대조 실험으로 처음 분리해 보였습니다.

리뷰어 판단

첫째, 이 논문에서 가장 값진 결과는 82.4% 대 79.3%라는 경쟁 구도가 아니라 하니스 정책이 성능 격차 대부분을 설명한다는 대조 실험이라고 판단합니다. "Claude Code가 이 취약점을 못 찾는다"를 모델의 한계로 해석하기 쉬운데, 같은 모델에 프롬프트만 바꿔 9개를 16개로 끌어올렸습니다. 도입 전에 벤더의 내장 리뷰 프롬프트가 무엇을 제외하는지부터 읽어야 한다는 뜻입니다.

둘째, DeepSec의 결과는 '모델이 아니라 파이프라인 앞단'이 재현율의 상한을 정할 수 있다는 경고로 읽어야 합니다. 모델이 돌기도 전에 파일 선정 단계가 108개 중 56개 흐름의 파일만 후보로 남겼고, 선정 안 된 취약점은 어떤 백엔드도 맞히지 못했습니다. 에이전틱 스캐너 도입 시 "어떤 모델인가"보다 "어느 단계가 후보를 좁히는가"를 먼저 물어야 합니다.

셋째, 이해상충 처리 방식 자체가 주목할 선례라고 생각합니다. 자사 제품에 유리할 수 있는 선택(정답 명명 규칙, 데모 앱 포함)을 숨기지 않고 공개한 뒤 그것을 빼고 재계산해도 결론이 바뀌지 않는다는 것까지 보였습니다. 이해상충의 존재보다 그것을 얼마나 투명하게 다뤘는지가 신뢰도를 가르는 기준이어야 합니다.

실무 적용

• SAST와 AI 리뷰를 병행 — 한쪽만으로는 101/108의 합집합에 도달하지 못합니다. 중복 보고 트리아지 인력도 함께 계산에 넣습니다.
• 내장 리뷰 정책을 먼저 읽는다 — 벤더 하니스가 어떤 클래스를 제외·제한하는지(ReDoS·프로토타입 오염·오픈 리다이렉트) 확인하고 별도 규칙 기반 도구로 보완합니다.
• '찾았다'와 '정확한 줄을 짚었다'를 구분 — 파일 단위 적중률만 보면 Codex Security처럼 함수는 찾고 줄은 못 짚는 사례를 과대평가합니다.
• 비용·성능은 같은 하니스 안에서만 비교 — 모델 등급을 바꾸면 성능이 오를 수도(Opus vs Sonnet) 비용만 오를 수도(Sol vs Luna) 있습니다. 하니스를 고정한 채 실험합니다.
• 파이프라인 앞단 필터링 단계를 점검 — 파일 선정 전처리가 놓친 파일은 뒤의 모델이 아무리 좋아도 복구되지 않습니다.

결론

VulnBench 2.0의 결론은 "AI가 SAST를 대체하는가"라는 질문 자체가 잘못됐다는 쪽입니다. 108개 중 73개는 둘 다 맞혔고 나머지는 유형이 갈렸습니다 — SAST는 단일 파일·알려진 패턴에, AI는 파일 경계를 넘는 논리적 흐름과 권한 문제에 강했습니다. 더 중요한 발견은 모델 선택보다 하니스 정책이 결과를 더 크게 흔들 수 있다는 것이고, 이해상충이 있는 저자들이 스스로 대조 실험으로 증명했다는 점이 신뢰도를 더합니다. 다만 108개·20개 앱, 구성당 1회 실행이라는 한계는 남아 있어 수치는 방향 신호로 받고 도입 전 자체 벤치마크로 재확인해야 합니다. 코딩 에이전트의 신뢰 경계를 어디에 둘지는 코딩 에이전트 신뢰 경계 설계에서 이어서 다룹니다.

참고 링크

• How Deterministic SAST and AI Security Agents Divide the Work — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용
• Snyk VulnBench JS 1.0(전작) — arXiv
• Vulnerability Localization Benchmark(VLoc Bench) — arXiv
• 코딩 에이전트 신뢰 경계 설계 — sunny34.com 블로그