N-Day-Bench – LLM이 실제 코드베이스에서 진짜 취약점을 찾을 수 있을까? | AI Paper Digest

TL;DR Highlight

GPT-5.4가 공개 N-Day 보안 취약점을 코드에서 탐지하는 벤치마크에서 1위를 차지했으나 평가 방식의 신뢰성이 커뮤니티에서 문제로 지적되고 있다.

Who Should Read

LLM을 보안 취약점 탐지나 코드 감사(audit)에 활용하려는 보안 엔지니어나 개발자, 또는 AI 모델의 사이버보안 역량을 비교 평가해야 하는 연구자.

Core Mechanics

N-Day-Bench는 LLM의 '취약점 탐지' 능력을 측정하는 벤치마크로, 각 모델이 이미 공개된 보안 취약점(N-Day, 패치 전에 발견된 취약점)을 실제 코드에서 직접 찾아낼 수 있는지를 테스트한다.
평가 설계 구조는 세 개의 에이전트로 구성된다: Curator(큐레이터)가 보안 어드바이저리를 읽고 정답 키를 만들고, Finder(평가 대상 모델)가 24번의 shell 명령 실행 기회를 가지고 코드를 탐색해 취약점 보고서를 작성하며, Judge(판정 모델)가 보고서를 채점한다.
Finder 모델은 패치 코드를 볼 수 없고, '싱크 힌트(sink hints, 취약점이 도달하는 최종 지점 정보)'만 제공받은 상태에서 실제 코드를 역추적해 취약점의 근원까지 찾아야 한다.
이번 최신 벤치마크 실행 결과(2026년 4월 기준): 1000개의 어드바이저리를 스캔해 47개 케이스가 채택되었고, GPT-5.4가 평균 점수 83.93으로 1위, GLM-5.1(80.13), Claude Opus 4.6(79.95), Kimi K2(77.18), Gemini 3.1 Pro Preview(68.50) 순이다.
채점 기준은 5가지 차원으로 구성된다: 타깃 정렬(30%), 소스-투-싱크 추론(30%), 영향도 및 취약성(20%), 증거 품질(10%), 과장 통제(10%)이며, Judge LLM이 이 전체 점수 객체를 한 번에 생성한다.
벤치마크는 매월 테스트 케이스를 업데이트하고 모델도 최신 버전으로 갱신하는 적응형(adaptive) 설계를 채택했으며, 모든 평가 trace(실행 로그)를 공개적으로 열람할 수 있다.
Judge LLM이 사후에 공식으로 점수를 계산하는 대신 점수 전체를 직접 생성하는 방식을 택했는데, 운영자는 이를 '의도적 트레이드오프'라고 설명하지만 커뮤니티에서는 이 판단의 근거를 강하게 의심하고 있다.

Evidence

벤치마크 결과의 신뢰성에 대한 심각한 문제가 제기됐다. 한 댓글러가 특정 케이스를 분석한 결과, GPT-5.4는 지정된 파일을 찾지 못해 9단계 탐색 후 포기해 '실패' 판정을 받았는데, Claude Opus 4.6은 마찬가지로 파일을 찾지 못하고 24번의 tool call을 소진한 뒤 훈련 데이터에서 유사한 취약점을 환각(hallucination)으로 생성한 보고서를 제출했고 이게 '우수(excellent)'로 판정받았다는 것이다.
위 사례에 대해 댓글러는 Judge 모델이 최종 출력 요약만 보는 게 아니라 버그를 찾는 각 단계 전체를 검토해야 이런 환각 통과를 막을 수 있다고 지적했다.
채점 방식에 대한 비판도 있었다. Judge LLM이 사후 공식 계산 대신 점수를 통째로 생성하는 이유로 '사후 공식 적용이 취약하다'는 설명을 하는데, 한 댓글러는 사후 공식 적용이 왜 취약한지 전혀 납득이 안 된다며 이것이 LLM이 게으름을 합리화하는 전형적인 방식이라고 비판했다.
실제 사용 경험도 공유됐다. 한 댓글러는 2025년 1월에 Gemini를 이용해 자사 레거시 시스템에 블랙박스/화이트박스 테스트를 수행했을 때 숨겨진 SQL 인젝션 취약점을 성공적으로 찾아내 비밀번호 해시까지 추출했다고 했으며, 이 수준을 '중급 사이버보안 전문가 정도'로 평가했다.
벤치마크 하네스(harness, 테스트 실행 환경)가 오픈소스가 아니라는 점도 지적됐다. trace 로그를 공개하는 것만으로는 부족하고 전체 harness 코드가 공개되어야 신뢰할 수 있다는 의견, 취약점이 없는 케이스도 포함시켜 false positive(오탐) 비율을 측정해야 한다는 의견, 모델이 인터넷 검색이 가능한지와 취약점 공개 이후 결과를 어떻게 필터링하는지에 대한 질문도 있었다.

