GitHub Security Lab, AI 퍼징 워크플로 Fuzzing Taskflow 공개: AI 에이전트가 C/C++ 취약점을 자동으로 찾는다

GitHub가 발표한 내용

GitHub 블로그는 2026년 9월 24일 Antonio Morales가 쓴 글을 게재해 Fuzzing Taskflow라는 새로운 워크플로를 소개했다. 글에 따르면 이 워크플로는 GitHub Security Lab Taskflow Agent를 기반으로 한다. Taskflow Agent는 GitHub가 대규모 언어 모델 기반 보안 자동화를 작성하는 데 쓰는 프레임워크다. 작성자는 Fuzzing Taskflow를 C/C++ 프로젝트를 위한 자율 퍼징 워크플로라고 설명한다.

퍼징(fuzzing)은 자동으로 생성한 대량의 입력으로 프로그램을 테스트해 크래시(프로그램이 비정상 종료되는 현상)와 잠재적 취약점을 찾는 기법이다. 작성자는 지속적 퍼징이 만능은 아니라고 지적한다. OSS-Fuzz에 수년간 참여한 프로젝트에도 심각한 버그가 숨어 있을 수 있다는 것이다. 여전히 누군가 커버리지(테스트가 실제로 실행해 본 코드의 범위)를 지켜보고, 도달하지 못한 코드를 위해 새 테스트 하네스(테스트할 코드에 입력을 넣어 주는 작은 프로그램)를 작성하고, 나온 크래시를 분류해야 하기 때문이다. Fuzzing Taskflow는 바로 이 수작업을 AI 에이전트에 맡기려는 시도다.

자세한 설명 보기

출처를 수집하고 독립적으로 검증한 뒤 Jev가 판단합니다.

GitHub 설명에 따르면 사용자는 GitHub 저장소 하나만 지정하면 된다. 그러면 워크플로가 적절한 진입점을 식별하고, 빌드 시스템을 분석하고, 테스트 하네스를 작성한다. 이어 퍼징 도구인 AFL++를 실행하고, 커버리지 보고서를 읽고, 하네스를 개선하고, 모든 크래시를 분류하며, 고유한 버그마다 취약점 보고서를 작성한다. 글에 따르면 도구는 GitHubSecurityLab/seclab-taskflows-fuzzing 저장소에 있다. 팀의 모든 내부 테스트를 통과했다는 이유로 기본 모델로 Claude Sonnet 5를 사용하며, 사용자는 설정 파일로 모델을 바꿀 수 있다.

작동 방식: 결정은 AI가, 실행은 도구가

글에 따르면 전체 구조는 세 계층으로 나뉜다. 첫째는 각 단계를 연결하는 셸 드라이버다. 둘째는 단계마다 하나씩 있는 taskflow YAML로, 사실상 에이전트에게 각 단계에서 할 일을 알려주는 프롬프트다. 셋째는 에이전트가 실제 작업을 수행하기 위해 호출하는 MCP 도구다. 작성자는 가장 중시한 설계 원칙이 명확한 역할 분담이라고 밝혔다. 대규모 언어 모델 에이전트는 결정을 내리고 MCP 도구가 실행을 맡으며, 에이전트는 AFL이나 clang을 직접 호출하지 않는다. 모든 상태는 SQLite 데이터베이스에 저장된다.

글은 또한 각 테스트 하네스가 두 번 빌드된다고 언급한다. .afl 버전은 실제 퍼징을 담당한다. .cov 버전은 이후 AFL의 테스트 큐를 재생해 실제 소스 코드 라인 및 분기 커버리지 보고서를 생성한다.

커버리지 피드백 루프와 중단 조건

작성자는 과거에 커버리지 확인과 커버리지 개선이라는 두 단계를 직접 수행했다고 말한다. 예를 들어 LCOV 보고서를 읽으며 테스트가 닿지 못한 분기를 찾는 식이었다. Fuzzing Taskflow는 이 두 단계를 모두 에이전트에 맡긴다. 글에 따르면 에이전트는 매 반복마다 다음 중 하나를 선택할 수 있다. 닿지 못한 분기를 겨냥한 시드 입력(퍼징의 출발점이 되는 예시 입력) 추가, 더 많은 API를 호출하도록 하네스 편집, AFL 사전 자동 확장, 또는 추적할 가치가 없는 공백 건너뛰기다.

시간 예산은 반복마다 두 배로 늘어 30초, 60초, 120초, 240초, 480초, 960초로 이어지며 대상당 약 32분이 소요된다. 워크플로는 정체기 감지를 사용한다. 연속 두 번의 반복에서 증가폭이 모두 설정 가능한 임계값 미만이면, 더 돌려도 얻는 것이 적다고 판단하고 다음 단계로 넘어간다. 기본 임계값은 절대 라인 커버리지 1%다.

구조 인식 입력

글에 따르면 워크플로는 입력 형식의 구조를 고려한 입력을 만들기 위해 네 가지 상호 보완적 메커니즘을 제공한다. JSON, XML, 정규 표현식, PNG, 길이 접두 바이너리 TLV 등 식별 가능한 형식에는 미리 만든 AFL 사전과 커스텀 뮤테이터(입력을 변형하는 모듈)가 포함되어 있다. 식별할 수 없는 형식의 경우 대상 프로젝트 자체의 .c/.h 파일을 스캔한다. 그리고 문자열 리터럴과 32비트 숫자 상수를 추출해 입력에 끼워 넣을 조각으로 사용한다.

일반 독자에게 미치는 실제 영향

• 오픈소스 메인테이너: GitHub는 이런 도구를 퍼징에서 사람이 하는 모니터링과 분류 작업을 줄이는 방법으로 제시한다. 다만 실제 효과는 각 프로젝트가 직접 평가해야 한다.
• 일반 사용자: 퍼징의 목적은 소프트웨어 출시 전에 버그를 찾는 것이다. 더 많은 프로젝트가 적은 비용으로 테스트할 수 있다면 장기적으로 자주 쓰는 소프트웨어의 신뢰성 향상에 도움이 될 수 있다. 하지만 이는 추론이며, 글은 효과에 관한 데이터를 제시하지 않았다.
• AI 보안: GitHub 자체의 경고가 보여주듯 AI 에이전트가 명령을 직접 실행하게 하는 것 자체에 프롬프트 인젝션 등의 위험이 따른다. 격리 환경은 여전히 기본 요건이다.
• 정보 출처: 위 내용은 모두 GitHub 자사 블로그에서 나온 것이며, 아직 독립적인 검증은 확인되지 않았다.

자주 묻는 질문

이 주제의 최신 뉴스 보기

• 테크 뉴스