기술 요약: 네 가지 원칙 프레임워크를 통한 품질 보증 퍼즈 하네스 생성

1. 문제 제기

퍼즈 테스트는 C/C++ 소프트웨어에서 메모리 안전성 취약점을 발견하는 주된 기법입니다. 그러나 라이브러리 코드의 경우, 퍼징의 효과성은 퍼저 엔진과 라이브러리 API 를 연결하는 프로그램인 퍼즈 하네스의 품질에 전적으로 달려 있습니다. 자동화된 하네스 생성 도구 (예: FuzzGen, OSS-Fuzz-Gen, PromptFuzz) 는 이러한 하네스들의 생성을 확장해 왔지만, 정확성을 보장하는 체계적인 메커니즘은 부족합니다.

현재의 도구들은 빌드 성공 여부, 충돌 횟수, 코드 커버리지와 같은 간접 신호에 의존합니다. 이러한 신호들은 불충분합니다. 하네스가 컴파일되고 실행되더라도 API 계약 위반, 객체 수명 주기 오용, 또는 보안 경계 우회와 같은 결함이 발생할 수 있기 때문입니다. 이러한 결함들은 이전 연구에서 최대 94% 에 달하는 거짓 긍정 충돌 보고서를 생성합니다. 대규모 언어 모델 (LLM) 이 하네스 생성을 확장 가능하게 만들면서, 통제되지 않은 품질은 이러한 확장성을 리스크로 전환시켜, 실제 라이브러리 버그와 유사한 하네스로 인한 충돌을 필터링해야 하는 유지보수자의 분류 부담을 가중시킵니다.

2. 방법론: 네 가지 원칙 프레임워크

저자들은 퍼징 캠페인이 시작되기 전에 하네스의 정확성을 강제하도록 설계된 자율 LM 에이전트 시스템인 QuartetFuzz를 소개합니다. 핵심 혁신은 수학적 명세와 구현 가능한 검사를 갖춘 하네스 정확성의 소스 레벨 정의인 네 가지 원칙 프레임워크입니다:

1. P1: 논리 정확성: 하네스 자체는 라이브러리의 동작과 무관하게 충돌을 유발하는 버그 (예: 낡은 상태, 자원 누수, 잘못된 데이터 처리) 가 없어야 합니다.
2. P2: API 프로토콜 준수: 하네스는 객체 수명 주기, 매개변수 제약 조건, 초기화 순서를 존중하며 유효한 순서로 대상 라이브러리를 호출해야 합니다.
3. P3: 보안 경계 존중: 하네스는 내부 전용 코드를 호출하여 검증을 우회하는 대신 공개 인터페이스를 테스트해야 합니다.
4. P4: 진입점 적절성: 하네스는 우연적인 보조 로직이 아닌 의미 있고 공격 표면과 관련된 진입점을 대상으로 해야 합니다.

시스템 아키텍처

QuartetFuzz 는 이러한 원칙들을 4 단계 파이프라인을 통해 운영화합니다:

• 1 단계: 논리 그룹 발견: 에이전트가 프로젝트의 호출 그래프를 탐색하여 후보 "논리 그룹"(예: "PNG 이미지 파싱"과 같은 기능 단위) 을 식별합니다. 에이전트는 도달 가능한 위험한 연산에 기반한 정적 위험 점수로 이러한 그룹들을 순위 매긴 후, P3(공개 API 도달성) 과 P4(적절성) 를 만족하는 진입점을 선택합니다.
• 2 단계: API 프로토콜 조사: 전용 에이전트가 헤더, 소스 코드, 기존 호출자를 분석하여 선택된 대상에 대한 프로토콜 정보 (호출 순서, 수명 주기, 제약 조건) 를 수집합니다. 이는 검증 가능한 소스 증거에 기반한 구조화된 P2 프로토콜 보고서를 생성합니다.
• 3 단계: 정적 기반 빌드: 하네스 생성 에이전트가 논리 그룹과 P2 보고서를 포함하여 퍼저 소스 코드를 초안 작성합니다. 이는 컴파일 가능한 바이너리를 생성하기 전에 P1/P2 하위 검사를 확인하기 위해 정적 분석과 의미론적 추론을 사용하는 유한 빌드 루프를 수행합니다.
• 4 단계: 적대적 검증: 제출 전에 시스템은 **적대적 프로빙 (Adversarial Probing, AP)**을 사용합니다. 에이전트는 P1/P2 하위 검사 위반을 의심되는 것을 유발하도록 설계된 특정 "공격 덩어리 (attack blobs)"를 생성합니다. 이러한 덩어리는 두 가지 프로브를 통해 실행됩니다:
  • Reach Check: 입력이 대상 API 로 실행을 유도하는지 확인합니다 (GDB 사용).
  • Run Check: 하네스가 샌드라이저 (ASan/LSan) 하에서 충돌하는지 확인합니다.
    하네스가 모든 선택된 프로브를 통과해야만 (즉, 하네스로 인한 충돌이 없어야만) 퍼징으로 진행됩니다.

3. 주요 기여

