Меня зовут Андрей, я руковожу службой разработки платёжных интерфейсов в Яндексе. Сегодня расскажу о TrustYFox — платформе на основе LLM для поиска уязвимостей в коде, которую я создал как пет-проект. Это не замена существующим сканерам, а дополнение, помогающее находить уязвимости, которые традиционные инструменты могут пропустить.

Эта история — не научная статья и не R&D. Я не эксперт в LLM, но за несколько месяцев мне удалось пройти путь от прототипа до рабочего решения, в котором ежедневно запускаются аудиты. За полгода разработки были проверены разные концепции, написан и переписан код. Ниже — рассказ о том, как всё начиналось, что получилось, и что можно было сделать лучше.

Как всё начиналось

К лету 2025 года команды в моём подразделении стали достаточно автономными: сами ведут проекты, договариваются со смежниками, проводят демо. Это освободило время для экспериментов.

К тому моменту я уже прошёл путь от эйфории к разочарованию в использовании LLM для разработки. Возникла идея: а что, если декомпозировать задачу, запускать её в дочерних агентах и управлять через MCP? Это могло бы эффективнее решать сложные задачи.

На одном из 1–1 с руководителем мы решили, что в финтехе безопасность — критически важна. Значит, стоит попробовать создать LLM-сканер уязвимостей в коде.

Создание прототипа

Я начал с изучения LangChain и выбрал TypeScript — мой основной язык. Первая ошибка: сразу попытался построить сложную мультиагентную систему на LangGraph. Фреймворк оказался сырым, и через выходные пришлось удалить большую часть кода.

Во втором подходе я начал с простого:

• Чтение файлов.
• Отправка чанков в LLM с требованием вернуть ответ в формате JSON.
• Парсинг и проверка ответа другой LLM.

Проблем не возникло. Интеграция с YT и отображение результатов в DataLens тоже прошли легко. Уже через пару дней можно было смотреть список найденных уязвимостей в табличке.

Прототип работал и находил что-то. Значит, можно было двигаться дальше. Но CLI + DataLens выглядели несерьёзно — нужен был нормальный UI.

Первый подход к UI (v0-alpha)

Проект делался как пет-проект, поэтому я хотел заниматься только интересным, а всё остальное — брать из готового. Для UI выбрал Toolpad: он позволял быстро получить приличный интерфейс «из коробки».

К началу августа у меня уже был прототип с UI. Но я хотел вернуться к идее мультиагентной системы. Это стоило ещё нескольких выходных, но в итоге система с несколькими агентами заработала.

Вот как она работала:

• Чтение файлов.
• Получение ранее найденных уязвимостей (размеченных как false positive или «такое хотим видеть»).
• Построение графа зависимостей через tree-sitter.
• Роутинг файлов по агентам: LLM решает, в какие агенты отправить каждый файл.
• Анализ:

Если язык поддерживается tree-sitter:

• Получаем связанные файлы из графа зависимостей.
• Через LLM выделяем важные части контекста.
• Формируем полный контекст: содержимое файла, размеченные уязвимости, системный промпт агента.
• Отправляем в LLM, парсим результат.

Если язык не поддерживается — отправляем чанками с передачей размеченных уязвимостей как обратной связи.

• Сбор результатов, проверка агентов через LLM на постобработке.
• Парсинг и возврат массива найденных уязвимостей.

Для этого пришлось ввести две ключевые сущности: агенты и граф зависимостей.

Агенты — это промпты вроде «Ты эксперт по SQL-инъекциям, проанализируй этот файл» и краткое описание для роутинга.

Граф зависимостей нужен, чтобы передавать LLM не только сам файл, но и связанный код. Поднимать language server для всех языков в Аркадии не хотелось. Решение — tree-sitter.

Tree-sitter — генератор парсеров, позволяющий строить синтаксические деревья и эффективно обновлять их. Я написал обёртку — библиотеку @trusty_fox/ast_indexer — и использовал её для поиска связанных файлов.

Анализ включал:

• Извлечение импортов, экспорта, вызовов функций, названий классов и типов.
• Построение графа с учётом специфики Аркадии.

