GitHub Security Lab представил описание открытого конвейера под названием Fuzzing Taskflow, предназначенного для автоматизации значительной части тестирования проектов C/C++ с помощью фаззинга (fuzzing) и агентов языковых моделей. При указании на репозиторий GitHub конвейер способен анализировать систему сборки, определять подходящие точки входа, создавать fuzz harnesses, запускать AFL++, читать отчёты о покрытии, улучшать инструменты, классифицировать сбои и подготавливать отдельный отчёт для каждой потенциальной проблемы.
Проект построен поверх фреймворка GitHub Security Lab Taskflow Agent, который представляет рабочий процесс в виде набора потоков, выполняемых агентом от начала до конца. Автор материала, Antonio Morales, отмечает, что цель заключается не в устранении роли исследователя, а в передаче агенту повторяющихся задач, отнимающих много времени, при сохранении разделения решений и исполнения на двух уровнях.
Как работает конвейер?
Использование начинается с репозитория проекта, например с запуска команды ./scripts/fuzzing/run_fuzzing.sh PROJECT внутри Codespace. Конвейер устанавливает инструменты, клонирует репозиторий, анализирует важные функции, затем создаёт цели fuzzing и запускает для них кампании. Его структура включает shell-оболочку, YAML-файлы, описывающие этапы работы и инструкции для модели, а также инструменты MCP, выполняющие такие операции, как запуск AFL, компиляция инструментов, чтение покрытия и сохранение сбоев.
Агент не вызывает AFL или clang напрямую: он решает, что следует тестировать и какой пробел в покрытии заслуживает дальнейшей работы, тогда как инструменты MCP выполняют низкоуровневые операции. Состояние хранится в базе данных SQLite с именем fuzz_context.db, что позволяет передавать результаты между этапами без использования общей памяти.
Цикл улучшения покрытия
Каждый harness собирается дважды: версия .afl для управления AFL с использованием соответствующих инструментов компиляции, и версия .cov для повторного запуска списка входных данных и измерения покрытия строк и ветвей. После каждого раунда агент анализирует непокрытые ветви, а затем выбирает такое действие, как добавление нового seed, изменение исходного кода harness для вызова другого интерфейса, расширение словаря AFL значениями, проверяемыми кодом, или игнорирование холодного пути, не оправдывающего затрат.
Временной бюджет увеличивается с 30 до 60, 120, 240, 480 и 960 секунд, то есть до примерно 32 минут на каждую цель в указанном максимуме. Конвейер останавливается при обнаружении снижения отдачи: если два последовательных раунда обеспечили менее одного процентного пункта покрытия строк, согласно настраиваемому значению по умолчанию, он переходит к другой цели.
Работа с входными данными и сбоями
Конвейер поддерживает специализированные механизмы для форматов JSON и XML, регулярных выражений, PNG и двоичного TLV со встроенными длинами, а также умеет создавать словарь из строковых и числовых констант, содержащихся в файлах C и H. После каждого этапа покрытия он также обогащает этот словарь на основе проверок, расположенных рядом с непокрытыми строками. Кроме того, каждый harness сохраняет постоянную папку corpus и использует afl-cmin для уменьшения её размера, сохраняя полезные входные данные между раундами и кампаниями.
После завершения кампании сбои минимизируются с помощью afl-tmin, повторно запускаются под AddressSanitizer, а затем дубликаты удаляются на основе отпечатка вершины стека. Конвейер также повторно тестирует известные сбои для проверки эффекта исправлений и классифицирует результаты по категориям: уязвимость, усиление библиотеки, ошибка в harness, исчерпание памяти, тайм-аут, сбой assertion или дубликат.
Почему эта новость важна?
Практическая ценность заключается в попытке автоматизировать цикл, который часто ограничивает эффективность непрерывного фаззинга: написание harnesses, чтение покрытия, выбор следующего пробела и классификация сбоев. Это может снизить стоимость начала тестирования проекта, который ранее не подвергался фаззингу, или помочь расширить покрытие уже существующего проекта.
Однако GitHub Security Lab устанавливает существенное ограничение: конвейер напрямую запускает afl-fuzz, clang и выбранные моделью команды сборки на хост-системе, без изолирующего контейнера. Поэтому агент, подвергшийся инъекции инструкций, может выполнить всё, что разрешено пользователю. Проект рекомендует запускать его в одноразовой среде, например в Codespace или временной виртуальной машине, и без повышенных привилегий.
Кроме того, отчёты об уязвимостях и предлагаемые исправления не являются окончательными результатами. В материале подчёркивается, что анализ модели может содержать ошибки, а предлагаемая заплатка помечена как требующая проверки. Таким образом, Fuzzing Taskflow представляет собой хорошо подготовленную отправную точку для исследователя, а не замену человеческой проверке достижимости, эксплуатируемости и первопричины.