GitHub 시큐리티 랩, LLM 자동 퍼징 파이프라인 'Fuzzing Taskflow' 공개

3분 GitHub Security LabfuzzingLLM agentAFL++
최근 30일 조회수 — 좋아요 —

핵심 요약

GitHub 시큐리티 랩이 저장소 주소만 넣으면 하네스 작성부터 크래시 트리아지까지 자동 수행하는 LLM 퍼징 파이프라인을 공개했다.

GitHub 시큐리티 랩이 C/C++ 프로젝트의 퍼징 과정을 LLM 에이전트에게 맡기는 자동화 파이프라인 ‘Fuzzing Taskflow’를 공개했다. GitHub 블로그에 따르면 이 도구는 GitHub 저장소 주소 하나만 입력받으면 진입점 식별부터 하네스 작성, AFL++ 실행, 크래시 트리아지, 취약점 보고서 작성까지 사람 개입 없이 전 과정을 수행한다.1

이 프로젝트는 GitHub 시큐리티 랩이 LLM 기반 보안 자동화를 위해 만든 프레임워크 ‘Taskflow Agent’ 위에서 동작한다. 저장소는 GitHubSecurityLab/seclab-taskflows-fuzzing에 공개돼 있고, 코드스페이스(Codespace)에서 ./scripts/fuzzing/run_fuzzing.sh PROJECT 명령 하나로 실행할 수 있다. 블로그 글쓴이는 tukaani-project/xz를 예로 들었고, 짧은 테스트용으로는 규모가 작은 DaveGamble/cJSON을 추천했다.

블로그 글쓴이가 이 도구를 만든 이유는 연속 퍼징(continuous fuzzing)의 한계 때문이다. OSS-Fuzz에 수년간 등록된 프로젝트라도 여전히 심각한 버그를 놓치는 경우가 있는데, 원인은 대개 같다. 커버리지를 계속 살피고, 아무도 도달하지 못하는 코드에 새 하네스를 써주고, 쏟아지는 크래시를 분류할 사람이 필요하다는 것이다. 글쓴이는 이 반복 작업 중 얼마나 많은 부분을 LLM 에이전트에게 넘길 수 있는지 묻는 데서 출발했다고 밝혔다.

구조는 세 층으로 나뉜다. 파이프라인 단계를 이어 붙이는 셸 드라이버 run_fuzzing.sh, 각 단계에서 에이전트에게 무엇을 할지 지시하는 프롬프트 역할의 태스크플로 YAML 파일들, 그리고 에이전트가 실제 작업을 실행할 때 호출하는 MCP(Model Context Protocol) 툴들이다. 설계 원칙은 역할 분리다. LLM 에이전트는 무엇을 퍼징할지, 어떤 하네스를 쓸지, 어떤 커버리지 공백을 쫓을지 같은 판단만 맡고, run_afl_for나 compile_harness 같은 실행 primitive는 MCP 툴이 담당한다. 에이전트는 AFL이나 clang을 직접 호출하지 않고 이 도구들을 조합해서 파이프라인을 구성하며, 전체 상태는 SQLite 데이터베이스(fuzz_context.db)에 저장돼 각 단계가 끊김 없이 이어진다.

기본 모델은 Claude Sonnet 5다. GitHub 시큐리티 랩은 일부 프런티어 모델이 출력에 보안 가드레일을 걸어놓는데, 내부 테스트를 문제없이 통과한 모델이 Sonnet 5였다고 밝혔다. 다른 모델을 쓰려면 src/seclab_taskflows_fuzzing/configs/model_config.yaml 설정을 바꾸면 된다.

WARNING

이 태스크플로는 afl-fuzz와 clang, 그리고 LLM이 스스로 선택한 빌드 명령을 컨테이너 없이 호스트에서 직접 실행한다. 블로그는 프롬프트 인젝션에 당한 에이전트가 원칙적으로 사용자 권한으로 무엇이든 할 수 있다고 경고하며, 코드스페이스나 일회용 가상머신처럼 폐기 가능한 환경에서 권한을 낮춰 실행할 것을 권고했다.

Footnotes

  1. GitHub Blog, “AI-powered fuzzing with the GitHub Security Lab Taskflow Agent” ↩

읽기 목록은 이 브라우저에 저장됩니다.

출처

  1. AI-powered fuzzing with the GitHub Security Lab Taskflow Agent — GitHub Blog

이 글은 위 출처를 근거로 자동 생성된 뒤 발행됐습니다. 원문을 함께 확인해 주세요. 교차 보도 없이 단독 출처로 작성됐습니다.