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

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

관련 논문

• MemTrace: LLM Memory System의 오류를 추적하고 원인을 찾아내는 프레임워크

  RAG, Mem0 같은 LLM 메모리 시스템이 왜 틀린 답을 내는지 자동으로 찾아주는 디버깅 프레임워크

• DeepSWE: 오염 없는 장기 코딩 에이전트 벤치마크

  기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.

• Constraint Decay: LLM 에이전트가 백엔드 코드 생성에서 구조적 제약을 못 따라가는 이유

  LLM 코딩 에이전트는 구조적 제약(아키텍처 패턴, ORM, DB 설계)이 쌓일수록 성능이 급격히 떨어지는 'constraint decay' 현상을 보인다는 연구 결과로, AI 코딩 도구를 프로덕션에 쓰려는 개발자라면 반드시 알아야 할 한계다.

• AMEL: 대화 히스토리가 LLM 판단에 미치는 누적 편향 효과

  LLM을 자동 평가자로 쓸 때 이전 대화 기록의 긍정/부정 분위기가 이후 판단을 오염시킨다는 걸 75,898개 API 호출로 증명한 연구.

• Language Model의 Backdoor Trigger는 숨겨진 Latent 경로를 통해 전파된다

  8B LLM에 심어진 백도어 트리거가 중간 레이어에서 언어 탐지기를 완전히 속이는 직교 부분공간(orthogonal subspace)으로 숨어 이동한다는 걸 회로 분석으로 밝혀냈다.

• Formal Methods와 LLM의 만남: AI 시스템 규정 준수를 위한 감사, 모니터링, 개입

  LLM이 규칙을 잘 지키고 있는지 감시하려면 LLM에게 맡기지 말고 LTL(시간 논리 공식) 기반 모니터를 쓰세요.

• Bun의 Rust 재작성: "safe Rust에서 UB(Undefined Behavior)를 허용하는 코드베이스"

Related Resources

• N-Day-Bench 원본 사이트
• 문제 케이스 trace 예시 (GPT-5.4 vs Claude Opus 4.6)