Continuous Red Teaming

Разового состязательного набора перед релизом недостаточно: атаки на LLM-системы эволюционируют быстрее релизного цикла компании. Проверка переносится с этапа выкатки на расписание против уже работающего продового эндпоинта.

Суть

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

Отсюда сдвиг: канареечный набор промптов (Agent Evals) остаётся шлюзом релиза, но рядом появляется отдельный процесс, который стреляет по проду по расписанию.

Три практики

  • Continuous Red Teaming. Автоматизированные состязательные наборы прогоняются не только перед релизом, но и регулярно против работающего эндпоинта. Обнаруженное попадает в бэклог уязвимостей, а не в переписку.
  • AI-SOC. Алерты guardrails и контроля утечек интегрируются в общий контур мониторинга информационной безопасности организации, а не живут на изолированном дашборде AI-команды. Без этого инциденты остаются невидимыми для службы ИБ и не попадают в общую отчётность — то есть формально их не было.
  • Ответственное раскрытие уязвимостей. Программа bug bounty с отдельной AI/LLM-категорией закладывается в governance с самого начала эксплуатации, а не заводится после первого публичного разбора чужой находки.

Второй пункт — самый недооценённый: он организационный, а не технический, и именно поэтому его пропускают. Команда, построившая отличный каскад guardrails, но не отдавшая его сигналы в общий контур ИБ, обнаруживает при первом инциденте, что доказывать сработавшую защиту нечем.

Как это связано с моделью угроз

Для систем, подпадающих под требования ФСТЭК России к защите значимых объектов КИИ, результаты непрерывного состязательного тестирования логично включать в общий процесс контроля защищённости наравне с классическим тестированием на проникновение (RU AI Regulatory).

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

Связано с

  • Agent Security — общая модель угроз агента
  • Guardrails — что именно проверяется на прочность и чем тестируется
  • Agent Evals — канареечный набор как отдельный шлюз безопасности
  • Attack Kill Chain — по какой цепочке идёт атака
  • Jailbreak Attacks — класс атак, эволюционирующий быстрее релизов
  • Incident Management AI — куда попадает найденное
  • RU AI Regulatory — требования, делающие практику частью соответствия