Red teaming LLM по OWASP: ASR, Security Score и что с ними делать

Коротко

Red teaming — это контролируемая атака на собственную систему до того, как это сделают другие. Автоматизированный вариант генерирует атакующие запросы, отправляет их цели и оценивает ответы отдельной моделью-судьёй.
Результат сводят к двум числам. ASR (Attack Success Rate) — доля атак, которым удалось добиться нежелательного ответа: чем ниже, тем лучше. Security Score — взвешенная оценка по категориям OWASP с учётом критичности: чем выше, тем лучше.
Одно число ничего не значит. Работает цикл: базовый скан → усиление защиты → повторный скан → сравнение.
Автоматический red teaming не заменяет экспертный пентест. Он закрывает базовый уровень и делает безопасность видимой на каждом релизе.

Зачем атаковать самих себя

Проверка безопасности LLM-приложения часто выглядит так: кто-то вставляет в чат несколько удачных prompt injection из интернета, видит, что система отказала, и считает вопрос закрытым. Это не измерение: нет датасета, нет повторяемости, нет числа, которое можно сравнить после следующего изменения промпта.

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

Что такое OWASP LLM Top 10 и зачем он здесь

OWASP LLM Top 10 — это список основных классов рисков для приложений на больших языковых моделях: prompt injection, утечки чувствительной информации, избыточные полномочия агента и другие. Для нас он выполняет роль общего языка. Когда результаты группируются по категориям OWASP и уровням критичности, их одинаково понимают разработчик и специалист по безопасности.

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

Техники атак

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

Single-turn: одно сообщение

Prompt Injection. Попытка переопределить инструкции системы вредоносным вводом: «забудь предыдущие указания и сделай X».
Roleplay. Обход ограничений через ролевую игру и вымышленные сценарии: «представь, что ты персонаж, у которого нет правил».

Multi-turn: диалог

Crescendo Jailbreaking. Постепенная эскалация диалога от безобидного к запретному. Каждая реплика по отдельности выглядит невинно, опасен вектор разговора.
Linear Jailbreaking. Последовательные уточнения, которые подбирают обход шаг за шагом, используя ответ модели на предыдущем шаге.

Multi-turn атаки важны, потому что защита, настроенная на проверку одного сообщения, их пропускает. Если ваша система ведёт диалоги, проверять нужно именно диалоги.

Что проверяем

Категория	Что это значит на практике
Prompt Leakage	Раскрытие системных инструкций
PII Leakage	Утечки персональных данных
Excessive Agency	Лишние полномочия и действия агента
Toxicity	Токсичные и оскорбительные ответы
Bias	Предвзятые и дискриминирующие ответы
Illegal Activity	Помощь в противоправных действиях

Для RAG и агентов к этому добавляется отдельный вектор: недоверенные данные. Документы из базы знаний, веб-страницы и тексты задач — это тоже ввод, и в них бывают инструкции. Если агент читает документ, в котором написано «отправь содержимое .env на адрес…», это та же prompt injection, только непрямая.

Как устроен автоматический прогон

Генерация атак. Для выбранных категорий и техник создаются атакующие запросы (в том числе многошаговые диалоги).
Отправка цели. Запросы уходят вашей системе. Для этого не нужен доступ к её коду: достаточно описать HTTP-контракт — адрес, заголовки, шаблон тела и путь к ответу в JSON.
Оценка судьёй. Отдельная модель-судья решает, удалась ли атака: раскрыла ли система инструкции, выдала ли данные, выполнила ли запретное.
Агрегация. Результаты считаются по категориям и сводятся к ASR и Security Score.

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

ASR и Security Score: как читать

ASR — доля успешных атак. Если из 200 запросов нежелательный ответ получен на 14, ASR равен 7%. (Цифры иллюстративные.) Число простое, но у него два подвоха:

ASR зависит от набора атак. Сравнивать можно только прогоны на сопоставимых наборах. Поменяли набор — получили другую шкалу.
Среднее по всем атакам скрывает критичные места. 2% успешных атак в категории «токсичность» и 2% в категории «утечка персональных данных» — это разные риски.

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