How to Apply

자사 레거시 코드베이스의 보안 감사를 저비용으로 수행하고 싶다면, GPT-5.4나 Claude Opus 4.6 같은 상위 모델에 싱크 힌트(취약점 도달 지점)를 제공하고 소스코드를 탐색하게 하는 방식을 시도해볼 수 있다. 다만 모델이 파일을 찾지 못할 경우 환각 보고서를 생성할 수 있으므로 반드시 탐색 trace를 사람이 직접 검토해야 한다.
LLM-as-a-Judge 방식으로 보안 취약점 탐지 결과를 자동 채점하는 파이프라인을 구축할 때, 최종 보고서만 채점하면 환각 통과 문제가 발생할 수 있으므로 Judge 모델이 탐색 각 단계의 tool call 기록을 함께 검토하도록 설계해야 한다.
AI 기반 취약점 탐지 도구의 성능을 내부적으로 평가할 때, 취약점이 없는 케이스(negative case)도 테스트셋에 포함시켜 false positive 비율을 함께 측정해야 실제 운영 환경에서의 신뢰도를 정확히 파악할 수 있다.
N-Day-Bench 리더보드를 모델 선택의 참고 자료로 쓰고 싶다면, 현재 harness 코드가 비공개이고 Judge 설계에 신뢰성 논란이 있으므로 개별 trace 로그를 직접 열람해 모델이 실제로 추론 과정을 거쳤는지 확인하는 방식으로 활용하는 것이 좋다.

Terminology

N-Day이미 공개적으로 알려진 보안 취약점을 말한다. 패치가 나왔지만 아직 적용 안 된 시스템이 노출되는 기간의 취약점으로, Zero-Day(아직 아무도 모르는 취약점)와 구별된다.

sink hint취약점 코드 흐름에서 '최종 도달 지점'에 대한 힌트다. 예를 들어 SQL 쿼리가 실행되는 함수가 sink인데, 모델은 이 지점에서 역방향으로 입력 경로를 추적해 취약점 원인을 찾아야 한다.

LLM-as-a-JudgeLLM의 출력을 사람 대신 다른 LLM이 평가하는 방식이다. 비용이 저렴하고 빠르지만, Judge LLM 자체의 편향이나 환각이 평가 품질에 영향을 줄 수 있다는 단점이 있다.

harness벤치마크에서 모델을 실행하고 테스트 케이스를 공급하며 결과를 수집하는 실행 환경 코드 전체를 말한다. 이게 공개되지 않으면 재현 가능성과 신뢰성을 검증하기 어렵다.

false positive취약점이 없는데 있다고 잘못 탐지하는 오탐(誤探)을 말한다. 보안 도구 평가에서 탐지율만큼 중요한 지표로, 오탐이 많으면 실제 운영에서 쓰기 어렵다.

SQL 인젝션사용자 입력값이 그대로 SQL 쿼리에 삽입되는 취약점이다. 공격자가 악의적인 SQL 구문을 넣어 데이터베이스를 무단으로 조회하거나 변조할 수 있다.

N-Day-Bench – LLM이 실제 코드베이스에서 진짜 취약점을 찾을 수 있을까?