LLM-based Vulnerability Detection at Project Scale: An Empirical Study

기술 요약: 프로젝트 규모에서의 LLM 기반 취약점 탐지: 경험적 연구

문제 정의
소프트웨어 복잡성과 배포 규모가 증가함에 따라 보안 취약점이 더욱 빈번하고 해로운 문제가 되었으며, 이에 따라 강력한 자동 탐지가 필수적이 되었습니다. 기존의 정적 분석 도구들은 널리 채택되어 사용되고 있으나, 수동으로 설계된 규칙과 사전 정의된 패턴에 의존하기 때문에 보이지 않거나 진화하는 유형의 취약점에 대한 일반화 능력이 제한적입니다. 반면, 최근의 대규모 언어 모델(LLM) 기반 탐지기들은 명시적인 규칙 엔지니어링 없이도 코드 의미론(semantics)과 복잡한 로직을 해석함으로써 향상된 의미론적 추론을 약속합니다. 그러나 기존의 대부분의 LLM 기반 접근 방식은 함수 수준 또는 헌크(hunk) 수준의 스니펫에 대해 평가되며, 프로젝트 규모에서의 효과성, 신뢰성 및 확장성은 불분나명합니다. 특히 이러한 특화된 탐지기를 적용할 때 발생하는 실패의 근본 원인(특히 오탐)과 계산 오버헤드에 대한 체계적인 이해가 부족한 실정입니다.

방법론
저자들은 다섯 가지 특화된 프로젝트 규모 LLM 기반 취약점 탐지기를 두 가지 전통적인 정적 분석 도구(CodeQL 및 Semgrep)와 비교하는 최초의 포괄적인 경험적 연구를 제시합니다. 이 연구는 이중 설정 평가 전략을 채택합니다:

1. 내부 벤치마크: ReposVul, CWE-Bench-Java, JLeaks에서 유래한 222개의 알려진 실제 취약점(C/C++ 및 Java의 8가지 CWE 유형 포함)을 포함하는 큐레이션된 데이터셋을 사용합니다. 이 설정은 그라운드 트루스(ground truth)에 대한 탐지 능력(재현율, Recall)을 평가합니다.
2. 실제 프로젝트: 24개의 활발하게 유지 관리되는 오픈 소스 프로젝트(Linux 커널 구성 요소, ImageMagick, Jenkins, Keycloak 포함) 세트를 사용합니다. 이 설정은 경고 발생량과 허위 발견율(False Discovery Rate, FDR)을 분석하여 실질적인 사용성을 평가합니다.
3. 수동 분석: 두 명의 보안 전문가가 385개의 샘사된 경고를 수동으로 검사하여(150시간 이상의 인적 시간 소요) 오탐의 근본 원인에 대한 분류 체계를 구축했습니다.
4. 비용 측정: 각 도구의 입력/출력 토큰 소비량과 엔드 투 엔드 실행 시간을 측정하여 계산 오버헤드를 정량화했습니다.

평가된 LLM 기반 방법에는 멀티 에이전트 프레임워크, LLM 지원 체커 생성, 제어 흐름 가이드 추론 등 다양한 워크플로우를 나타내는 RepoAudit, KNighter, IRIS, LLMDFA, INFERROI가 포함됩니다.

주요 기여

• 최초의 프로젝트 규모 비교: 본 연구는 다섯 가지 대표적인 LLM 기반 탐지기를 프로젝트 규모에서 전통적인 도구들과 체계적으로 비교하는 최초의 연구입니다.
• 포괄적인 평가: 222개의 알려진 취약점에 대한 탐지 효과와 24개의 실제 프로젝트에 대한 실질적인 사용성을 평가합니다.
• 실패 분류 체계: 저자들은 385개의 보고서를 수동으로 레이블링하여 오탐 원인에 대한 상세한 분류 체계를 구축하였으며, 설계 선택(예: 데이터 흐름 구축, 소스/싱크 추론)이 실패에 어떻게 기여하는지 정량화했습니다.
• 비용 분석: 프로젝트 규모의 LLM 탐지와 관련된 상당한 토큰 사용량과 시간 비용을 측정하고 보고합니다.
• 아티팩트 공개: 재현성을 촉진하기 위해 스크립트, 프롬프트, 분류 레이블을 포함한 모든 실험 아티팩트를 공개합니다.

주요 결과

