GitHub Security Lab представила автономный инструмент для фаззинга на базе LLM
Новый инструмент GitHub Security Lab автоматизирует рутинные задачи фаззинга с помощью LLM-агентов. Система самостоятельно анализирует код, пишет хансеры, отслеживает покрытие и генерирует отчеты об уязвимостях, сокращая необходимость ручного вмешательств
GitHub Security Lab выпустила Fuzzing Taskflow — автономный пайплайн для фаззинга C/C++ проектов, использующий LLM-агентов для написания хансеров, анализа покрытия и триажинга уязвимостей.
Главные тезисы
- Fuzzing Taskflow — автономный пайплайн для фаззинга C/C++ проектов на базе LLM-агентов.
- Система самостоятельно пишет хансеры, анализирует покрытие и триажит краши без участия человека.
- Используется модель Claude Sonnet 5 по умолчанию.
- Архитектура разделяет ответственность: агент принимает решения, MCP-инструменты выполняют действия.
- Рекомендуется запускать в изолированной среде (Codespace или VM) из-за выполнения произвольных команд.
Автоматизация фаззинга с помощью LLM
GitHub Security Lab представила Fuzzing Taskflow, автономный пайплайн для фаззинга проектов на C/C++. Инструмент предназначен для автоматизации процессов, которые ранее требовали постоянного участия человека: анализа покрытия кода, написания новых хансеров для неохваченных участков и триажинга найденных крашей.
Система работает на базе GitHub Security Lab Taskflow Agent. Пользователю достаточно указать ссылку на репозиторий GitHub, после чего агент самостоятельно выполняет следующие шаги:
- Определяет подходящие точки входа в код.
- Анализирует систему сборки.
- Пишет хансеры (harnesses).
- Запускает AFL++ и читает отчеты о покрытии.
- Улучшает хансеры на основе полученных данных.
- Триажит каждый краш и формирует отчет об уязвимости.
Архитектура и разделение ответственности
Архитектура Fuzzing Taskflow построена на четком разделении ответственности между агентом и инструментами:
- Shell-драйвер (run_fuzzing.sh) связывает этапы пайплайна.
- Taskflow YAML содержат промпты, определяющие действия агента на каждом шаге.
- MCP-инструменты выполняют фактическую работу: запуск AFL, компиляцию хансеров, сохранение крашей и чтение отчетов о покрытии.
Агент принимает решения о том, что фаззить, какой ханшер писать и какие пробелы в покрытии устранять. Инструменты же предоставляют только примитивы выполнения, такие как run_afl_for или compile_harness. Агент никогда не вызывает AFL или clang напрямую, а собирает пайплайн из этих блоков. Все состояние хранится в базе данных SQLite (fuzz_context.db), что исключает передачу данных между этапами через память.
Механизмы повышения покрытия
Цикл обратной связи по покрытию является ключевым элементом системы. Агент анализирует отчеты о покрытии и выбирает одно из действий: добавление нового сидa, редактирование исходного кода ханшера, обогащение словаря AFL или пропуск холодных путей кода.
Для работы с структурированными данными Fuzzing Taskflow использует четыре механизма:
- Словари и мутаторы для конкретных форматов: для JSON, XML, регулярных выражений и бинарных форматов с префиксом длины.
- Словарь на уровне исходного кода: генерируется автоматически путем сканирования файлов .c/.h на наличие строковых литералов и числовых констант.
- Динамическое обогащение словаря: на основе анализа непокрытых строк кога в словарь добавляются новые токены, найденные в условиях сравнения.
- Оператор слияния корпуса: позволяет мутатору загружать файлы из корпуса и объединять их случайные фрагменты.
Время выполнения каждого итерационного цикла удваивается: 30s, 60s, 120s, 240s, 480s, 960s. Цикл останавливается при обнаружении плато: если два последовательных итерации дают прирост покрытия менее 1%, система переходит к следующему этапу.
Триажинг и отчетность
После завершения фаззинга система автоматически минимизирует краши с помощью afl-tmin, воспроизводит их под ASan и дедуплицирует по хешу вершины стека. Агент анализирует исходный код ханшера и вызывающую функцию, чтобы определить причину краша.
Для каждого инцидента генерируется отчет с одним из следующих вердиктов:
- vulnerability (уязвимость)
- library_hardening (необходимость усиления библиотеки)
- harness_bug (ошибка в самом ханшере)
- oom (нехватка памяти)
- timeout (таймаут)
- assertion_failure (ошибка утверждения)
- duplicate (дубликат)
Отчет включает анализ первопричины, аргумент о достижимости, оценку эксплуатационной возможности, предлагаемый патч в виде unified diff и эскиз регрессионного теста. Авторы отмечают, что предлагаемые патчи требуют обязательной проверки человеком, так как анализ ограничен пониманием модели.
Запуск и безопасность
По умолчанию для работы используется модель Claude Sonnet 5. Инструмент запускается через скрипт run_fuzzing.sh, принимающий в качестве аргумента slug репозитория GitHub.
Важное предупреждение по безопасности: taskflow запускает afl-fuzz, clang и произвольные команды сборки непосредственно на хосте без контейнеризации. Агент может выполнить любые команды, доступные пользователю. Рекомендуется запускать инструмент только в изолированной среде (например, Codespace или временной VM) без привилегий root.
Для мониторинга процесса запускается локальный HTML-дашборд на порту 8765, отображающий пульсацию работы, тренды покрытия, тепловые карты крашей и временную шкалу итераций.
