GitHub Security Lab은 퍼징(fuzzing)과 언어 모델 에이전트를 사용해 C/C++ 프로젝트 테스트의 상당 부분을 자동화하도록 설계된 Fuzzing Taskflow라는 오픈 소스 워크플로를 소개했다. 이 워크플로는 GitHub 저장소를 대상으로 실행하면 빌드 시스템을 분석하고, 적절한 진입점을 식별하며, 퍼즈 하니스(fuzz harnesses)를 생성하고, AFL++를 실행하며, 커버리지 보고서를 읽고, 하니스를 개선하고, 크래시를 분류해 잠재적인 각 문제에 대한 별도 보고서를 작성할 수 있다.
이 프로젝트는 GitHub Security Lab Taskflow Agent 프레임워크 위에 구축되었다. 이 프레임워크는 에이전트가 처음부터 끝까지 실행하는 일련의 워크플로로 작업 과정을 표현한다. 글의 작성자인 Antonio Morales는 목표가 연구자의 역할을 없애는 것이 아니라, 많은 시간을 소모하는 반복 작업을 에이전트로 넘기고 의사 결정과 실행을 두 개의 별도 계층으로 유지하는 것이라고 설명한다.
워크플로는 어떻게 작동하는가?
사용은 프로젝트 저장소에서 시작되며, 예를 들어 Codespace 안에서 ./scripts/fuzzing/run_fuzzing.sh PROJECT 명령을 실행한다. 워크플로는 도구를 설치하고 저장소를 복제하며 중요한 함수를 분석한 다음 퍼징 대상을 생성하고 이에 대한 캠페인을 실행한다. 구조는 셸 실행기, 작업 단계와 모델에 전달되는 지침을 설명하는 YAML 파일, 그리고 AFL 실행, 하니스 컴파일, 커버리지 읽기, 크래시 저장 등의 작업을 수행하는 MCP 도구로 구성된다.
에이전트는 AFL이나 clang을 직접 호출하지 않는다. 무엇을 테스트해야 하는지, 어떤 커버리지 공백을 후속 조사할 가치가 있는지를 결정하고, MCP 도구가 저수준 작업을 수행한다. 상태는 fuzz_context.db라는 SQLite 데이터베이스에 저장되므로 공유 메모리에 의존하지 않고 단계 간 결과를 전달할 수 있다.
커버리지 개선 루프
각 하니스는 두 번 빌드된다. 하나는 적절한 계측 도구를 사용해 AFL을 유도하는 .afl 버전이고, 다른 하나는 입력 목록을 다시 실행해 라인 및 브랜치 커버리지를 측정하는 .cov 버전이다. 각 라운드가 끝나면 에이전트는 커버되지 않은 브랜치를 검토한 뒤 새 시드를 추가하거나, 다른 인터페이스를 호출하도록 하니스 소스를 수정하거나, 코드가 검사하는 값으로 AFL 사전을 보강하거나, 비용을 들일 가치가 없는 비활성 경로를 무시하는 등의 조치를 선택한다.
시간 예산은 30초에서 시작해 60초, 120초, 240초, 480초, 960초로 두 배씩 늘어난다. 즉, 언급된 최대 기준으로 각 대상에 약 32분이 할당된다. 두 번 연속으로 라인 커버리지가 1퍼센트포인트 미만 증가하면, 조정 가능한 기본값에 따라 워크플로는 수익률 하락을 감지하고 다른 대상으로 넘어간다.
입력과 크래시 처리
이 워크플로는 JSON, XML, 정규 표현식, PNG, 그리고 길이가 내장된 바이너리 TLV 형식을 위한 전용 메커니즘을 지원한다. 또한 C 및 H 파일에 있는 문자열 및 숫자 상수에서 사전을 생성할 수 있다. 커버리지 단계가 진행될 때마다 커버리지되지 않은 라인 근처의 조건문을 바탕으로 이 사전을 보강한다. 각 하니스는 고정된 corpus 디렉터리를 유지하며, afl-cmin을 사용해 크기를 줄이면서 라운드와 캠페인 사이에 유용한 입력을 보존한다.
캠페인이 끝나면 afl-tmin을 사용해 크래시 입력을 축소하고, AddressSanitizer에서 다시 실행한 뒤, 최상위 스택 프레임의 지문을 바탕으로 중복을 제거한다. 또한 워크플로는 알려진 크래시를 다시 테스트해 수정 사항의 효과를 확인하고, 결과를 취약점, 라이브러리 강화, 하니스 오류, 메모리 부족, 시간 초과, assertion 실패, 중복을 포함한 범주로 분류한다.
이 소식이 중요한 이유
실질적인 가치는 지속적인 퍼징의 효율을 제한하는 경우가 많은 루프, 즉 하니스 작성, 커버리지 검토, 다음 공백 선택, 크래시 분류를 자동화하려 한다는 데 있다. 이를 통해 이전에 퍼징을 수행하지 않았던 프로젝트의 테스트 시작 비용을 낮추거나, 기존 프로젝트의 커버리지를 확대하는 데 도움이 될 수 있다.
그러나 GitHub Security Lab은 중요한 제한 사항을 제시한다. 이 워크플로는 별도의 컨테이너 없이 호스트 시스템에서 afl-fuzz, clang 및 모델이 직접 선택한 빌드 명령을 실행한다. 따라서 명령어 주입의 영향을 받은 에이전트가 사용자가 실행할 수 있는 작업을 수행할 수 있다. 프로젝트는 Codespace나 임시 가상 머신처럼 폐기 가능한 환경에서, 높은 권한 없이 실행할 것을 권장한다.
또한 취약점 보고서와 제안된 수정 사항은 최종 결과가 아니다. 글은 모델의 분석이 잘못될 수 있으며, 제안된 패치에는 검토가 필요하다는 표시가 붙는다고 강조한다. 따라서 Fuzzing Taskflow는 연구자를 위한 잘 준비된 출발점이지, 도달 가능성, 악용 가능성 및 근본 원인에 대한 사람의 검증을 대신하는 도구는 아니다.