기술 요약: JavaVulBench

문제 정의

딥러닝 기반의 취약점 탐지는 역사적으로 C/C++ 코퍼스(예: Big-Vul, Devign)에 의존해 왔으며, 이로 인해 널리 배포되는 엔터프라이즈 언어인 Java는 저평가된 상태로 남아 있습니다. 기존의 Java 중심 벤치마크(Vul4J, VJBench, CWE-Bench-Java, CVEfixes)는 결정적인 방법론적 결함을 가지고 있습니다. 즉, 명시적인 비취약 샘플(non-vulnerable samples), 라인 단위의 세밀함(granularity), 다중 현실적 데이터 분할(multiple realistic data splits), 그리고 통합된 평가 하네스(unified evaluation harnesses)가 부족합니다. 결정적으로, 기존의 평가는 다국어 코퍼스에서 무작위 분할(random splits)을 사용하는 경우가 빈번하며, 이는 Chakraborty 등[5]에 의해 훈련 및 테스트 세트 간의 데이터 누수(예: 동일 프로젝트 내의 유사한 메서드)로 인해 성능 지표(F1 점수)를 15~40포인트까지 부풀리는 것으로 밝혀졌습니다. 또한, 사전 학습 오염(pre-training contamination)을 감사할 수 있는 인프라가 부족하여, 진정한 일반화와 단순 암기(memorization)를 구분하기 어렵습니다.

방법론

1. 데이터셋 구축 (JavaVulBench)

저자들은 1,740개의 CVE와 700개 이상의 프로젝트에 걸친 약 30,600개의 Java 메서드로 구성된 코퍼스를 구축했습니다.

• 마이닝(Mining): NIST, GitHub Security Advisories, CVEfixes에서 CVE 기록을 병합했습니다. 수정 커밋(fix commits)은 해결되었으며, 메서드, 클래스, 파일의 출처를 보존하기 위해 tree-sitter 문법을 사용하여 수정 전/후 스냅샷을 추출했습니다. 노이즈 필터를 통해 테스트 전용, 포맷팅 전용, 리팩토링 전용 커밋을 제거했습니다.
• 레이블링(Labelling): 취약한 메서드는 패치된 대응 메서드와 쌍을 이룹니다. 비취약(negative) 샘플은 취약한 메서드당 세 가지 전략을 사용했습니다: 동일 파일(3:1), 동일 프로젝트(2:1), 무작위 프로젝트(1:1).
• 세밀도(Granularity): 레이블은 메서드 및 라인 수준 모두에 존재하며, CVE 발행 날짜와 CWE 태그를 포함합니다.
• 분할 전략(Split Strategies): 다섯 가지 현실적인 파티션 전략이 JSONL 형식으로 제공됩니다:
  1. Random (무작위): 낙관적인 참조용.
  2. Project-Disjoint (프로젝트 불일치): 훈련과 테스트 사이에 프로젝트 중복이 없음.
  3. Temporal (시계열): 2023년 이전의 CVE로 학습하고, 2023년 7월 이후의 데이터로 테스트.
  4. Deduplicated (중복 제거): 분할 전 유사 중복(Jaccard 0.8)을 제거.
  5. Unseen CWE-Family (미학습 CWE 제품군): 교차 클래스 일반화를 테스트하기 위해 전체 CWE 제품군을 제외.

2. 통합 평가 하네스 (Unified Evaluation Harness)

단일 LlmPrediction 스키마는 세 가지 백엔드 제품군에 대한 평가를 통합합니다:

• 인코더 분류기(Encoder Classifiers): HuggingFace Transformers (CodeBERT, GraphCodeBERT, UniXcoder).
• 로컬 생성 모델(Local Generative Models): Ollama로 서빙되는 모델 (예: DeepSeek-Coder-1.3B)의 zero-shot 및 LoRA 미세 조정 구성.
• API 서빙 LLM(API-Served LLMs): OpenRouter를 통해 라우팅되는 모델들 (GPT-4o, GPT-4.1-mini, Claude Sonnet 4, DeepSeek-v3, DeepSeek-Coder-v2, Qwen-2.5-Coder, CodeLlama-13B).

하네스는 Java 특화 지식 베이스(MITRE CWE 설명 및 OWASP/CERT API 오용 패턴)를 활용한 zero-shot, few-shot, RAG(Retrieval-Augmented Generation)를 지원합니다. 비용 관리를 위해 API 평가는 분할당 200개 샘플의 계층적 서브셋을 사용합니다.