Из-за ошибок LLM в запросах к tree-sitter я не стал покрывать все языки, а ограничился TypeScript, JavaScript, Python и Go — теми, что были под рукой.

Подготовка к продакшену (v0.1)

К 18 августа проект был развёрнут на виртуалке, и я мог делиться ссылкой. Заинтересовались коллеги из других команд — появилась обратная связь от реальной аудитории.

Решено было доводить проект до продакшена. Нужно было решить несколько задач:

• Переезд с SQLite на PostgreSQL. Да, стоило сделать сразу, но сначала был фокус на скорости.
• Сохранение состояния аудита: процессы могут падать или попадать под деплой.
• Ролевая модель: разделить доступ между сотрудниками СИБ (полный) и обычными пользователями (ограниченный).
• Отображение логов в UI — чтобы видеть, что происходит.
• Перенос промптов из кода в базу данных.
• Настройка CI/CD: деплой в несколько локаций, балансировка, мониторинг.
• Придумать название и брендинг.

Название появилось из сочетания: я работаю в Trust, люблю лисичек, и есть Яндекс. Так родился TrustYFox. Логотип сгенерировала нейросеть.

TrustYFox перестал быть просто CLI-инструментом — он стал продуктом.

Отображение логов аудита

Логи нужно было выводить в UI, а не заставлять пользователей искать их в хранилище. Прототип изначально был библиотекой без UI, и логи писались в stdout. Но для фоновых задач нужен был иной подход.

Я внедрил структурированные логи с указанием скоупа (например, «обработка файлов», «анализ контекста»). Это позволило легко сделать древовидное представление логов в UI.

Сохранение стейта

Аудиты могут длиться долго и прерываться — из-за деплоя, падения воркера и т.д. Без сохранения состояния пришлось бы начинать с нуля.

Я переработал архитектуру и ввёл ReportAnalysisStateManager. Каждый этап аудита (роутинг, анализ, постобработка) теперь:

• Сохраняет и получает результаты через state manager.
• При старте проверяет, не завершён ли уже этап.

State manager также предоставляет AbortController, сигнал которого передаётся в запросы к LLM. Это даёт graceful shutdown.

Ролевая модель

В TrustYFox три роли:

• Пользователь — только просмотр.
• Аудитор — просмотр и запуск аудитов.
• Админ — полный доступ, включая редактирование промптов.

Но был нюанс: нельзя было позволить всем сканировать Финтех. Даже при доверительной культуре доступ к финансам — суперсекьюрен.

Решение — маппинг доступа к проектам на основе ролевой модели внутреннего монорепозитория. Это ограничило сканирование только тем кодом, к которому у пользователя есть доступ.

Последние штрихи

К середине сентября TrustYFox запустили для небольшой группы пользователей. Но это был не финальный продакшен — нужно было сделать UI удобным и понятным.

Я доработал интерфейс, исправил баги в бэкенде и библиотеке. За полтора месяца появилось множество миграций — от обратной связи и улучшений.

Перенос промптов, настройка CI/CD и поднятие окружения прошли без особых сложностей — просто сделано.

Что происходит сейчас

Прошло почти четыре месяца с момента первого PoC. Сейчас я работаю над улучшением TrustYFox.

Запуск аудитов

Аудит — это задача поиска уязвимостей по выбранному пути с указанной конфигурацией (модели, промпты, агенты). Задачи хранятся в БД и выполняются воркером.

Чтобы можно было сравнивать результаты, ввели систему тегов для промптов и агентов. Теперь можно запустить два аудита — со stable- и экспериментальной версией — и сравнить, какая лучше.

Промпты и агенты

Промпты и агенты — это системные промпты. Разница в том, что:

• Промпты — фиксированный набор правил для всех этапов аудита (роутинг, анализ, постобработка).
• Агентов может быть сколько угодно, каждый специализируется на определённой уязвимости (например, SQL-инъекции).

На этапе анализа промпты агентов вставляются в тег <role>, формируя конкретную роль для LLM.

Теги и тюнинг промптов

Сначала промпты лежали в JSON внутри библиотеки. Это не подходило для продакшена — нужно было вынести в БД и обновлять через UI.

