Оценка безопасности AI-продукта: как выбрать рамки и доказательства

Представим условную ситуацию. Через месяц компания выпускает AI-ассистента для клиентской поддержки. Он отвечает по базе знаний, видит историю заказов клиента и умеет оформить возврат. На столе у CTO два коммерческих предложения. Первое обещает «проверку по OWASP LLM Top 10 за пять рабочих дней». Второе предлагает «AI red teaming силами команды исследователей». Оба написаны уверенно, в обоих много знакомых терминов.

Но ни одно не отвечает на вопрос, который на самом деле волнует компанию. Может ли пользователь, сформулировав запрос определённым образом, оформить возврат по чужому заказу? И если может, где именно происходит сбой: в модели, в коде, который вызывает функцию возврата, или в том, как приложение проверяет права?

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

Что на самом деле покупается под названием «оценка безопасности AI»

Система, а не модель

Оценка безопасности — это техническое тестирование конкретной системы, за которым следуют анализ результатов и план устранения. NIST SP 800-115 выделяет планирование, выполнение и действия после выполнения оценки; анализ находок, рекомендации по устранению и отчёт относятся к последнему этапу. Документ вышел в 2008 году, задолго до LLM-продуктов, и сам себя не называет полной программой тестирования. Тем не менее его цикл хорошо переносится на AI: он держит фокус на доказательствах и исправлениях, а не на новизне атак.

Ключевое слово здесь — система. Злоумышленник не общается с «моделью» в вакууме. Он работает с веб-интерфейсом или API, проходит или не проходит аутентификацию, получает сессию и отправляет запросы. На них реагирует оркестрационный код, который обращается к модели, к поиску по документам и к внутренним сервисам. Отчёт, который описывает только поведение модели, описывает один компонент из многих.

Три формата, которые часто путают

Под похожими названиями на рынке продают разные работы. Их полезно развести до того, как сравнивать цены и сроки.

Ни один формат не лучше других в абсолюте. Список LLM Top 10 — хороший словарь, но плохой план тестирования. Red teaming отвечает на вопрос, может ли конкретный противник добиться конкретной цели. Это другой вопрос, чем «работают ли все меры защиты». Разницу подробно разбираем в материале о том, как заказывать AI red teaming с проверяемыми критериями. Если задача — систематически проверить границы продукта перед релизом, начинать обычно стоит с оценки безопасности, а red teaming планировать позже, под конкретные сценарии.

Четыре слоя AI-продукта

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

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

Первый слой — всё, что модель видит. Это данные для дообучения, если модель дообучалась, документы для поиска, история диалога и сведения о пользователе, которые подставляются в контекст. Вопросы здесь такие. Кто может записать в эти источники? Разделены ли данные разных клиентов и ролей до того, как попадут в контекст? Может ли документ с внедрённой инструкцией повлиять на ответы другим пользователям?

Слой поиска по документам заслуживает отдельной проверки: ошибки разграничения доступа в индексе часто важнее любых особенностей модели. Подход к такому тестированию разобран в методике оценки RAG-систем.

Модель и её конфигурация

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

Важно, что конфигурация — часть объекта проверки. Тот же базовый продукт с другими системными инструкциями или другим фильтром — это уже другая система с точки зрения выводов. Как глубже работать с этим слоем, мы описали в руководстве по оценке безопасности моделей.

Приложение и API вокруг модели

Третий слой — привычная прикладная часть. Аутентификация, сессии, авторизация, ограничения частоты запросов, обработка ошибок, журналы, отображение ответа в браузере. Этот слой проверяется по зрелым методикам веб- и API-тестирования. Именно здесь часто лежат самые дешёвые для атакующего пути: незачем обманывать модель, если API отдаёт чужие диалоги по подменённому идентификатору.

Инструменты и действия

Четвёртый слой — всё, что модель может запустить. Функции, плагины, MCP-серверы, вызовы внутренних API, отправка писем, изменение записей. Вопросы: с чьими правами выполняется действие? Проверяет ли код права пользователя перед вызовом, или полагается на то, что «модель не станет»? Есть ли подтверждение для необратимых операций?

В нашем условном примере именно этот слой решает судьбу функции возврата. Агентные сценарии с цепочками вызовов добавляют свои риски, и их стоит планировать отдельно; подробнее — в руководстве по пентесту агентных AI-систем.

Как выбрать рамки оценки

Начать с решения, которое должна поддержать оценка

Первый вопрос — не «что тестировать», а «какое решение оценка должна поддержать». Выпуск в продакшн, подключение нового инструмента к агенту, приёмка продукта у поставщика, ответ на вопрос крупного клиента о безопасности — каждое решение требует своей глубины.

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

Карта границ доверия

Дальше исполнитель вместе с командой фиксирует четыре вещи: откуда AI-компонент получает входные данные, к чему у него есть доступ, какие действия он может запускать и куда уходит его вывод. Каждая точка, где недоверенный ввод встречается с правами, данными других пользователей или действиями, — граница доверия. На ней должна работать конкретная мера защиты, и тесты проверяют именно эти меры, а не «модель вообще».

