GitHub Security Lab 연구원 Antonio Morales는 9월 24일, 대형언어모델(LLM)이 구동하는 퍼징(fuzzing) 파이프라인을 공개하는 글을 올렸다. 대상은 C/C++ 프로젝트이며, 코드는 GitHub 저장소 seclab-taskflows-fuzzing에 있고 기본 모델은 Claude Sonnet 5다.
이 파이프라인은 GitHub 자체의 Taskflow Agent 프레임워크 위에 만들어졌다. GitHub는 이 프레임워크를 “LLM 기반 보안 자동화를 작성하기 위한 프레임워크”로 소개한다. 사용자는 저장소에서 Codespace를 열고 스크립트 한 줄을 실행한 뒤 대상 프로젝트 이름(예: tukaani-project/xz)을 붙이면, 나머지는 에이전트가 알아서 처리한다.
진입점 탐색부터 보고서 작성까지
글에 따르면 파이프라인은 다음 순서로 작동한다. 코드의 진입점을 식별하고, 테스트용 하네스(harness)를 자동으로 작성하고, AFL++를 호출해 퍼징을 실행하고, 커버리지 리포트를 읽고, 커버리지 상황에 맞춰 하네스를 다시 작성하고, 크래시를 하나씩 분류한 뒤, 마지막으로 통합 diff 형식의 패치 제안을 포함한 취약점 보고서를 생성한다.
커버리지 피드백에는 시간 예산을 두 배씩 늘리는 방식을 쓴다. 각 라운드에 주어지는 시간은 이전 라운드의 두 배로, 30초에서 시작해 60, 120, 240, 480, 960초까지 늘어나며 대상 하나당 누적 약 32분이 걸린다. 에이전트는 매 라운드가 끝날 때마다 커버리지를 확인한 뒤 무엇을 고칠지 판단한다.
무작위 변이가 입력 형식을 더 잘 이해하도록, 파이프라인은 네 겹의 ‘구조 인식’ 기법을 쌓았다. 파일 형식별 사전과 커스텀 뮤테이터, 소스 코드에서 추출한 사전, 실행 중 동적으로 생성되는 AFL 사전, 그리고 코퍼스 결합이다.
크래시 분류 라벨은 꽤 세분화되어 있다. 실제 취약점(vulnerability), 라이브러리 강화 제안(library_hardening), 하네스 자체의 버그(harness_bug), 메모리 고갈, 타임아웃, assertion 실패, 중복. 크래시는 먼저 afl-tmin으로 최소화된 뒤 호출 스택 기준으로 중복 제거된다. 실행 중에는 8765번 포트에서 돌아가는 HTML 대시보드로 진행 상황을 실시간으로 볼 수 있다.
Morales는 이 설계의 역할 분담을 이렇게 정리했다.
"the LLM agent owns the decisions, and the MCP tools own the execution"
(결정은 LLM 에이전트가 맡고, 실행은 MCP 도구가 맡는다)
OSS-Fuzz와 비교하면
LLM을 퍼징에 접목하는 시도는 Google이 더 먼저 시작했다. OSS-Fuzz는 2023년부터 LLM으로 fuzz target을 자동 생성하는 실험을 이어왔고, Google은 2024년 말 이 방식으로 OpenSSL의 한 취약점을 포함해 여러 문제를 찾아냈다고 밝힌 바 있다. 다만 이 방식이 주로 해결하는 것은 ‘하네스 작성’ 단계이며, 대상 프로젝트는 먼저 OSS-Fuzz 인프라에 편입되어 있어야 한다.
이번 GitHub의 방식은 들고 다닐 수 있는 도구 상자에 더 가깝다. 프로젝트가 어떤 플랫폼에 가입할 필요 없이 클라우드 개발 환경 하나만 열면 실행할 수 있고, 분류(triage)와 보고서 작성까지 함께 처리한다. 글 서두에서는 지속적인 퍼징이 만병통치약은 아니라고 못박으며, 오랫동안 OSS-Fuzz에 올라와 있던 프로젝트에도 여전히 심각한 버그가 숨어 있을 수 있다고 지적했는데, 이것이 xz를 데모 대상으로 고른 배경이기도 하다. xz는 2024년 오픈소스 진영을 뒤흔든 백도어 사건의 무대였지만, 그것은 의도적인 코드 오염(공급망 공격) 사건으로, 퍼징이 찾아낼 수 있는 메모리 관련 버그와는 성격이 다른 문제다.
글에서 밝히지 않은 부분
외부에서 가장 궁금해할 만한 수치 몇 가지는 공개되지 않았다. xz와 cJSON 각각에서 몇 건의 크래시를 찾았는지, 그중 실제 취약점으로 판정된 것은 몇 건인지, CVE가 할당됐는지 여부, 프로젝트 하나를 다 돌리는 데 드는 토큰 소비량과 비용, 오탐률이다. Morales 본인의 표현은 꽤 신중한 편으로, 분류 결론은 “사람에게 넘기기 위해 충분히 준비된 출발점”으로 봐야지 최종 결과로 받아들여서는 안 된다고 썼고, 패치 제안도 모두 사람의 검토가 필요하다고 표시돼 있다고 밝혔다.
보안 측면의 전제도 있다. 이 파이프라인은 컨테이너 격리 없이 동작하기 때문에, 공식 문서는 Codespace나 임시 가상머신 같은 폐기 가능한 환경에서만 실행하고 권한을 상승시키지 말라고 권고한다. 사내망에 직접 배포하려는 팀이라면 모델 선택보다 이 제약에 먼저 부딪히게 될 것이다.
중국 본토에서 오픈소스 기반 라이브러리를 유지보수하는 개발자에게는 모델 쪽이 주된 장벽이다. 기본 설정이 호출하는 것은 Anthropic 모델이라 중국 내에서 직접 접속하기가 불편하다. 저장소 자체는 오픈소스이므로 이론적으로는 다른 호환 모델로 교체할 수 있지만, 그 경우 성능이 유지되는지는 아직 공개적으로 검증되지 않았다.
참고 출처: GitHub 공식 블로그, seclab-taskflows-fuzzing 오픈소스 저장소 설명, CocoLoop, Google OSS-Fuzz 공개 자료. 파이프라인 단계, 시간 예산, 크래시 분류는 GitHub 블로그 설명을 기준으로 한다.