기술 요약: POC-GYM: 더 신뢰할 수 있는 LLM 지원 PoC(Proof-of-Concept) 익스플로잇 생성 toward

문제 정의

PoC(Proof-of-Concept) 익스플로잇 생성은 취약점 검증, 패치 개발 지원, 회귀 테스트 수행에 필수적입니다. 그러나 공개된 취약점 중 상당수는 사용 가능한 PoC 가 부재합니다. 대규모 언어 모델 (LLM) 이 취약점 탐지 및 익스플로잇 생성 자동화에 increasingly 적용되고 있지만, 기존 접근 방식은 종종 신뢰성 문제를 겪습니다.

현재 LLM 지원 방식은 일반적으로 취약점 설명을 기반으로 PoC 를 생성하고, 인쇄된 마커, 생성된 파일, 또는 런타임 부수 효과와 같은 얕은 신호를 사용하여 이를 검증합니다. 저자들이 규정한 핵심 문제는 이러한 신호가 실제 취약점을 유발하지 않는 '거짓 양성 (false-positive)' 코드 경로로도 충족될 수 있다는 점입니다. 결과적으로, PoC 는 자동화된 런타임 검사 하에서는 성공적으로 보일 수 있지만 실제 취약한 코드 위치 (ground truth) 에 도달하지는 못할 수 있습니다. 표면적인 성공과 진정한 익스플로잇을 구분할 수 있는 더 신뢰할 수 있는 생성 파이프라인이 필요합니다.

방법론: PoC-Gym 프레임워크

저자들은 정적 애플리케이션 보안 테스트 (SAST) 데이터플로우 추적과 LLM 추론을 결합하여 Java PoC 익스플로잇을 생성하도록 설계된 하이브리드 파이프라인인 PoC-Gym을 제안합니다. 이 프레임워크는 세 가지 반복 단계를 통해 작동합니다:

1. 프롬프트 구성:

   • 취약점별 컨텍스트: 시스템은 LLM 을 사용하여 CVE 와 Common Weakness Enumeration (CWE) 설명에 기반한 구체적인 익스플로잇 목표와 프로그래밍적 검증 검사를 정의하는 명시적인 "CVE 특정 가이드"를 생성합니다.
   • 추적 컨텍스트: 구체적인 프로그램 경로를 제공하기 위해 PoC-Gym 은 CodeQL 과 IRIS 프레임워크를 사용하여 추출된 정적 소스 - 싱크 (source-to-sink) 데이터플로우 추적을 통합합니다. 이러한 추적은 LLM 트라이지 어시스턴트에 의해 순위가 매겨져 가장 관련성 높은 경로를 선택한 후 포맷팅되어 프롬프트에 삽입됩니다.
   • 저장소 제약 조건: 프롬프트에는 취약한 저장소에 대한 메타데이터 (URL, 커밋, 빌드 스크립트) 와 생성된 코드가 실행 가능하도록 보장하기 위한 API 사용에 대한 엄격한 제약 조건 (예: 리플렉션 회피, 의존성 제한) 이 포함됩니다.

2. PoC 생성:

   • LLM 에이전트 (예: Claude Sonnet 4, GPT-5) 는 구조화된 프롬프트를 수신하고 단일 Java 소스 파일 (PoCTest.java) 을 생성합니다.
   • 에이전트는 취약점을 유발하고 특정 성공 마커 ([VULN]) 를 인쇄하는 main 메서드를 가진 public 클래스를 생성하도록 제한됩니다.

3. PoC 검증:

   • 런타임 검증: 후보 PoC 는 AspectJ 인스트루멘테이션을 사용하여 취약한 프로젝트에서 컴파일되고 실행됩니다. 후보는 다음 조건을 모두 충족할 때만 "런타임 유효 (runtime-valid)"로 간주됩니다:
     1. 성공적으로 종료됨 (종료 코드 0).
     2. [VULN] 마커를 인쇄함.
     3. 정적 추적에서 정의된 특정 싱크 위치에 도달함 (SinkReachability).
   • 반복 피드백: 검증이 실패할 경우, 출력 및 추적 커버리지를 포함한 실패 요약이 다음 반복을 위한 프롬프트에 추가됩니다.
   • 사후 검증: 중요하게도, 저자들은 CWE-Bench-Java 벤치마크에서 제공된 "ground-truth" 취약한 위치에 대한 별도의 검증 단계를 도입했습니다. 이 단계는 실행이 패치에서 식별된 특정 파일 및 행 범위에 실제로 도달했는지 확인하여 시뮬레이션과 진정한 익스플로잇을 구분합니다.

