Интеллектуальная фаззинговая уязвимость: как GitHub Security Lab автоматизирует поиск ошибок в коде с помощью ИИ

# Умная безопасность кода: автоматизация поиска уязвимостей с помощью ИИ

Современная практика непрерывной фаззинговой проверки (continuous fuzzing) часто сталкивается с одной проблемой: она не является магическим решением. Даже проекты, подключенные к системам автоматической проверки безопасности годами, могут скрывать критические ошибки. Основная причина банальна: кто-то должен следить за покрытием кода, писать новые тестовые наборы для недостижимых участков и сортировать возникающие сбои. Человеческий фактор в этом цикле по-прежнему необходим.

Команда GitHub Security Lab предлагает новый подход. Они разработали Fuzzing Taskflow — автономный конвейер для фаззинга проектов на C/C++. Система позволяет пользователю просто указать репозиторий GitHub, после чего агент самостоятельно идентифицирует точки входа, проанализирует систему сборки, напишет тестовые программы (harnesses), запустит движок AFL++, проанализирует отчеты о покрытии, улучшит тесты, отсортирует каждый найденный краш и подготовит отчет об уязвимости для каждой обнаруженной проблемы.

Архитектура автономного агента

Fuzzing Taskflow построен на основе фреймворка GitHub Security Lab Taskflow Agent. В основе дизайна лежит четкое разделение ответственности: ИИ-агент принимает решения, а инструменты (MCP tools) отвечают только за выполнение. Агент решает, что нужно фаззить, как изменить тестовый код и какие пробелы в покрытии проработать дальше. Инструменты же предоставляют примитивы для запуска AFL или компиляции кода. Агент никогда не вызывает эти утилиты напрямую, а конструирует конвейер из готовых блоков.

Все данные между этапами передаются через SQLite-базу данных, а не по памяти, что обеспечивает стабильность процесса. Для работы системы используются два типа бинарных файлов для каждого тестового набора: один для фаззинга с инструментами AFL, второй для воспроизведения сессии и генерации отчетов о покрытии источника и веток кода.

Система запускается через простой скрипт, который принимает ссылку на репозиторий. Агент самостоятельно устанавливает необходимое программное обеспечение (включая AFL), кlonирует код и ищет наиболее релевантные функции.

*Осторожно: данный скрипт запускает компилятор и инструменты фаззинга прямо на хостовой машине без изоляции в контейнере. Рекомендуется запускать его в одноразовой среде, например, в Codespace или выделенной виртуальной машине без повышенных привилегий.*

Цикл обратной связи и адаптация

Сердцем системы является цикл обратной связи покрытия, который автоматизирует рутинную работу человека. Вручную этот процесс выглядит так: специалист запускает фаззинг, проверяет отчеты покрытия, находит незакрытые ветки кода и пишет новый тест, чтобы их достичь.

Агент повторяет этот цикл итеративно. На каждом этапе он запускает AFL в течение заданного времени, после чего воспроизводит очередь найденных входов на специальном бинарнике для получения точных данных о покрытии. Затем агент анализирует список незакрытых веток и выбирает одно из действий:

* Создать новый тестовый ввод (seed), специально сконструированный для прохождения через незакрытую ветку. * Изменить исходный код тестовой программы, чтобы вызвать дополнительный API. * Расширить словарь AFL магическими константами, которые используются в контрольных выражениях кода. * Пропустить путь, если он является редким ошибочным сценарием или частью защищенного кода вендора.

Время, выделяемое на фаззинг, удваивается с каждой итерацией: от 30 секунд на ранних этапах (когда легко найти "низовисящие" фрагменты) до почти 32 минут на финальных стадиях, когда фаззеру требуется больше времени для преодоления сложных защит.

Цикл останавливается автоматически по обнаружению плато: когда два последовательных итерации дают прирост покрытия менее 1%, система считает, что дальнейшие усилия неэффективны.

Структурированный фаззинг и эволюция корпуса

Движок AFL+ отлично справляется с бинарными форматами, но испытывает трудности со структурированными текстовыми данными. Обычно для таких случаев пишут кастомные мутаторы вручную. Fuzzing Taskflow делает это автоматически с помощью четырех механизмов:

1. Готовые словари и мутаторы: Для известных форматов (JSON, XML, регулярные выражения) система использует предопределенные словари и логику мутации, учитывающую балансировку скобок, тэги и паттерны ReDoS. 2. Словарь на уровне кода: Для неопознанных форматов система сканирует исходные файлы проекта, извлекая строковые литералы и числовые константы, которые могут служить магическими ключами для парсера. 3. Динамическое обогащение: Система создает словарь, который растет в процессе работы, добавляя новые токены, найденные рядом с неосвоенными строками кода (например, результаты сравнения строк или проверка на равенство). 4. Сплайсинг корпуса: Умный мутатор может комбинировать случайные фрагменты из накопленного корпуса файлов, что недоступно стандартным мутаторам.

Эволюция корпуса также решается автоматически. Система сохраняет накопленный список интересных входов, чтобы новые запуски не начинались с нуля. Это позволяет сохранять прогресс и избегать повторного прохождения одних и тех же путей.

В системе также реализован триаж (сортировка) найденных крашей и генерация отчетов об уязвимостях, что является заключительным этапом автоматизации процесса поиска дефектов.

Заключение

Fuzzing Taskflow демонстрирует, насколько далеко можно зайти в автоматизации процессов безопасности. Используя комбинацию LLM и специализированных инструментов, GitHub создает систему, которая не только находит ошибки, но и адаптирует свою стратегию поиска в реальном времени. Это не замена человеку полностью, как заявляет автор поста, но мощная помощь, которая освобождает инженеров от монотонной рутины, позволяя сосредоточиться на сложной аналитике и принятии стратегических решений.