Но простое обновление не позволяло тестировать гипотезы. Я хотел сравнивать версии и выбирать лучшую. Варианты — использовать VCS или LLM-ревизии — оказались либо избыточными, либо неработающими.

Решение — теги:

• Stable — версия по умолчанию.
• Теги для промптов и агентов независимы — можно собирать любые комбинации.
• Можно клонировать stable в другой тег и редактировать.
• После обновления experimental можно запустить два аудита для сравнения.
• Любой тег можно промоутить в stable: текущие сущности помечаются как удалённые (soft delete), а новый тег становится stable.

Конфигурации и модели

Конфигурация связывает промпты, агентов, модели и аудиты. Опыт показал, что лучше использовать одну модель на всех этапах, кроме постобработки — так одна LLM проверяет результат другой.

Найденные уязвимости и их разметка

После анализа и фильтрации уязвимости сохраняются в БД. Каждая включает:

• Описание уязвимости.
• Уязвимый код.
• Рекомендуемый фикс.

Даже с контекстом LLM не всегда понимает, что считать false positive. Поэтому ввели петлю обратной связи: пользователи могут размечать уязвимости вручную.

Возможные действия:

• False Positive — уязвимость логична, но не применима. Можно указать причину (на русском, LLM переведёт на английский).
• Looks Good — найдено что-то ценное, хочется больше таких результатов.
• Удалить — если это мусор, просочившийся через постобработку.

Tool Calling

Tool calling позволяет LLM вызывать инструменты из списка. Раньше использовался AST Indexer, но у него были ограничения:

• Ограниченный набор языков.
• Неточность построения графа зависимостей.
• Недостаточный контекст — только ближайшие файлы.

Tool calling стал более гибким решением. Диаграмма взаимодействия:

• LLM получает список инструментов, путь к файлу и промпт с просьбой собрать контекст.
• Запускается цикл:
• LLM запрашивает вызов инструмента (например, чтение файла).
• TrustYFox вызывает инструмент и возвращает результат.
• LLM в какой-то момент завершает цикл.

Tool calling работает лучше, но есть нюансы:

• LLM может зацикливаться, повторяя одни и те же действия.
• Упирается в лимиты — но это лучше, чем бесконечный цикл.
• Проблемы с RegExp: LLM плохо генерирует корректные регулярки, пришлось перейти на поиск по подстроке.
• Повторные вызовы одного инструмента с одинаковыми аргументами.
• Добавление двоеточий в аргументы — вероятно, баг, но быстро не найден.

Что можно было сделать лучше

Ретроспективно есть несколько косяков:

• Проект начинался как эксперимент без чёткого видения конечного результата.
• Выбор SQLite был сделан ради скорости, но пришлось переезжать на PostgreSQL.
• Стоило сразу идти в сторону tool calling. Время, потраченное на tree-sitter, можно было использовать эффективнее.
• Много времени ушло на переделку решений, сделанных «лишь бы работало».

Что дальше

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

Но на выходе всё ещё много шума. Есть идеи по улучшению понимания контекста — возможно, через гибридный RAG. Это задачи будущего.

Сейчас TrustYFox — это v1:

• Стабильно работает в нескольких локациях, переживает закрытие и продолжает прерванные аудиты.
• Удобное тестирование гипотез через теги.
• Возможность запуска аудита на выбранной ветке или ревизии.
• Сбор контекста через tool calling.
• Аудиторы и пользователи не мешают друг другу.
• Права строго разграничены.
• Есть механизмы observability: логи, метрики.
• Выдерживает нагрузку на чтение (проверено через jmeter).

Главная задача остаётся прежней — рост качества. Этим я и займусь дальше.

Всем привет! Меня зовут Андрей, и я работаю в финтех‑направлении Яндекса. Руковожу службой разработки платёжных интерфейсов. Если вы пользуетесь сервисами Яндекса, то наверняка сталкивались с формами оплаты, вот большую их часть делают ребята из моей службы.

Сегодня я расскажу вам о TrustYFox — платформе для поиска уязвимостей в коде при помощи LLM, которую я создал своими руками. С практической точки зрения TrustYFox — это ещё один инструмент, который не заменяет существующие сканеры, а дополняет их, позволяя находить уязвимости.

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