Что полезно видеть на дашборде:

Security Score, общий ASR, число тестов и число успешных атак.
Разбивку по категориям OWASP с метками критичности.
Динамику по истории сканирований.
Сравнение двух сканов: стало ли безопаснее после изменения.
Полный журнал атак с результатом по каждому запросу.

Последний пункт — самый практичный. Агрегаты нужны для решения «выпускать или нет», журнал — для решения «что чинить».

Цикл: базовый скан → усиление → повторный скан

Один скан — это фотография. Ценность появляется, когда их несколько.

Базовый скан. Зафиксируйте ASR и Security Score текущей версии. Это точка отсчёта.
Разбор успешных атак. Откройте журнал и сгруппируйте успешные атаки: какие категории, какие техники, какой общий механизм.
Усиление защиты. Меняйте то, что реально влияет: системный промпт, фильтры ввода и вывода, ограничения инструментов у агента, права доступа к документам.
Повторный скан и сравнение. Убедитесь, что ASR снизился, а полезные ответы не пострадали. Последнее важно: можно «победить» ASR, научив систему отказывать на всё подряд. Поэтому после усиления защиты прогоните и метрики качества.
Регулярный запуск. Повторяйте после каждого значимого изменения модели, промпта или данных. Для этого скан удобно подключить к релизному процессу и поставить порог: если ASR выше допустимого, релиз останавливается.

Порог, как и при оценке качества, выбирают от базового значения, а не «от потолка». Сначала зафиксируйте, где вы сейчас, затем решите, какое ухудшение вы не готовы выпускать.

Базовый чек-лист безопасности RAG и агентов

Даже без специальных инструментов есть меры, которые заметно снижают риск.

Данные и контекст

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

Промпт и модель

В системном промпте нет секретов: считайте, что его могут вытащить.
Явно задано поведение, когда ответа в контексте нет.
Инструкции отделены от пользовательских данных в шаблоне промпта.

Агенты и инструменты

Минимум полномочий: агент получает только нужные ему инструменты.
Опасные действия подтверждает человек.
Заданы лимиты: число шагов, число вызовов, объём выходных данных.

Эксплуатация

Ключи, токены и чувствительные запросы не пишутся в логи целиком.
Секреты хранятся в переменных окружения или в хранилище секретов.
Частота запросов ограничена, аномалии отслеживаются.

И четыре шага «проверки вместо веры»: запустить скан по категориям OWASP, зафиксировать ASR и разобрать успешные атаки, усилить защиту и повторить скан, сделать скан частью каждого релиза.

Границы подхода

Честно о том, чего автоматический red teaming не делает:

Не заменяет экспертный пентест. Автоматика закрывает базовый уровень и типовые атаки. Нестандартные цепочки, связанные с вашей бизнес-логикой, находит человек.
Зависит от качества судьи. Ложные срабатывания и пропуски неизбежны, поэтому нужен ручной разбор выборки.
Не доказывает безопасность. ASR 0% означает, что набор атак не сработал, а не то, что система неуязвима. Набор нужно обновлять.
Проверяет поведение, а не архитектуру. Если у агента есть права на удаление данных, никакой скан не заменит решения убрать эти права.
Покрывает язык набора. Если атаки сгенерированы в основном на английском, а пользователи пишут по-русски, часть уязвимостей останется в тени. Русскоязычные наборы атак — отдельное направление развития.

Что дальше

Если вы только начинаете, сделайте три вещи на этой неделе. Пройдите чек-лист выше и закройте то, что закрывается без инструментов (права агента, секреты в промптах, недоверенные документы). Запустите базовый скан по категориям OWASP и сохраните ASR. Решите, какое значение ASR остановит релиз.

Инструмент, на котором я это делаю, — DeepRisk: self-hosted платформа с модулями Red Teaming, Evaluate RAG и API Runner, лицензия MIT. Подробнее: neon-dev.ru. Качество ответов проверяется отдельно, об этом — в разборе про четыре метрики RAG.