깃허브 보안연구소(GitHub Security Lab)가 2026년 9월 24일 공식 블로그에서 LLM 기반 퍼징 파이프라인 Fuzzing Taskflow를 오픈소스로 공개했다. 깃허브 저장소 주소 하나만 주면 진입점 자동 식별, 테스트 하네스 작성, AFL++ 실행, 커버리지 리포트 판독, 테스트 케이스 개선을 거쳐 각 크래시를 취약점 보고서로 트리아지하기까지 전부 알아서 처리한다. 사람이 지켜볼 필요가 없다.
명령어 한 줄이면 파이프라인이 알아서 돈다
보안 도구라고는 믿기 어려울 만큼 사용법이 간단하다. 코드는 깃허브에 공개돼 있다(조직명 GitHubSecurityLab, 프로젝트명 seclab-taskflows-fuzzing). Codespace를 열고 ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz를 실행하면 나머지는 에이전트가 알아서 한다. AFL 의존성 설치, 저장소 클론, 코드에서 테스트할 만한 함수 찾기, 그 함수용 퍼즈 타깃 생성이 자동으로 진행된다.
작성자 안토니오 모랄레스(Antonio Morales)는 블로그에서 분명한 경고를 덧붙였다. 이 파이프라인은 afl-fuzz, clang, LLM이 직접 선택한 임의의 빌드 명령을 호스트 머신에서 직접 실행하며, 사이에 컨테이너 격리가 없다는 것이다. 프롬프트 인젝션된 에이전트는 이론상 사용자 계정이 할 수 있는 것은 무엇이든 할 수 있으므로, 반드시 일회성 환경(Codespace나 쓰고 버리는 VM)에서만 실행하고 권한 상승은 절대 금지다.
에이전트는 판단, 도구는 실행
Fuzzing Taskflow는 GitHub Security Lab의 Taskflow Agent 프레임워크 위에 구축됐으며, 파이프라인 전체가 일련의 taskflow로 표현돼 에이전트가 엔드투엔드로 실행한다. 아키텍처는 3층 구조다. 각 단계를 잇는 셸 스크립트, 각 단계의 프롬프트를 기술한 YAML taskflow들, 그리고 AFL 실행·하네스 컴파일·크래시 저장·커버리지 리포트 판독 등 실제 일을 하는 MCP 도구들이다.
설계상 분업은 명확하다. LLM 에이전트가 판단권을 쥐고 무엇을 테스트할지, 어떤 하네스를 쓸지, 다음에 어떤 커버리지 공백을 쫓을지를 결정한다. MCP 도구는 실행 원시 명령만 제공한다. 에이전트는 AFL이나 clang을 직접 호출하지 않고, 이 빌딩 블록으로 파이프라인을 조립한다. 모든 단계의 상태는 SQLite 데이터베이스에 저장되며, 단계 간 메모리 데이터를 직접 주고받지 않는다.
기본 모델은 Claude Sonnet 5로, 내부 테스트를 전부 통과하고 안전 가드레일을 발동시키지 않아 선정됐다. 모델을 바꾸려면 src/seclab_taskflows_fuzzing/configs/model_config.yaml을 수정하면 된다.
핵심은 커버리지 피드백 루프
수동 퍼징에서 가장 손이 많이 가는 두 단계는 커버리지 리포트를 읽고 커버되지 않은 브랜치를 찾는 것, 그리고 그 브랜치용 새 하네스를 쓰는 것이다. Fuzzing Taskflow는 이 두 단계를 에이전트에게 맡긴다. 매 라운드 각 하네스에 AFL 실행 시간 예산을 주고, 실행 후 큐를 리플레이해 실제 라인·브랜치 커버리지를 생성한 뒤, 커버되지 않은 브랜치를 읽고 다음 중 하나를 선택한다. 해당 브랜치를 직격하는 새 시드 추가, 하네스를 바꿔 다른 API 호출, 가드 조건을 지키는 매직 넘버를 AFL 딕셔너리에 자동 보충, 혹은 찬밥 신세인 에러 경로로 판단하고 건너뛰기.
시간 예산은 라운드마다 두 배로 늘어난다. 30초, 60초, 120초, 최대 약 32분. 언제 멈추는가? "정체 탐지"다. 연속 두 라운드에서 절대 라인 커버리지 증가폭이 1% 미만이면 수확 체감으로 판단해 다음 타깃으로 넘어간다. 마지막 몇 퍼센트를 쥐어짜느라 컴퓨팅 자원을 태우지 않는다.
JSON, XML, 정규식, PNG 같은 구조적 입력에는 네 가지 상호 보완 메커니즘이 준비돼 있다. 사전 구축된 형식 딕셔너리와 커스텀 변이자, 타깃 소스코드에서 문자열 상수를 스캔해 자동 생성하는 소스 레벨 딕셔너리, 커버리지에 따라 동적으로 성장하는 딕셔너리, 그리고 코퍼스 스플라이싱 연산자다.
가장 골치 아픈 크래시 트리아지도 자동화
크래시를 찾는 건 일의 절반이고, 트리아지가 더 시간이 많이 걸리는 경우가 많다. 퍼징이 끝나면 파이프라인이 자동으로 3단계를 밟는다. 각 크래시를 afl-tmin으로 최소화하고 ASan 하에서 리플레이해 스택을 확보한 뒤 "스택 탑 해시"로 중복을 제거한다. 다음으로 과거에 알려진 크래시를 전부 새 바이너리에서 리플레이해 업스트림 수정으로 이미 해결됐는지 확인한다. 마지막으로 에이전트가 하네스 소스와 크래시 함수를 읽고 호출 체인을 거슬러 올라가며, 각 크래시마다 마크다운 보고서를 작성한다.
각 보고서에는 판정이 붙는다. 진짜 vulnerability, library_hardening, 하네스 자체의 버그, OOM, 타임아웃, 어서션 실패, 중복 중 하나다. "진짜 버그"와 "하네스를 잘못 쓴 것"을 가르는 판단이야말로 예전에는 사람이 앉아서 코드를 한 줄씩 따라가야만 가능했던 일이다. 각 보고서에는 근본 원인 분석(파일·라인 번호 포함), 도달 가능성 논증, 악용 가능성 평가, "사람 검토 필요"라고 명시된 unified diff 형식 수정 제안, 회귀 테스트 초안도 포함된다.
실행 후에는 8765 포트에서 실시간 대시보드가 열려 각 하네스의 하트비트, 커버리지 추이, 크래시 히트맵, 반복 타임라인을 볼 수 있다.
오픈소스 유지보수가 먼저 시도해 볼 만하다
가장 직접적인 수혜자는 "퍼징해야 한다는 건 아는데 인력이 없는" C/C++ 오픈소스 프로젝트 유지보수자다. OSS-Fuzz 도입 후에도 하네스 작성, 커버리지 감시, 크래시 트리아지는 사람 몫으로 남았는데, 그 부분을 에이전트가 가져간다. 물론 모랄레스 본인도 인정하듯 에이전트의 판정은 어디까지나 "잘 준비된 출발점"이지 최종 결론이 아니다. 보고서의 수정 제안에 "검토 필요"라고 적혀 있는 데는 이유가 있다.
흥미로운 건 코드 보안에 AI를 들이는 곳이 깃허브만이 아니라는 점이다. 본지는 앞서 Cursor의 Security Reviewer를 보도했는데, 저쪽은 "PR마다 스캔" 방식, 깃허브의 이것은 "깊이 파고드는 퍼즈" 방식이다. 증분 코드를 지키는 쪽과 기존 코드를 지키는 쪽이 서로 딱 맞물려 보완된다.