За прошедшие полгода разработки проекта были проверены различные концепции, написано, удалено и заново написано много кода, поэтому сначала расскажу, какой путь пройден, а после — про сам проект, что он умеет и где можно было сделать лучше.

Как всё начиналось

860 год…К лету 2025 года наша служба доросла до состояния, когда команды самостоятельно (ребята, вы очень большие молодцы) или с помощью руководителей ведут проекты, готовят графики с цифрами, договариваются со смежниками, проводят красивые демо. Другими словами, необходимость моего непосредственного участия существенно сократилась. А это значит, что появилось время наносить вокруг добро в своё удовольствие.

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

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

В середине июля на очередном 1–1 со своим руководителем поразмышляли на тему того, что можно сделать не просто интересного, а ещё и полезного. Решили, что раз мы работаем в Финтехе, то нам точно важна безопасность, так что можно попробовать написать сканер на основе LLM, который будет искать уязвимости в коде.

Создание прототипа

Сказано — сделано. Пошёл изучать, что есть готового в этих ваших LLM, чтобы прототип собрать, и наткнулся наLangChain, который предлагал на выбор Python или мой любимый TypeScript. Выбор был очевиден.

Первой болезненной ошибкой здесь было сразу сделать космолёт через LangGraph с распределённой мультиагентской схемой. На тот момент фреймворк был откровенно сырой, и спустя потраченные выходные я с сожалением удалил большую часть кода.

Во второй подход решил уже не выпендриваться и начал с самого простого:

• Прочитал файлы.
• Отправил их в LLM чанками на анализ, настоятельно попросив вернуть ответ в виде JSON.
• Распарсил ответ и попросил ещё одну LLM проверить всё это дело на корректность.

С этим проблем уже не возникло.

Прикрутить выгрузку вYTи настроить отображение вDataLensожидаемо тоже не стало сложной задачей. Спустя пару дней после старта разработки уже можно было посмотреть список найденных уязвимостей в простой табличке.

Итого прототип работает и даже что‑то находит. Значит, нужно продолжать активно копать. А копать есть куда, потому что CLI + DataLens выглядят как‑то не очень серьёзно.

Первый подход к UI (или версия v0-alpha)

Напомню, что делал я это всё хотя и вполне официально, но в дополнение к основной работе, как пет‑проект. И поэтому хотелось делать только интересное, а для всего остального уже использовать готовое. И вот таким готовым решением сталToolpad. Здесь «из коробки» можно получить симпатичный готовый UI без особых усилий.

К началу августа у меня на руках был готовый прототип с UI. Но хотелось продолжить историю с мультиагентской системой. Этот маленький манёвр стоил мне ещёчетырёх выходныхпары недель. Зато в итоге получилось запустить систему с несколькими агентами.

Диаграмма всей это красоты выглядит следующим образом:

Предлагаю вместе разобрать то, как эта схема работает:

• Читаем файлы.
• Получаем на вход найденные ранее уязвимости (которые были размечены как false positive или «такое хотим видеть»).
• Строим граф зависимостей при помощи tree‑sitter.
• Роутим файлы по агентам: берём их и передаём в LLM вместе с содержимым файлов с просьбой вернуть JSON с тем, в какие агенты какие файлы отправить.
• Парсим ответ от LLM.Если язык проекта поддержан в tree‑sitter, то вызываем для каждого файла анализ независимо каждым из выбранных агентов:Получаем связанные файлы из графа зависимостей.Просим в LLM выделить только важные части из всей этой каши содержимого соседних файлов.Берём подготовленный контекст файла, содержимое самого файла, размеченные уязвимости для этого файла (при их наличии) и системный промпт агента.Отправляем это всё в LLM и говорим, в каком формате вернуть.Парсим найденные уязвимости.Если язык проекта не поддержан в tree‑sitter, то чанками отправляем в агента на анализ с передачей всех размеченных уязвимостей в качестве петли обратной связи.
• Собираем всё найденное, берём все размеченные уязвимости и просим LLM проверить, что там отыскали агенты.
• Парсим ответ с этапа «постобработки» и возвращаем массив найденных уязвимостей.

Чтобы вся эта схема вообще заработала, пришлось ввести новые сущности: агенты и граф зависимостей.

