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