1. 네 가지 원칙 프레임워크: 정적 검사 및 런타임 적대적 프로빙을 통해 운영화된, 수학적 명세를 갖춘 하네스 정확성의 첫 번째 소스 레벨 정의.
2. 종단 간 품질 보증 파이프라인: 퍼징 시작 전에 P1–P4 를 검사하여 상류 병합 준비가 된 전달 가능한 하네스를 생성하는 4 단계 LLM 에이전트 시스템.
3. 선별된 평가 데이터셋: 586 개의 프로덕션 하네스에 대한 수동 감사에서 파생된 39 개 프로젝트의 100 개 라벨링된 P1–P4 클린 하네스로 구성된 골드 스탠다드 데이터셋으로, 인간이 작성한 퍼저에 대한 재현 가능한 평가를 가능하게 함.
4. 실제 환경 검증: 23 개의 오픈 소스 프로젝트 (C/C++, Java, JavaScript) 에 대한 배포를 통해 낮은 거짓 긍정률로 취약점을 발견하는 시스템의 능력을 입증.

4. 결과

시스템은 다섯 가지 연구 질문 (RQ) 에 대해 평가되었습니다:

• RQ1 (감사): 70 개 프로젝트의 586 개 프로덕션 OSS-Fuzz 하네스에 사후 감사자로 적용된 결과, QuartetFuzz 는 **53 개의 위반 사항 (9.0%)**을 식별했습니다. 이 중 45 개는 유지보수자에 의해 확인되었고 35 개는 상류에서 수정되거나 병합되었습니다. 중요하게도, 이러한 결함을 수정함으로써 원래 하네스들이 가리고 있던 2 개의 잠재적 라이브러리 버그(OpenSSL 의 DES 구현에 있는 25 년 된 스택 버퍼 오버리드 포함) 가 드러났습니다. 감사는 또한 14 개의 하네스로 인한 충돌을 차단하여 거짓 긍정 보고서가 되는 것을 방지했습니다.
• RQ2 (논리 그룹 품질): 골드 스탠다드 데이터셋에서 에이전트의 진입점 선택은 프롬프트에 특정 함수 이름이 없더라도 91%(91/100)의 경우 인간 전문가의 선택과 일치했습니다.
• RQ3 (생성 대 베이스라인): 100 건 데이터셋에서 QuartetFuzz 가 생성한 하네스는 인간이 작성한 골드 스탠다드와 통계적으로 동등한 코드 커버리지를 달성했습니다 (TOST 동등성, $p < 10^{-10}$). 라인/브랜치 커버리지에서 OSS-Fuzz-Gen보다 6.9–8.3 퍼센트 포인트, PromeFuzz보다 4.1–5.2 퍼센트 포인트 더 높은 성능을 보였습니다. 생산성 비율 (성공적인 빌드 및 0 이 아닌 커버리지) 은 **96%**였으며, OSS-Fuzz-Gen 은 64%, PromeFuzz 는 74% 였습니다.
• RQ4 (절제 실험): 적대적 프로빙을 제거하면 생산성 비율이 12pp 감소했고, P2 프로토콜 보고서를 제거하면 13pp 감소하여 이러한 구성 요소가 품질에 필수적임을 확인했습니다.
• RQ5 (배포): 23 개 프로젝트에 배포된 시스템은 42 개의 버그 보고서를 제출했습니다. 29 개는 수정되거나 확인되었고 (이 중 3 개의 CVE 포함), 2 개만 거짓 긍정으로 거절되어 4.8% 의 FP 비율을 기록했는데, 이는 비교된 LLM 기반 생성자 중 가장 낮았습니다. 시스템은 LLM 만을 사용한 순위 매기기를 통해 Java(PDFBox) 및 JavaScript(GraalJS) 프로젝트에서도 버그를 식별했습니다.

5. 중요성과 주장

이 논문은 하네스 품질이 퍼징 효과성의 결정적 제약 조건이라고 주장합니다. 저자들은 확장 가능한 LLM 생성 시대에는 퍼징 후에 충돌 로그로부터 정확성을 추론하는 전통적인 접근 방식이 불충분하다고 주장합니다. 대신 품질은 퍼징 시작 전에 소스 레벨 검사를 통해 강제되어야 합니다.

이 연구의 중요성은 다음과 같습니다:

• 패러다임 전환: 자동화된 생성의 주요 지표로 "빌드되고 실행되는가?"에서 "하네스가 정확한가?"로 전환.
• 분류 부담 감소: 유지보수자에게 도달하기 전에 하네스로 인한 충돌 (감사와 생성 과정에서 총 58 건 차단) 을 차단함으로써 OSS 유지보수자가 자동화된 도구에 대해 가지는 주요 우려를 해결.
• 잠재적 버그 드러내기: 하네스 프로토콜 위반을 수정함으로써 이전에 잘못된 사용 패턴에 의해 숨겨져 있던 깊고 장기적인 라이브러리 버그를 드러낼 수 있음을 입증.
• 재현성: 하네스 품질을 위한 첫 번째 라벨링 데이터셋을 제공하고 시스템 및 베이스라인을 오픈 소스화하여 엄격한 비교를 가능하게 함.

저자들은 소스 코드 분석의 결정 불가능성으로 인해 수학적 정의가 구문 검사 및 LLM 추론으로 근사화됨을 인정하며 겸손한 어조를 유지합니다. 그들은 네 가지 원칙 프레임워크를 최종 증명보다는 "시작 정의"로 위치시켜, 신뢰할 수 있는 자동화된 퍼징에 대한 미래 연구의 기반을 마련하고자 합니다.