Агенты.Агент — это фактически промпт вида «Ты эксперт в поиске SQL‑инъекций, давай аудируй тут мне вот этот файл» и короткое описание для роутинга.

Граф зависимостей.В какой‑то момент я понял, что обрабатывать файлы просто пачками не очень эффективно. Модели нужен больший контекст: важно передавать не только сам файл, но и части кода, с которыми он связан.

Поднимать language server под неизвестное количество языков в Аркадии мне совсем не хотелось. Хотелось быстро и малой кровью получать связанные файлы (даже если их будет немного с запасом). Беглый поиск привёл меня к tree‑sitter.

Tree‑sitter— это генератор парсеров и библиотека для инкрементального анализа. Он позволяет построить конкретное синтаксическое дерево для исходного файла и эффективно обновлять его по мере редактирования исходного файла.

Соответственно, я взял tree‑sitter, написал необходимую обёртку, назвал библиотеку@trusty_fox/ast_indexer, положил рядышком с уже существующей@trusty_fox/llmи там же её заиспользовал. На деле это не то чтобы AST Indexer, а, скорее, библиотека для поиска связанных файлов. Работает она следующим образом:

• Каждый файл анализируется при помощи tree‑sitter и из них извлекаются:Импорты и экспорты.Вызовы функций.Названия функций, классов, типов.
• Имея на руках все файлы, можно строить граф(я же всё‑таки фронтендер, а тут алгоритмы какие‑то сложные)с учётом специфики Аркадии.

Из‑за того, что LLM‑агент с уверенным видом сдавал кривые запросы к tree‑sitter, проще было самому проверять черезSyntax Tree Playground. Поэтому я не стал покрывать все языки, а выбрал те, проекты на которых были под рукой — TypeScript, JavaScript, Python и Go.

Вот так выглядят запросы к tree‑sitter:

Подготовка к продакшену (или версия v0.1)

На дворе 18 августа. Я уже успел развернуть это всё на виртуалке и мог давать ссылки всем, кто хотел посмотреть. К тому моменту проектом заинтересовались ребят из нескольких других команд и подтвердили, что им интересно посмотреть на развитие этой истории. Фактически у меня появилась возможность выстраивать образ результата не на основе своих фантазий, а основываясь на рекомендациях от потенциальной целевой аудитории.

Поэтому решено было продолжать и причёсывать проект для продакшена, тем более что для этого всё было почти готово, нужно было только причесать пару моментов.

Что подразумевается под «парой моментов»:

• Переехать с SQLite на PostgreSQL.Да, я сам себе злой Буратино, нужно было сразу делать нормально, но что есть, то есть.
• Аудиты могут идти долго и попасть в шов бесшовного деплоя.Нужно придумать механизм, как сохранять и восстанавливать состояние аудита.
• Добавить ролевую модель.Пользователей нужно разделять на сотрудников СИБ с полным доступом и обычных пользователей с доступом поменьше.
• Нужно научиться отображать логи в UI,чтобы понимать, что происходит (может, ошибки какие или запросы застряли где‑то).
• Все промпты нужно перенести из библиотеки в базу.До этого момента они хранились в отдельной директории в рамках библиотеки.
• Добавить CI/CD,а именнодеплой в несколько локаций, балансеры, ну и прочие необходимые для продакшена вещи, которые спрашивают на архитектурной секции.
• Придумать название и брендинг.Чтобы инструмент точно запомнился.

Пробежимся по самым интересным пунктам из этого списка.

Начал я, конечно же, с последнего пункта. Так как я работаю в Trust, то хотелось как‑то в названии это упомянуть, да и Яндекс тоже. А, ну и лисичек я люблю. И вот из этого всего родилось название TrustYFox.

А нейросеть сгенерила мне иконки под это дело. Угадаете, какая стала логотипом?

TrustYFox перестал быть просто CLI‑тулзой и начал приобретать черты продукта.

Отображение логов аудита

Зачем? Чтобы в моменте понимать, что происходит в аудите. Нельзя же просить пользователей идти искать в хранилище логов то, что происходит в их аудите, — нужно это выводить в UI.