1. РешениеЗафиксировать, что должна поддержать оценка: релиз, новый инструмент агента, приёмку поставщика или ответ клиенту.
2. Карта системыОписать данные, модель, приложение и инструменты, включая версии, поставщиков и интеграции.
3. Границы доверияОтметить места, где недоверенный ввод встречается с правами, чужими данными или действиями.
4. ПроверкиДля каждой границы выбрать метод: стандартный тест приложения, сценарий для модели или ручную проверку прав.
5. ДоказательстваЗаранее договориться, что считается подтверждённой находкой и как будут описаны пределы выводов.

Что зафиксировать письменно до старта

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

Если модель предоставляет внешний поставщик, полезно проверить его условия использования. Разрешение владельца продукта не всегда покрывает тестирование чужой инфраструктуры, и это лучше выяснить до первого запроса, а не после.

Если удобнее разложить продукт по слоям и границам вместе с командой Pentest.red, это можно сделать на этапе подготовки контура пентеста. Там обсуждаются системы, доступы, ограничения и ожидаемый результат — без заранее обещанных находок.

Опорные стандарты и где они заканчиваются

Цикл тестирования

Для этой статьи мы разворачиваем процессную рамку SP 800-115 в практический порядок работы с AI-продуктом. Планирование включает разрешение, охват, цели, правила обращения с данными и условия остановки. Выполнение — методы, привязанные к согласованным целям, с пониманием их сильных сторон и ограничений. Анализ превращает наблюдения в находки с корневыми причинами и затронутыми активами. Устранение — приоритеты, владельцы и повторная проверка. AI-специфичные цели дополняют этот каркас, а не заменяют его.

Прикладной уровень

OWASP Web Security Testing Guide даёт процедуры тестирования веба и API; стабильная версия — 4.2, версия 5.0 в разработке. OWASP ASVS 5.0.0 — набор проверяемых требований к мерам защиты. Проект прямо ставит цель выровнять охват и строгость проверок, которые предлагает рынок.

ASVS рекомендует ссылаться на требования вместе с версией, например v5.0.0-1.2.5, потому что номера требований меняются между выпусками. Списки требований публикуются в CSV и JSON. Это позволяет согласовать охват заранее и отслеживать его программно, а не верить описанию на словах.

Язык AI-рисков

OWASP Top 10 for LLM Applications в редакции 2025 года даёт общий словарь рисков. Он помогает обсуждать слабости AI-систем, но не задаёт полную программу проверки конкретного продукта. Как связать такую классификацию с реальными проверками, разобрано в материале об аудите безопасности LLM.

MITRE ATLAS — база знаний о тактиках и техниках атак на AI-системы, построенная по образцу ATT&CK. Она полезна для моделирования угроз и подготовки сценариев. NIST AI RMF 1.0, выпущенный в январе 2023 года, и его профиль для генеративного AI — NIST AI 600-1, июль 2024 года, — относятся к управлению рисками. Они помогают встроить результаты оценки в процессы организации, но не являются процедурой тестирования.

Чего нет ни в одном стандарте

Процедуры оценки AI-продукта зависят от его слоёв, интеграций и модели угроз. Знакомство исполнителя с WSTG и ASVS само по себе не подтверждает полноту проверки AI-системы. Эта статья не опирается на публичный независимо проверенный бенчмарк, который позволял бы напрямую сравнить результативность поставщиков. Поэтому формулировку «собственная методика оценки AI» нужно проверять по существу: попросите описать методы, их ограничения и связь с вашей картой границ доверия.

Есть и ещё одно различие, которое полезно держать в техническом задании. Использование AI в работе по кибербезопасности и оценка безопасности самих AI-систем — разные задачи. Обе важны, но смешивать их в одном документе не стоит: у них разные исполнители, критерии и результаты.

Классические слабости никуда не делись

Вывод модели как недоверенный ввод

Самая недооценённая мысль в оценке AI-продуктов: всё, что сгенерировала модель, нужно рассматривать как ввод от потенциального злоумышленника. На модель можно повлиять через запрос, документ в базе знаний или ответ внешнего сервиса, поэтому её вывод не надёжнее любого пользовательского поля.

Если ответ отображается в браузере, работают обычные риски межсайтового скриптинга, и Content Security Policy снова становится важной мерой: она помогает обнаруживать и смягчать XSS и внедрение данных. Если вывод используется для построения SQL-запроса, пути к файлу или команды ОС, возвращаются инъекции и обход каталогов. В ASVS есть прямое требование: вызовы ОС должны быть параметризованы или использовать контекстное кодирование командной строки. CISA в рамках Secure by Design выпускало предупреждения об устранении целых классов дефектов — межсайтового скриптинга, инъекций команд ОС, обхода каталогов.

Корневые причины вместо симптомов

