Мой блог
Локальные LLM в AppSec: что доверить открытым моделям
Для проведения экспериментов с искусственным интеллектом в сфере безопасности приложений вовсе не обязательно оформлять платные облачные подписки. Современные локальные LLM можно развернуть прямо на рабочей станции, интегрировать со средствами анализа исходного кода и задействовать в решении исследовательских задач. Открытые программные обвязки предоставляют возможность гибкой настройки таких процессов под конкретные программные продукты.
В результате специалисты получают полный контроль над тем, какие именно данные передаются модели, где именно выполняются вычисления и насколько автономной должна быть проверка. Однако техническая установка языковой модели — это лишь первый шаг, за которым следует поиск оптимальных сценариев применения и выстраивание эффективной методологии.
Как локальные модели вошли в мир безопасности приложений
Появление доступных средств инференса открыло путь для внедрения ИИ в локальные контуры. В марте 2023 года был представлен инструмент llama.cpp, который позволил запускать модель LLaMA-7B на обычном пользовательском оборудовании, включая центральные процессоры. Для уменьшения объема модели применялось 4-битное квантование весов. Данная разработка предоставила разработчикам базу для создания собственных локальных приложений.
Для экспертов по безопасности такие программные решения сформировали новый класс объектов для исследований. Возникла необходимость тестировать поведение моделей при подаче вредоносных или специально сконструированных запросов. Уже в июне 2023 года сканер безопасности Garak 0.9 получил поддержку локальных моделей через интерфейсы ggml и llama.cpp. Параллельно предпринимались попытки задействовать LLM в роли помощника пентестера для генерации действий или интерпретации выводов утилит.
Главным препятствием на раннем этапе была потеря контекста проверки, из-за чего модель приходилось постоянно возвращать в курс дела. В августе 2023 года вышел проект PentestGPT, где данную проблему решили через декомпозицию: история пентеста фиксировалась в виде дерева выполненных проверок и следующих шагов. Хотя проект опирался на облачные API, он продемонстрировал необходимую архитектуру для последовательных исследований.
В феврале 2024 года корпорация Microsoft открыла набор инструментов PyRIT для автоматизации тестирования генеративного ИИ. Необходимость таких систем обусловлена вариативностью ответов языковых моделей на идентичные запросы, что требует многократного проведения тестовых атак. Осенью того же года появились инструменты анализа кода вроде Vulnhuntr, позволившие LLM запрашивать функции и классы при исследовании проектов на Python, а также получившие интеграцию со средой Ollama.
К 2025 году сформировались открытые агентные среды для тестирования на проникновение. В январе появилась альфа-версия платформы PentAGI, а к концу года локальные подключения были закреплены в документации Strix. Данные среды объединяют выбор модели, набор исполнительных команд и фиксацию итогов. В январе 2026 года GitHub Security Lab презентовала среду Taskflow Agent, где исследовательские последовательности описываются отдельно от исполняющего кода, упрощая перенос практик между специалистами.
Что можно собрать вокруг локальной LLM
Архитектура локального применения ИИ в безопасности включает несколько ключевых компонентов. Сама языковая модель генерирует ответы на основе переданного ей контекста. Для ее работы необходима среда исполнения, которая загружает веса в память оборудования и обрабатывает внешние запросы. В качестве таких сред выступают Ollama, llama.cpp и vLLM.
Программная оболочка организует взаимодействие модели с исходным кодом и утилитами безопасности. В базовых сценариях скрипт передает фрагменты кода для разбора конкретного предупреждения. Продвинутые агентные среды могут делегировать модели чтение файлов, выполнение команд и отправку запросов к тестируемому приложению, возвращая результаты обратно для дальнейшего анализа.
Интерфейсыроде протокола MCP позволяют подключать к агентам классические статические анализаторы, такие как Semgrep. Детерминированный анализатор выполняет проверку по жестким правилам, а LLM сопоставляет его выводы с контекстом исходного кода. Возможность гибкой замены моделей в таких связках позволяет тестировать разные языковые версии на одном наборе данных или переключаться на единый внутренний сервер.
Открытый исходный код программ-обвязок дает возможность модифицировать логику проверок: ограничивать разрешенные действия, подключать собственные анализаторы или менять схему передачи контекста. Необходимость подобных усложнений зависит от стоящих задач, так как для точечного анализа фрагмента кода тяжелые агентные системы избыточны.
Какие сценарии безопасности можно реализовать с помощью локальных инструментов: Чтение исходников и результаты анализа
В задачах статического анализа кода модель выступает помощником при проверке конкретных гипотез. Если сканер обнаруживает подозрительную операцию, специалист может поручить ИИ проследить путь поступающих данных и наличие проверок на предшествующих участках. Подобная работа выполняется без предоставления доступа ко всей инфраструктуре приложения.
Эффективность такого подхода напрямую зависит от возможности проверки выводов по исходному коду. В исследованиях гибридного анализа локальные модели оценивали пути передачи данных от источника к опасному вызову, что помогало фильтровать ложные срабатывания. Тем не менее, качество фильтрации у компактных моделей может варьироваться.
Важным фактором остается детализация заданий. Исследование SRLabs «Beyond Fable» продемонстрировало, что разделение аудита веб-приложений на мелкие задачи с четко заданными файлами и ожидаемыми результатами дает гораздо более точные ответы, чем общая команда проверить весь проект. При этом отсутствие сквозного контроля связей между отдельными этапами может привести к пропуску уязвимостей, даже если локальные ответы на каждом шаге выглядели корректно.
Анализ приложения в динамике
Динамическое исследование поведения работающих программ требует от модели формирования запросов, воспроизведения состояний и интерпретации серверных ответов. Для этих целей применяются открытые агентные среды PentAGI и Strix, связывающие логику ИИ с реальными действиями через браузер, HTTP-прокси и терминал.
Полученные отклики необходимо соотносить с бизнес-логикой приложения. Например, один и тот же ответ сервера при проверке прав доступа может быть штатным для владельца ресурса и критической уязвимостью для стороннего аккаунта. Соответственно, модель должна обладать полной информацией о ролях и текущей сессии.
Степень автономности агента варьируется от выполнения отдельных директив под управлением человека до полностью самостоятельной цепочки операций. Поскольку среда выполнения не занимается интерпретацией недосказанностей, пригодность модели для автономной работы требует отдельного тестирования.
Проверка безопасности встроенных ИИ-помощников
Наличие встроенных в приложения языковых моделей создает новые векторы угроз, связанные с эксплуатацией корпоративных ассистентов через специально сформированные запросы. Для тестирования таких систем на утечки данных или несанкционированное выполнение функций применяются инструменты Garak и PyRIT, работающие в связке с локальными серверами генерации.
Эффективность защиты оценивается по двум критериям: блокировка несанкционированных действий атакующего и сохранение работоспособности штатных функций для обычных пользователей. Для непрерывного контроля создаются собственные наборы регрессионных тестов, запускаемые после любых изменений в системных промптах или окружении.
Архитектура проверок может включать несколько ролей: одна модель обслуживает приложение, вторая генерирует тестовые атаки, а третья оценивает результаты. Подобные схемы реализуются с помощью библиотек Giskard и DeepTeam, предназначенных для моделирования угроз ИИ-приложениям.
Что потребуется от команды при внедрении локальной модели
Различные сценарии использования предъявляют специфические требования к вычислительным ресурсам. Разбор изолированных фрагментов кода работает в рамках ограниченного контекста, в то время как агентные исследования накапливают историю и создают высокую нагрузку на оборудование. Ошибки на ранних этапах работы агентов способны увести все расследование в неверном направлении, как это фиксировалось в тестах локального агента PrivEsc-LLM 4B при попытке эскалации привилегий в Linux.
Дополнительные компоненты инфраструктуры, такие как векторные базы данных или поисковые модели, также требуют контроля безопасности, если обрабатываемые данные не должны покидать периметр компании. Аналогичные требования касаются инструментов тестирования: некоторые функции фреймворков вроде Promptfoo могут задействовать внешние облачные генерации, что нарушает требования полной локальности.
Открытые инструменты и сторонние зависимости несут риски供应链-атак. В январе 2025 года в репозитории PyPI фиксировались поддельные пакеты интеграции с моделями, похищавшие переменные окружения. Уязвимости в легитимных AI-фреймворках, включая кампанию ShadowRay против платформы Ray, подчеркивают важность строгой изоляции кластеров и контроля версий.
Условия лицензирования моделей также требуют отдельного юридического анализа. Наличие открытых весов не всегда гарантирует право на коммерческое использование или развертывание в определенных юрисдикциях. Кроме того, экономия на облачных подписках нивелируется затратами на оборудование, инфраструктурное сопровождение и рабочее время инженеров, затрачиваемое на отладку результатов.
Как локальные LLM могут изменить процессы AppSec
Интеграция локальных решений стимулирует появление специализированных моделей, адаптированных под узкие задачи безопасности. Обучение компактных моделей под конкретные типы уязвимостей требует значительных вычислительных мощностей на этапе тренировки, однако готовые веса эффективно функционируют на потребительских видеокартах.
Развитие стандартизированных форматов описания проверок, реализованное в Taskflow Agent, позволяет командам обмениваться готовыми сценариями исследований и накапливать общую экспертизу. В результате специалисты получают возможность выбирать не только базовую языковую модель, но и проверенные методики аудита, адаптируя их под особенности собственных программных продуктов.