Важно отметить, что прототип я начинал делать в качестве библиотеки, без UI и бэкендов. Мне показалась, что это вполне годная мысль — максимально изолировать библиотеки и заставить бэкенд зависеть от интерфейсов библиотеки. В целом‑то логично, так все и делают. Но что делать с логами? Ведь если запускать утилиту из командной строки, то логи можно писать в stdout, а куда их писать при запуске аудита в фоне, чтобы можно было посмотреть логи без поиска в БД? Можно передавать логгер в библиотеку и логи писать в БД.

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

Сохранение стейта

Аудиты идут долго: процесс может упасть, в этот момент может случиться деплой новой версии. Да вообще что угодно может произойти и прервать аудит до завершения. А пока аудит не завершился, всё лежит только в памяти. Без стейт‑менеджера, если воркер упадёт в процессе аудита, придётся начинать всё сначала. В общем, вся эта конструкция выглядит не слишком устойчиво.

Чтобы поддержать сохранение состояния аудита, пришлось немного переработать архитектуру библиотеки и ввестиReportAnalysisStateManager.

Любой этап аудита (роутинг, аудит, обработка) теперь для хранения и получения результатов используетReportAnalysisStateManager. State Manager, в свою очередь, при каждом изменении стейта вызывает колбэк с актуальным состоянием, чтобы вызывающий код мог это состояние сохранить. Ну и каждый этап при старте явно смотрит вReportAnalysisStateManager: вдруг этап уже завершён и там лежат результаты этого шага.

А ещёReportAnalysisStateManagerотдаёт наружу возможность вызватьAbortController, signal которого передаётся во все запросы к LLM, что на сдачу от работы со стейтом даёт нам полноценный graceful shutdown.

Ролевая модель

Теперь что касается ролей. На тот момент в инструменте было (да и осталось) три роли:

• Пользователь (можно смотреть, трогать нельзя).
• Аудитор (можно смотреть и можно трогать аудиты).
• Админ (можно трогать вообще всё, включая промпты, смотреть тоже можно).

Однако есть нюанс. Не очень хотелось бы, чтобы все рванули сканировать Финтех. Безусловно, у нас, джентльменов, принято доверять друг другу, но всё, что касается финансов, — суперсекьюрно. Нужно было сделать так, чтобы возможность искать уязвимости была строго ограничена скоупом кода, к которому у пользователя есть доступ.

Несмотря на то что откладывал решение этого пункта почти месяц в пользу доработки всего TrustYFox, решилось всё за пару дней. Я реализовал маппинг доступа к проектам на ролевую модель нашего внутреннего монорепозитория.

Последние штрихи

Наступает середина сентября, TrustYFox запущен в продакшене на небольшой круг заинтересованных пользователей. Но это ещё не продакшен: надо запускать на всех и так, чтобы не было стыдно перед самим собой.

Мне очень не хотелось открывать TrustYFox на большее количество пользователей с кривым UI. Поэтому было решено допилить UI до состояния, когда всё максимально удобно, понятно и очевидно. Потому что могу и потому что хочу. В процессе причёсывания UI попутно правил какие‑то баги на бэкенде и в библиотеке для аудитов. В общем, готовил продукт к продакшену, выступая заодно и в роли тестировщика.

Вот столько появилось миграций за полтора месяца причёсывания UI и обработки обратной связи от пользователей.

Про перенос промптов, настройку CI/CD и поднятие продакшен‑окружения сказать, честно говоря, особенно нечего. Ну настроил и настроил, чего бубнить‑то.

Что происходит сейчас

Прошло почти четыре месяца с того момента, как я решил запустить AI‑Secreview и обрадовался табличке с уязвимостями в DataLens. И вот над чем я работаю теперь.

Запуск аудитов

Начнём с главной страницы — страницы аудитов. Аудит — это задача на поиск уязвимостей по выбранному пути с указанной конфигурацией (выбранные модели, промпты и агенты). Эти задачи лежат в БД и ждут, пока воркер сможет взять их в работу.

Чтобы появилась возможность запускать аудиты с разными конфигурациями и сравнивать результаты, была введена система тегов для промптов и агентов. Если коротко, то можно обновить агентов или системные промпты, после чего запустить одновременно два аудита: со stable‑версией и с экспериментальной. А в конце сравнить найденные уязвимости и принять решение, какую версию оставляем.

