GitHub рассказала о результатах применения GitHub Security Lab Taskflow Agent и новом подходе к использованию больших языковых моделей (LLM) для аудита безопасности открытого кода.
За последние месяцы команда GitHub Security Lab использует Taskflow Agent и новый набор аудиторских сценариев для поиска уязвимостей в веб-приложениях. Эти сценарии уже позволили выявить более 80 уязвимостей в проектах с открытым исходным кодом, около 20 из которых на момент публикации были раскрыты в публичных консультативных отчётах.
Taskflow Agent распространяется как open source-фреймворк и может быть запущен на собственных репозиториях. Для работы требуется лицензия GitHub Copilot, при этом запросы используют премиальные модели. На репозиторий среднего размера анализ занимает примерно час-два, после чего открывается SQLite‑просмотрщик: результаты хранятся в таблице audit_results, где признак уязвимости отмечен в колонке has_vulnerability.
Сценарии работают и с приватными репозиториями GitHub, но для этого нужно изменить конфигурацию Codespaces, так как по умолчанию доступ к частным репозиториям ограничен.
Как устроены taskflows
Taskflows представляют собой YAML-файлы, которые описывают последовательность задач для LLM: отдельные подсказки, их зависимости и передачу результатов между этапами. Фреймворк seclab-taskflow-agent сам запускает задачи по очереди и передаёт вывод одной задачи следующей.
При аудите репозитория сначала код делится на компоненты по функциональности. Для каждого компонента LLM собирает ключевую информацию: входные точки, через которые поступают недоверенные данные, назначение и предполагаемый уровень привилегий. Эти данные сохраняются в базу и используются как контекст для следующих задач.
Далее создаются задачи аудита. В текущей конфигурации есть задача, которая предлагает типовые потенциальные проблемы для каждого компонента, и отдельная задача, которая детально проверяет каждую такую проблему. Можно добавлять и специализированные задачи с фокусом на определённые классы уязвимостей.
GitHub использует набор задач, а не один большой промпт, потому что контекст у LLM ограничен, а сложные многошаговые запросы часто выполняются с ошибками. Taskflows позволяют детально управлять этапами, отлаживать их и масштабировать на крупные проекты.
Фреймворк также умеет запускать одну и ту же задачу по всем компонентам асинхронно по аналогии с циклом. Для этого задаются шаблонные промпты, а seclab-taskflow-agent подставляет в них данные конкретного компонента при запуске.
Контроль галлюцинаций и ложных срабатываний
Ранее GitHub уже применял seclab-taskflow-agent для разбора алертов CodeQL с чёткими и узкими критериями. Для расширенного аудита, где тип уязвимостей заранее не задан, возникла задача снизить риск галлюцинаций и ложных срабатываний, сохранив свободу поиска для LLM.
Новый конвейер строится вокруг нескольких этапов:
- Трудоёмкий этап моделирования угроз: репозиторий делится на компоненты, собираются сведения о входных точках и предполагаемом использовании, определяется граница безопасности и степень экспозиции каждому виду недоверенных входных данных.
- Формирование фокуса аудита: на основе собранной информации LLM предлагает типы уязвимостей и зоны повышенного риска по каждому компоненту, при этом её явно просят избегать малозначимых или не относящихся к безопасности проблем.
- Запрет аудита на этапе генерации идей: чтобы LLM не пыталась сразу проверять найденные идеи в этом же шаге, в инструкциях отдельно указано не проводить аудит на стадии «мозгового штурма».
- Финальный аудит: другая задача с новым контекстом поочерёдно проверяет каждое предложенное потенциальное нарушение, рассматривает код и оценивает, является ли кандидат действительно эксплуатируемой уязвимостью.
На завершающем этапе от LLM требуют конкретный и реалистичный сценарий атаки, подтверждение из исходного кода с указанием пути к файлу и номеров строк, а также допускают, что уязвимостей может не быть. Это снижает риск выдуманных дефектов и вынуждает модель опираться на фактические данные из кода.
По наблюдениям GitHub, значительная часть ложноположительных результатов автоматических сканеров связана не с ошибками анализа, а с недостаточным моделированием угроз. Например, SSRF в реверс‑прокси или удалённое выполнение кода внутри изолированной sandbox‑среды без выхода наружу часто не являются реальной угрозой по замыслу приложения.
Примеры найденных уязвимостей
1. Outline: ошибка в авторизации
Информационные taskflows GitHub оптимизированы под веб-приложения, поэтому одной из первых целей стала система совместной работы Outline. Уже при первом запуске сценарий нашёл ошибку в логике авторизации.
Анализ TypeScript‑кода и проверка на тестовом стенде подтвердили, что уязвимость эксплуатируема так, как описала LLM. Низкопривилегированный пользователь мог добавить произвольные группы к документу, который ему разрешено только редактировать, хотя для таких действий обычно требуется право «manageUsers».
Разработчики Outline исправили этот дефект и ещё одну связанную проблему в течение трёх дней после отчёта.
2. WooCommerce и другие ecommerce‑проекты: доступ к PII в заказах гостей
Для ecommerce‑приложений сценарии вскрыли системные проблемы в логике корзины и заказов. В PHP‑проекте WooCommerce LLM нашла способ для обычных авторизованных пользователей просматривать все заказы гостей, включая персональные данные (имена, адреса, номера телефонов). После сообщения об этом компания Automattic выпустила обновление с идентификатором CVE-2025-15033 и опубликовала объясняющий пост.
После этого GitHub расширил проверку и на другие интернет‑магазины. В популярном Ruby‑приложении Spree были обнаружены две схожие уязвимости (CVE-2026-25758 и CVE-2026-25757). Более критичная позволяла неаутентифицированным пользователям последовательно перебирать идентификаторы и получать адреса и телефоны по всем гостевым заказам.
Дальнейшие проверки показали аналогичные уязвимости ещё в двух ecommerce‑приложениях. По оценке GitHub, ошибки в логике авторизации в таких системах существовали годами до автоматического аудита.
3. Rocket.Chat: вход с любым паролем
Ещё один показательный случай связан с системой чатов Rocket.Chat, использующей микросервисную архитектуру. В конкретной конфигурации сервис аккаунтов пользователей был доступен через DDP Streamer‑сервис по протоколу Meteor DDP.
Taskflow обнаружил потенциальную уязвимость, и исследователи GitHub подготовили proof-of-concept, опираясь на JSON‑конструкцию, предложенную агентом. Подключение к WebSocket‑эндпойнту показало, что войти в Rocket.Chat через открытый DDP‑сервис можно с любым паролем. После успешного входа становилось возможным подключаться к произвольным каналам и прослушивать сообщения, отправленные туда.
Техническая причина оказалась в работе с bcrypt в TypeScript‑коде: функция validatePassword возвращала Promise<boolean>, однако при вызове await не использовался. В результате в логике аутентификации происходила проверка вида valid = validatePassword(...) && true, где значение Promise в JavaScript всегда считается истинным. Таким образом, переменная valid всегда была true, если у пользователя был установлен bcrypt‑пароль.
GitHub подчёркивает, что LLM смогла обнаружить эту тонкую ошибку, проследить её через несколько файлов и прийти к корректному выводу об уязвимости.
Статистика по результатам аудита
На момент сбора статистики taskflows были запущены более чем на 40 репозиториях, в основном на много-пользовательских веб‑приложениях. На этапе формирования идей LLM предложила 1003 потенциальные проблемы.
После финального аудита 139 из них были помечены как реальные уязвимости. После удаления дублей (каждый репозиторий анализировался несколько раз, а результаты агрегировались) осталось 91 уникальная уязвимость, которые команда вручную проверила перед отправкой отчётов.
Для анализа кода и аудита использовалась модель gpt-5.x. Часть последующих запусков и найденных уязвимостей в эту статистику не вошла, поэтому таблица не отражает полный объём всех отчётов, опубликованных GitHub.
GitHub разделяет все найденные проблемы на логические (IDOR, ошибки аутентификации и авторизации, нарушения бизнес‑логики, утечки чувствительных данных, неправильная конфигурация безопасности) и технические (XSS, CSRF, SSRF, path traversal, командная инъекция, удалённое выполнение кода, уязвимости загрузки файлов, внедрение шаблонов, SQL‑инъекции, XXE, проблемы с памятью и т.д.). В сумме было зафиксировано 439 логических и 501 техническая проблема на стадии предложений.
Уязвимостей, связанных с безопасностью памяти, оказалось всего три. Это объясняется тем, что большинство исследованных проектов написаны на языках с управляемой памятью, но также у GitHub есть гипотеза, что текущие taskflows не оптимальны для поиска именно таких ошибок по сравнению с инструментами вроде fuzzing‑фреймворков.
Отдельно выделяется большая доля ошибок бизнес‑логики и IDOR. Число подтверждённых IDOR‑уязвимостей превышает суммарное количество XSS и CSRF. По оценке команды, LLM хорошо справляется с пониманием структуры кода, следованием по контролю потока и учётом модели доступа, что особенно полезно для поиска подобных логических дефектов.
Интересно, что среди ложных срабатываний практически нет «чистых» галлюцинаций. Все отчёты, в том числе ошибочные, содержали разумную аргументацию и ссылки на конкретные участки кода. Многие ошибки в классификации объяснялись контекстом за пределами кода (например, защитами браузера от XSS) или ситуациями, где опытный аудит также мог бы ошибиться, например при наличии нескольких слоёв аутентификации.
Фильтрация по критичности и качество моделирования угроз
Чтобы показать расширяемость taskflows, GitHub добавил ещё один сценарий, выполняемый после основного аудита. Он использует собранную информацию, чтобы отфильтровать уязвимости низкой значимости. По экспериментам, такая пост-обработка позволяет отсечь примерно 50% малозначимых проблем, хотя несколько пограничных кейсов, которые всё же были отправлены разработчикам, также попали в низкий приоритет.
Выражаясь в общих чертах, LLM демонстрирует сильные стороны при моделировании угроз. Taskflows проверялись на приложениях разных типов: десктопные программы, многотенантные веб‑приложения, системы, выполняющие произвольный код в песочнице, реверс‑прокси. В большинстве случаев LLM корректно учитывала предполагаемое использование и делала адекватные выводы о безопасности.
Сложнее всего агенту удаётся оценка угроз для десктопных приложений, где трудно однозначно определить, следует ли считать другие процессы на машине пользователя доверенными или нет.
В отчётах встречаются примеры того, как LLM осознанно отклоняет потенциальные уязвимости при отсутствии прироста привилегий. В одном из кейсов модель заметила несогласованность в контроле доступа, но отметила, что атакующий не получает ничего сверх того, что можно сделать вручную с помощью копирования и вставки.
Также зафиксированы случаи использования сложных техник в рассуждениях. В одном приложении, выполняющем скрипты в изолированной nodejs‑среде, LLM предложила метод выхода из песочницы. Хотя конкретный вывод оказался ложным из-за дополнительных защит, пример показывает достаточно глубокие технические знания модели.
Доступность фреймворка и возможные сценарии использования
Taskflows, использованные GitHub Security Lab для поиска уязвимостей, опубликованы как open source и доступны для запуска на собственных проектах. Команда GitHub призывает разработчиков не только использовать готовые конфигурации, но и писать свои сценарии.
Авторы подчёркивают, что показанные кейсы — лишь часть возможностей подхода. Помимо поиска новых уязвимостей, taskflows могут применяться для задач triage результатов SAST, построения безопасных окружений разработки и других задач безопасности, где комбинируются автоматический анализ и знания LLM.
Источник: блог GitHub Security Lab.