Классификация находок по CWE связывает их с практикой разработки. Рейтинг CWE Top 25 и сопутствующий список слабостей, которые активно эксплуатируются по каталогу CISA KEV, помогают выстроить очерёдность исправлений. Если оценка проверяет только «новое поведение AI» и пропускает эти классы, самые эксплуатируемые пути остаются непроверенными.

OWASP Top 10 в редакции 2025 года остаётся общим словарём веб-рисков. Но это документ для осведомлённости, а не план тестирования, и отчёт, который ссылается только на его категории, говорит об уровне осведомлённости, а не верификации.

Три заблуждения, которые искажают выводы

Отказ модели не доказывает авторизацию

Модель ответила: «Я не могу выполнить это действие». Это наблюдение о поведении модели на конкретном запросе, а не доказательство того, что инструмент защищён. Если функция возврата принимает идентификатор заказа и не проверяет, принадлежит ли заказ текущему пользователю, перефразированный запрос, другой язык, длинный контекст или документ с внедрённой инструкцией могут привести к вызову.

Корректный тест — проверить авторизацию на стороне инструмента. Что произойдёт, если вызов с чужим идентификатором придёт к API напрямую? А если через модель от имени другой роли? Принцип короткий: права проверяет код, а не модель.

Фильтр промптов — не граница доступа

Фильтры входных данных и классификаторы подозрительных запросов полезны как дополнительный слой. Но они вероятностные: в зависимости от формулировки, языка или контекста фильтр может пропустить то, что должен был остановить. Граница доступа — это проверка прав в коде, изоляция данных клиентов и минимальные привилегии сервисной учётной записи, от имени которой работают инструменты. Если отчёт описывает фильтр как меру, которая «закрывает» риск доступа к чужим данным, это повод для вопросов.

Секретность системного промпта не заменяет защиту

OWASP выделяет утечку системного промпта в отдельную категорию LLM Top 10 2025 и рекомендует не хранить в нём чувствительные сведения: учётные данные, строки подключения, описание ролей и прав. Исходить стоит из того, что содержимое системного промпта может быть извлечено. Поэтому находка «удалось получить системный промпт» важна не сама по себе. Важно, что в нём оказалось и какие меры защиты на его секретность опирались.

Что считать реальным доказательством

Как выглядит подтверждённая находка

Хорошая находка в оценке AI-продукта описывает проверенную границу или требование. Она фиксирует условия: модель, версию, конфигурацию, учётную запись и данные. Указывает воспроизводимость — сколько было попыток и насколько стабилен результат. Показывает наблюдаемый эффект на стороне системы, а не только текст ответа. Называет затронутые активы, корневую причину, рекомендацию и степень уверенности исполнителя.

Разница между «модель сказала странное» и «через модель был вызван API возврата для заказа другого пользователя, вызов зафиксирован в журнале» — это разница между наблюдением и доказательством.

Пределы выводов

Для AI это особенно важно. Результат относится к конкретной модели, версии, конфигурации и набору сценариев. Модели недетерминированы: один и тот же запрос может дать разные ответы. Поэтому отсутствие находки после нескольких попыток — это наблюдение при этих попытках, а не доказательство невозможности.

Смена версии модели у поставщика, правка системных инструкций или подключение нового инструмента делает часть выводов устаревшей. И общее правило, которое касается любого пентеста: оценка — не сертификат и не доказательство отсутствия всех уязвимостей. Она показывает, что было проверено, как и с каким результатом.

Компромиссы, о которых стоит договориться заранее

Снимок во времени

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

Чек-лист и исследование

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

Тестирование не заменяет проектирование

По позиции CISA Secure by Design, эксплуатируемые изъяны дешевле устранять на этапе проектирования, а продукт должен поставляться с безопасными настройками по умолчанию — включая многофакторную аутентификацию и журналирование без доплаты. Для покупателей у CISA есть руководство Secure by Demand с вопросами для закупочных переговоров; оно особенно полезно, когда AI-возможности покупают, а не разрабатывают сами. Оценка показывает остаточный риск, но не превращает слабую архитектуру в сильную.

Вопросы к коммерческому предложению

Вернёмся к условной ситуации с двумя предложениями. Вместо выбора между названиями CTO может задать обоим исполнителям одинаковые вопросы и сравнить ответы.

Первый — про охват. Описана ли система целиком, со всеми четырьмя слоями и версиями, или речь идёт о «тестировании модели»? Второй — про инструменты. Будет ли проверяться авторизация на стороне кода, который выполняет действия, или только реакция модели на запросы? Третий — про прикладной уровень. Привязаны ли тесты веба и API к процедурам WSTG и требованиям ASVS с версией?

Четвёртый вопрос — про доказательства. Как оформляется находка, что считается подтверждением, как описывается воспроизводимость при недетерминированном поведении модели? Пятый — про пределы. Как в отчёте будут названы непроверенные области и при каких изменениях результаты потребуют повторной проверки? Шестой — про данные. Как исполнитель хранит и удаляет запросы, ответы и документы, которые увидит в ходе работы?

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

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