Промпты и агенты

Фактически что промпты, что агенты — это всё системные промпты. Отличие только в том, что набор промптов строго фиксирован и промпты описывают общие правила игры. Они определяют поведение на каждом из этапов аудита: роутинг, подготовка, контекста, анализ, постобработка.

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

Промпты из агентов просто собираются на этапе анализа внутрь тега:

И на выходе получается агент с конкретной ролью и общим пониманием того, что нужно делать.

Теги и тюнинг промптов

Как вы помните, изначально все промпты и агенты лежали просто в json внутри библиотеки и обновлялись вместе с релизом. Было сразу понятно, что такое решение не подходит для продакшена и нужно будет всё выносить в БД. Собственно, первый подход как раз и был такой, что я вынес все промпты (и агентов) в БД, после чего мог обновлять их через UI.

Но такой подход не позволял мне шаг за шагом дорабатывать промпты, а для LLM промпты — это очень важная штука, которая напрямую влияет на качество вообще всего. Фактически я мог запустить сначала на одних промптах, потом обновить их и проверить, стало хуже или лучше. Всё это меня совершенно не устраивало, и было понятно, что нужно что‑то придумывать.

Какие вообще были варианты? Один из вариантов — вынести промпты в главный репозиторий и заиспользовать уже готовую VCS. Но это казалось каким‑то космолётом для относительно простой задачи. Второй вариант — реализовать ревизии при помощи LLM‑инструментов. Собственно, LLM‑агент всё переделал на ревизии, и в итоге после потраченных на это выходных мне пришлось откатить пул‑реквест, потому что в нём было всё слишком усложнено (куча разных ревизий, бардак в БД, в общем, мне не понравилось). Да и вообще, оно не работало.

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

И я просто ввёл теги:

• Stable — это то, с чем работают аудиты по умолчанию.
• Теги для промптов и агентов не зависят друг от друга, поэтому их можно собирать в любые комбинации.
• Можно клонировать stable в любой другой тег и редактировать в рамках нового тега агентов и промпты как душе угодно.
• Обновив тег experimental, можно запустить два аудита: на теге stable и на экспериментальном теге.
• Любой тег можно запромоутить в stable, тем самым применив новые изменения.Текущие сущности из stable удаляются через soft delete (проставляем текущий таймстемп в deletedAt).В выбранном теге меняем тег на stable.

Конфигурации и модели

Конфигурация — это связующее звено между промптами/агентами/моделями и аудитами.

Как уже было написано выше, аудит последовательно проходит через несколько этапов. На каждом можно указать свою конфигурацию LLM. Но опытным путём было выяснено, что наилучшая конфигурация — использовать одну модель на всех этапах, кроме постобработки. Фактически такой подход позволяет одной LLM проверять результат работы другой.

Найденные уязвимости и их разметка

После того как агенты нашли уязвимости и уязвимости были отфильтрованы на постобработке, результаты сохраняются в БД.

Что включает в себя сущность найденной уязвимости:

• Описание уязвимости.
• Сам уязвимый код.
• Рекомендуемый фикс.

К сожалению, даже с передачей инфраструктурного контекста и с докидыванием связанных файлов LLM не понимает, что мы хотим видеть, а что считаем false positive. Нужно ей как‑то накидывать примеры, которые можно разметить в ручном режиме.

Вот этим «накидыванием» стала петля обратной связи на размеченных уязвимостях. Пользователи могут изучить, что навыдавала LLM, и сделать три действия:

• Отметить уязвимость как False Positive.Значит, уязвимость логичная, но неприменима в нашем случае. Тогда стоит указать причину, почему это у нас считается нормальным. Написать можно на русском, LLM переведёт на английский. Можно вообще не писать, но дополнительная информация бывает очень полезна.
• Отметить уязвимость как Looks Good.Это значит, что TrustYFox нашёл что‑то стоящее и что хочется видеть больше такого.
• Удалить уязвимость.На случай, если совсем какой‑то мусор просочился через постобработку.

Tool Calling