3. 누수 인식 평가 (Leakage-Aware Evaluation)

사전 학습 오염 감사는 테스트 세트를 "위험(risky)"(모델의 학습 컷오프 이전에 발표된 CVE)과 "클린(clean)"(이후에 발표된 CVE) 서브셋으로 분할합니다. 이를 통해 메모리된 결과가 일반화와 혼동되지 않도록 각 모델별로 지표를 별도로 보고할 수 있습니다.

주요 기여

1. 데이터셋: 메서드/라인 레이블, 225개 CWE 카테고리, 5가지 현실적 분할 전략을 갖춘 CVE 기반의 약 30,600개 메서드 코퍼스.
2. 하네스: 인코더 분류기, 로컬 LLM, API LLM을 동일한 조건에서 지원하는 단일 명령 실행 가능한 통합 평가 파이프라인.
3. 오염 감사: 잠재적으로 메모리된 테스트 샘플을 식별하고 분리하는 모델별 감사 메커니즘.
4. 재현성: 미세 조정된 체크포인트와 Zenodo에 아카이브된 데이터를 포함한, Docker 기반의 단일 명령 재현 파이프라인.

결과

분할 전략의 영향

무작위 분할에서 프로젝트 불일치 분할로 전환하면 Chakraborty 등[5]이 관찰한 성능 저하가 재현됩니다:

• UniXcoder: F1 점수가 0.446(무작위)에서 0.298(프로젝트 불일치)로 하락.
• GraphCodeBERT: F1 점수가 0.343에서 0.256으로 하락.
• CodeBERT: 프로젝트 불일치 및 시계열 분할에서 F1이 0.000으로 붕괴됨. 이는 모델이 사전 학습 데이터 내의 겹치는 API 표면이 부족하여 다수 클래스를 예측하도록 기본 설정되었기 때문입니다.
• 결론: 프로젝트 불일치 분할을 기본 헤드라인 지표로 취급해야 하며, 무작위 분할은 낙관적인 참조로만 사용되어야 합니다.

모델 성능

• 인코더: 미세 조정된 인코더(UniXcoder, GraphCodeBERT)는 프로젝트 불일치 분할에서 중간 정도의 F1 점수(~0.25–0.30)를 달성합니다.
• API LLM: 비용이 매칭된 200개 샘플 프로브에서, GPT-4o (F1=0.419)와 Claude Sonnet 4 (F1=0.416)가 모든 인코더 베이스라인을 능가합니다. GPT-4o는 가장 우수한 캘리브레이션(ECE=0.147)을 보여줍니다.
• DeepSeek-Coder-v2: 음의 MCC(-0.108)를 보여주며, 이는 zero-shot 구성에서 Java 취약점 탐지에서 무작위 확률보다 낮은 성능을 나타냅니다.
• CodeLlama-13B: 가장 높은 PR-AUC(0.540)를 보여, 임계값 기반 F1은 약하더라도 유용한 신뢰도 순위 지정 능력을 시사합니다.

오염 감사

2024–2025 컷오프를 가진 모델들(예: Claude Sonnet 4, GPT-4.1-mini)은 테스트 세트의 최대 59%를 "위험(risky)"으로 분류합니다. 흥ًا롭게도, 가장 강력한 API 모델들은 전체 세트보다 "클린(clean)" 서브셋에서 더 높은 F1 점수를 보이는데, 이는 위험한 서브셋이 쉽게 암기되는 것보다 더 어려운 CVE 변종들을 포함하고 있음을 시사합니다.

의의 및 주장

본 논문은 **분할 전략이 모든 취약점 탐지 벤치마크 수치의 제1급 속성(first-class property)**이라고 주장합니다. 주요 경험적 발견은 프로젝트 불일치 또는 시계열 분할이 없다면, 보고된 Java 취약점 탐지 F1 점수는 데이터 누수로 인해 크게 부풀려진다는 것입니다.

JavaVulBench는 연구의 재현성을 보장하고 보고된 개선 사항이 단순한 암기나 데이터 누수가 아닌 진정한 일반화를 반영하도록 하기 위해 필요한 인프라(통합 하네스, 현실적 분할, 오염 감사)를 제공합니다. 저자들은 이 작업이 기존 Java 벤치마크와 엔터프라이즈 취약점 탐지에 요구되는 엄격한 평가 표준 사이의 간극을 메우는 역할을 한다고 규정합니다.