В прошлой статье я показал, как защищен Open Source проект телеграм-бота. В комментариях меня спросили о иных инструментах и методах проверки в связи с чем, мы вышли к ключевому вопросу: почему, если основная LLM защищена, кастомные боты на ее основе остаются уязвимыми?
Базовые LLM проходят отдельное safety-training и RLHF-выравнивание. Но production-бот, построенный поверх модели, добавляет новый attack surface: system prompts, память диалога, RAG, tools, webhook-логику и внешние API. Именно этот orchestration layer часто становится слабым местом. Вот данные:
Из анализа 14 904 кастомных GPT:
95% не имеют адекватной защиты
96.51% уязвимы к roleplay-атакам
92.20% — утечка system prompt
91.22% — генерация фишингового контента
0.47% устояли против всех атак
Из 10 000 реальных кастомных GPT:
98.8% уязвимы к атакам на утечку инструкций
Половина оставшихся 1.2% взламывается через многоходовые диалоги
Из тестирования 200+ кастомных GPT (Yu et al., ICLR 2024):
97,2 % уязвимы к утечке system prompt (в ботах с активным Code Interpreter)
100% уязвимы к утечке загруженных файлов
При этом те же самые базовые модели отбивают большинство этих атак напрямую. Как отмечают исследователи из ACM:
«Хотя базовые LLM в целом более безопасны, уязвимости сохраняются… что указывает на то, что подобные недостатки могут переноситься или даже усугубляться в кастомизированных моделях».
Исследования охватывают Custom GPTs, однако те же attack surface — system prompt, RAG, webhook-логика — присутствуют в любом production LLM-боте, включая Telegram.
Почему Garak, Promptfoo и PyRIT не решают эту проблему?
Все три инструмента отличные. Но у каждого есть принципиальное ограничение для нашей задачи.
Garak: Отлично подходит для probing и security-тестирования самих LLM-моделей и API-оберток. Но для сложных production-ботов с webhook-интеграциями, состоянием диалога и бизнес-логикой его приходится сильно менять.
Promptfoo: Подходит для evals, regression testing и red-team проверки LLM-пайплайнов. Однако для непрерывного тестирования production-ботов с реальными webhook-flow, пользовательскими сессиями и сложным состоянием диалога обычно требуется дополнительная инфраструктура.
PyRIT (Microsoft): Фреймворк для построения кастомных сценариев атак. Мощный, но требует написания Python-скриптов под каждый сценарий. Это инструмент для исследователей и выделенных security-команд.
В чём пробел?
Существующие инструменты ориентированы либо на model probing, либо на pipeline evals, либо на исследовательские red-team сценарии. Production webhook-боты с многоходовыми пользовательскими сессиями остаются менее автоматизированным кейсом.
BarkingDog закрывает именно эту нишу — тестирует бота через реальный webhook с многоходовыми атаками, out of the box, без написания кода.
GitHub: https://github.com/PPushkarev/BarkingDog
Сталкивались с этой проблемой при деплое своих ботов? Пишите в комментариях!