Что такое tool calling? Фактически это подход, который позволяет LLM самим вызывать необходимые инструменты из предоставленного списка. Выше я уже упоминал, что LLM очень любит находить проблемы там, где их нет, а без контекста тем более. Частично эту проблему получилось решить при помощи AST Indexer и просьбы к LLM чуть пофильтровать контекст. Но там было несколько проблем:

1. Ограниченный скоуп языков (да, можно добавить больше, но это ручная работа).
2. Даже для поддержанных языков построить честный граф связей между файлами — не самая тривиальная задача, и точность здесь страдает.
3. Контекст собирается только из ближайших соседей, а этого часто недостаточно для хорошего анализа.

AST Indexer выручал, пока не было tool calling, но именно как промежуточное решение с понятными компромиссами.

Вот диаграмма взаимодействия LLM с tools при сборе контекста:

И пошагово:

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

Tool calling, безусловно, работает лучше, чем AST Indexer, но и здесь есть целый набор своих нюансов. Одна из самых частых проблем: LLM не всегда решает, что ей хватит, и начинает повторять одни и те же действия с полной уверенностью, что получит какой‑то другой результат…

Ну и ожидаемо упирается в лимиты (но лимиты всё же лучше, чем бесконечный цикл).

Какие ещё есть проблемы, которые пока не решены до конца:

• LLM практически не умеет присылать корректный RegExp для поиска. Пришлось перейти на поиск по подстроке и явно требовать этого от LLM, но поиск через регулярки явно даёт больше гибкости.
• LLM временами любит запрашивать через tools одно и то же. То есть буквально делать два вызова одного и того же инструмента с одинаковыми аргументами.
• LLM зачем‑то постоянно добавляет двоеточие в некоторые аргументы (скорее всего, где‑то просто баг, но быстро найти не получилось) и потом удивляется, что ничего не нашлось.

Что можно было бы сделать лучше

Вообще, есть некоторые моменты, которые ретроспективно выглядят как косяки. Ну куда же без ретро после запуска проекта?

• Проект начинался как эксперимент, и первый месяц совершенно не было понимания, отправится он в продакшен или в помойку. Всё было очень в духе стартапа: проверялись разные гипотезы самым быстрым образом и не было продумано никакого образа конечного результата.
• С самого начала было решено взять SQLite, чтобы не плодить инфру и быстро всё натыкать. В итоге всё равно пришлось переезжать.
• Скорее всего, стоило сразу идти в историю с tool calling. Было интересно поиграться с tree‑sitter, но если бы это время было вложено в tool calling, качество достигло бы приемлемого уровня гораздо быстрее.
• Как следствие из первого пункта, очень много времени было потрачено на то, чтобы переделать то, что было сделано с позиции «лишь бы работало» на старте. С другой стороны, на тот момент с учётом тех входных данных было важно как можно быстрее проверить гипотезу и показать PoC.

Что дальше

Фактически проект уже успешно работает в продакшене около полугода. За это время провели несколько сотен запусков и нашли более 100 потенциальных уязвимостей.

При этом пока ещё на выходе получается достаточно много всякого мусора. Уже сейчас есть идеи, как улучшать понимание контекста проекта, возможно, для этого придётся переписать текущую архитектуру и подключить гибридный RAG, но это уже вопросы будущего…

А что касается настоящего, сейчас проект дорос до состояния, когда его можно назвать v1:

• Всё стабильно работает в нескольких локациях. И инструмент сам переключается между базами и переживает учения по закрытию локаций, умеет продолжать прерванный аудит.
• Можно удобно тестировать гипотезы на разных промптах и аудитах через механизм тегов.
• Можно запускать аудит в выбранной ветке или на выбранной ревизии.
• Для сбора контекста используется Tool Calling.
• Аудиторы и пользователи не пересекаются и не мешают друг другу.
• Права и доступы корректно разграничены по наличию доступов.
• Есть все необходимые механизмы observability, в частности метрики в мониторинге.
• Успешно обстрелян через jmeter, нагрузку на чтение держит хорошо.

Но основная задача осталась неизменной — нужно растить качество. Этим я и займусь в ближайшее время. А пока буду рад ответить на ваши вопросы или обсудить решения в комментариях.