1. 낮은 재현율과 고유한 탐지: 내부 벤치마크에서 LLM 기반 방법들은 낮은 평균 재현율(C/C++ 21.09%, Java 33.82%)을 보였으며, 주로 소스/싱크 정의의 불일치로 인해 취약점을 놓치는 경우가 많았습니다. 그러나 이들은 여로 전통적인 도구보다 더 많은 고유한 취약점을 발견하였으며, 이는 상호 보완적인 가치를 시사합니다.
2. 높은 허위 발견율(FDR): 실제 프로젝트에서 LLM 기반 도구와 전통적인 도구 모두 매우 높은 FDR을 가진 상당한 양의 경고를 생성했습니다. 가장 성능이 좋은 도구조차 평균 FDR이 85.3%였습니다. 예를 들어, C/C++ 프로젝트에 대한 RepoAudit의 평균 SFDR은 97.0%였습니다.
3. 실패의 근본 원인: 수동 분석 결과, LLM과 전통적인 도구 모두에서 공통적으로 나타나는 두 가지 지배적인 원인이 식별되었습니다:
   • 얕은 절차 간 추론 (오탐의 37.47%): 도구들이 깊은 호출 체인이나 복잡한 제어 구조를 통한 데이터 흐름을 추적하는 데 실패합니다.
   • 부정확한 소스/싱크 식별 (오탐의 19.00%): 도구들이 무해한 프로그램 지점을 보안 관련 지점으로 잘못 식별하거나 프로젝트 특정 API를 인식하지 못합니다.
   • LLM 특유의 실패: LLM 기반 도구들은 추가적으로 환각된 코드 이해, 잘못된 제어 흐름 재구성(예: 상호 배타적인 경로의 병합), 또는 프롬프트 정의나 CWE 범위에 엄격하게 준수하지 못하는 문제로 어려움을 겪었습니다.
4. 계산 오버헤드: 프로젝트 규모의 LLM 탐지는 계산 비용이 많이 듭니다. RepoAudit 및 LLMDFA와 같은 도구는 프로젝트당 수십만에서 수억 개의 토큰을 필요로 하며, 실행 시간은 수 시간에서 수 일(예: 최대 4,638분)에 달합니다. 전통적인 도구(CodeQL, Semgrep)는 무시할 만한 토큰 비용으로 몇 초에서 몇 분 내에 분석을 완료합니다.

의의 및 시사점
본 논문은 LLM 기반 탐지기가 전통적인 패턴 매칭 도구가 놓치는 취약점을 발견할 수 있는 유망한 의미론적 추론 능력을 제공하지만, 실제 시나리오에서 신뢰할 수 있는 단독 배포를 위한 성숙도는 아직 부족하다고 결론짓습니다. 이 연구는 강건성(높은 FDR), 신뢰성(그라운드 트루스에 대한 낮은 재현율), 확장성(과도한 계산 비용) 측면의 결정적인 한계를 강조합니다.

저자들은 향후 연구를 위한 다섯 가지 시사점을 도출했습니다:

1. 데이터 흐름 추론 심화: 얕은 호출 그래프 탐색을 넘어 전역적인 "입력 → 전파 → 출력" 분석으로 나아가야 합니다.
2. 소스/싱크 추론 개선: 일반적이거나 환각된 정의에 의존하는 대신, 프로젝트 특정 API를 정확하게 식별할 수 있는 문맥 인식 메커니즘을 개발해야 합니다.
3. 의미론적 이해 강화: 복잡한 언어 기능(예: 소멸자, try-with-resources)을 더 잘 처리하기 위해 LLM을 중간 프로그램 표현 및 정적 분석 신호와 통합해야 합니다.
4. 프롬프트 정렬 강제: 모델이 취약점 정의를 엄격히 준수하도록 구조화된 멀티 에이전트 협업 또는 자가 검증을 구현해야 합니다.
5. 확장성 해결: 지속적 통합(CI)에 적합한 수준으로 토큰 소비와 실행 시간을 줄이기 위해 계층적 분석, 중간 추론 캐싱 및 워크플로우 최적화를 채택해야 합니다.

저자들은 현재의 결과가 LLM의 의미론적 강점을 활용하면서도 엄격한 정적 분석 통합을 통해 비용 및 신뢰성 문제를 완화하는 하이브리드 접근 방식의 필요성을 강조한다고 역설합니다.