주요 기여

• 하이브리드 파이프라인: 익스플로잇 생성을 안내하기 위해 정적 분석에서 파생된 데이터플로우 추적과 LLM 생성 및 동적 싱크 도달성 검사를 통합합니다.
• 이중 검증 메커니즘: "런타임 유효 (생성 루프의 기준을 충족)"와 "사후 유효 (ground-truth 취약한 위치에 도달)"를 구분하여 기존 방법에서의 성공 과대평가를 강조합니다.
• 종합적 실패 분석: 런타임 검증을 통과했으나 사후 검증에서 실패한 PoC 에 대한 심층 수동 분석을 수행하여 "무관한 오류" (잘못된 추적/설명), "하드코딩", "시뮬레이션" (유발 대신 취약점 논리를 재구현), "부적절한 검증" (신뢰할 수 없는 성공 신호) 과 같은 실패 모드를 분류했습니다.

실험 결과

저자들은 세 가지 다른 LLM 구성을 사용하여 CWE-Bench-Java 의 20 개의 실제 Java CVE에 대해 PoC-Gym 을 평가했습니다.

• 런타임 대 사후 유효성: 338 회 실행에서 PoC-Gym 은 116 개의 런타임 유효 후보 (34.3%) 를 생성했습니다. 그러나 ground-truth 위치에 대한 사후 검증 후, 65 개 후보 (19.2%) 만 유효한 것으로 확인되었습니다. 이는 런타임 검사 하에서 성공적으로 보인 후보의 44% 가 실제 취약점 싱크에 도달하지 않은 실제 거짓 양성이라는 것을 나타냅니다.
• 추적 가이드의 영향: 추적 정보 없이 수행된 실험은 더 높은 초기 런타임 성공률 (86.7%) 을 보였으나 사후 유효성은 훨씬 낮았습니다 (36.7%). 반면, 다중 추적 설정은 초기 성공률은 낮았으나 (23.0%) 사후 유효성 감소 폭은 작았습니다 (15.5%). 이는 추적 가이드가 실제 취약한 경로에 해당하지 않는 잘못된 솔루션을 필터링하는 데 도움이 됨을 시사합니다.
• FaultLine 과의 비교: FaultLine 시스템과 중복되는 14 개 CVE 에 대해, 가장 강력한 PoC-Gym 구성 (추적을 사용한 Claude Sonnet 4) 은 8/14개의 사후 유효 결과를 달성한 반면, FaultLine 은 원래 평가 기준 하에서 5/14를 기록했습니다.

중요성 및 주장

이 논문은 LLM 이 익스플로잇 전략 생성에서 가능성을 보이지만, 결정론적 테스트 생성 기술을 완전히 대체할 수는 없다고 주장합니다. 저자들은 다음과 같이 논합니다:

1. 신뢰성은 ground-truth 검증을 요구합니다: 런타임 신호만으로는 익스플로잇 정확성을 과대평가합니다. 진정한 효과를 평가하려면 알려진 취약한 위치에 대한 사후 검증이 필요합니다.
2. 추적 컨텍스트는 거짓 양성을 줄입니다: 정적 추적이 모든 실패를 제거하지는 않지만, 얕은 성공 신호를 충족하는 잘못된 솔루션의 비율을 크게 줄입니다.
3. 실패 패턴은 체계적입니다: 많은 실패는 특정하고 반복되는 패턴 (예: LLM 이 취약점을 유발하는 대신 시뮬레이션하거나, 무관한 추적을 사용하는 경우) 에서 발생합니다. 이러한 패턴을 이해하는 것은 향후 시스템 설계 개선을 위해 필수적입니다.

저자들은 LLM 지원 PoC 생성의 향후 발전은 생성 품질 향상뿐만 아니라 더 강력한 검증 메커니즘 개발과 실패 분석을 활용하여 LLM 의 창의성과 사양 기반 검사의 결합을 안내하는 데 달려 있다고 결론지었습니다.