Оценка безопасности генеративного ИИ: что проверять и как заказать

Сценарий ниже придуман для этой статьи, но экзотики в нём нет. HR-платформа добавляет функцию «краткая справка по кандидату». Рекрутер загружает резюме в PDF, система извлекает текст, подтягивает из базы описание вакансии, отправляет всё это модели и показывает ответ в браузере с markdown-разметкой. Если справка понравилась, ассистент по кнопке предлагает время собеседования и сам создаёт событие в корпоративном календаре.

Перед релизом команда заказывает «оценку безопасности ИИ» и получает отчёт: сорок попыток джейлбрейка, скриншоты отказов модели и пара случаев, где удалось выманить системный промпт. Выглядит солидно, но ответов на вопросы, которые действительно определяют риск, в нём нет. Что будет, если кандидат спрячет в резюме белый текст с инструкцией? Отрисует ли интерфейс ссылку или картинку, которую сгенерировала модель, и куда при этом уйдёт запрос браузера? Может ли модель через инструмент календаря создать событие от имени рекрутера с произвольными участниками? Увидит ли один клиент платформы фрагменты чужих вакансий через общий поисковый индекс?

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

Что на самом деле входит в оценку безопасности генеративного ИИ

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

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

Четыре слоя, которые стоит назвать в охвате

Приложение: интерфейс чата или генерации, аутентификация, сессии и способ отображения вывода модели — текстом, markdown, HTML или предпросмотром документа. API и интеграции: конечные точки запросов и ответов, а также инструменты и функции, которые модель может вызывать, — в нашем примере календарь, в другом продукте CRM или отправка почты.

Данные: запросы, загружаемые файлы, источники для извлечения (retrieval), журналы и обращение с чувствительной информацией в каждой точке. Управление: кто владеет риском и принимает остаточный риск, что журналируется и кто это смотрит, какие обязательства несут поставщики модели и хостинга. Если слой сознательно исключён, это записывают; плохо, когда об исключении узнают из отчёта.

Что дают классические стандарты и где они молчат

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

Специализированный ориентир для этого охвата — OWASP Top 10 for LLM Applications. Выпуск 2026 года, опубликованный в августе 2026-го, ставит на первое место промпт-инъекцию (LLM01) и отдельно выделяет избыточные полномочия (LLM03), раскрытие скрытого контекста (LLM08), слабости векторных хранилищ и эмбеддингов (LLM09) и некорректную обработку вывода (LLM10). Нумерация в этом выпуске отличается от версии 2025 года, поэтому в техзадании стоит ссылаться на конкретный выпуск. Как строить проверку по этому списку, мы подробно разбирали в материале об оценке по OWASP LLM Top 10. Важно помнить: это документ о рисках, а не стандарт сертификации. Ни закрытие всех пунктов, ни пентест в целом не являются сертификацией или заключением о соответствии.

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

Источники и приёмники: карта поверхности атаки

Вывод модели — это недоверенные данные

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

Дальше всё зависит от того, куда этот ответ попадает. Если сгенерированный текст отображается в браузере, актуален межсайтовый скриптинг. Если он передаётся в системный вызов, актуальна инъекция команд ОС. Если из него собирается путь к файлу — обход каталогов. CISA посвятила каждому из этих классов отдельные оповещения в рамках Secure by Design, а MITRE включает их в рейтинг CWE Top 25 2025 года и описывает такие слабости как часто легко обнаруживаемые и эксплуатируемые, способные привести к захвату системы, краже данных или нарушению работы приложения.

Где текст входит и куда выходит

Точки входа: пользовательские запросы, загружаемые документы, контент из поискового индекса, ответы инструментов и внешних сервисов. Точки выхода: интерфейс, исходящие вызовы API, журналы, аналитика, последующие системы. Сопоставление «источник → приёмник» — тот же анализ потоков данных, что в классическом тестировании, с поправкой на то, что модель может переписать данные по дороге; оно превращает разговор «про риски ИИ» в проверяемые гипотезы.

Если в системе есть поиск по базе знаний, отдельного внимания требует изоляция индекса между арендаторами и с учётом прав пользователей; этому посвящён наш разбор оценки безопасности RAG-систем.

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

1. Документ с инструкциейКандидат загружает резюме, где белым текстом спрятана просьба пригласить на встречу внешний адрес и вставить ссылку на «портфолио».
2. Сборка контекстаПриложение кладёт текст резюме рядом с системной инструкцией и описанием вакансии; для модели всё это один поток текста.
3. Ответ с полезной нагрузкойМодель возвращает справку, markdown-ссылку и предложенный вызов календаря с лишним участником.
4. Срабатывают приёмникиБраузер отрисовывает ссылку, а сервис календаря создаёт событие правами рекрутера, если аргументы не проверяются.
5. Где должен стоять барьерСанитизация разметки и URL, запрет автозагрузки по недоверенным адресам, специализированное API календаря с разрешёнными полями, ограничение участников и подтверждение человеком разрывают цепочку.

Мультимодальные каналы — если они есть

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

Как спланировать и провести проверку: NIST SP 800-115 на практике

NIST SP 800-115, «Технический руководящий документ по тестированию и оценке информационной безопасности», вышел в сентябре 2008 года и заменил SP 800-42. Он помогает планировать и проводить технические тесты, анализировать результаты и вырабатывать меры по устранению, а сам описывает себя как обзор ключевых элементов с акцентом на техники, их достоинства и ограничения, а не как исчерпывающую программу.

Формально SP 800-115 делит оценку на три фазы: планирование, выполнение и пост-выполнение, в которую входят анализ, отчётность и рекомендации по устранению. Документ рассматривает тестирование и как поиск уязвимостей, и как проверку соответствия политике или иным требованиям. В правилах взаимодействия нужно указать цель: поиск уязвимостей, проверка выбранных политик или требований либо обе задачи. Например, цель по проверке требований может охватывать вопрос о том, какие данные разрешено передавать внешнему поставщику модели.

Правила взаимодействия, без которых результат не воспроизвести

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

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

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

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

От находки до повторной проверки

Дальше начинается то, что в SP 800-115 относится к пост-выполнению, а на практике становится отдельным рабочим циклом. Каждую находку стоит связать с первопричиной и, где это применимо, с версионированным требованием, назначить ответственного, исправить и проверить повторно. Цикл «исправление → повторная проверка» — практическая рекомендация автора, а не дословная схема фаз NIST.

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

Веб и API вокруг модели: WSTG, ASVS, OWASP Top 10 и механизмы HTTP

OWASP называет Web Security Testing Guide одним из ведущих ресурсов по тестированию веб-приложений; в этой статье WSTG 4.2 закреплён как пример, а в техзадании нужно указать фактически используемую версию. WSTG даёт сценарии для всего, что окружает модель: аутентификации, авторизации, сессий, обработки ввода, бизнес-логики. В примере с HR-платформой именно WSTG подскажет, как проверить, может ли рекрутер одной компании через подмену идентификатора запросить справку по кандидату другой.

OWASP ASVS — основа для проверки технических мер защиты и перечень требований к безопасной разработке; его цель — выровнять охват и строгость проверок на рынке открытым стандартом, пригодным для договоров. Базовый выпуск здесь — 5.0.0. ASVS рекомендует ссылаться на требования с префиксом версии, в форме вида v5.0.0-1.2.5, потому что номера без версии могут сдвигаться между выпусками. Требования доступны в машиночитаемых форматах, включая CSV и JSON, что удобно для трассировки находок. В стандарте есть и требования о защите от инъекции команд ОС — они прямо релевантны везде, где вывод модели может дойти до системных операций. Привязывать находку к требованию ASVS стоит только тогда, когда она ему действительно соответствует; натягивание ради красоты отчёта вредит.

OWASP Top 10 2025 года — документ осведомлённости о наиболее критичных рисках веб-приложений; он хорош для приоритизации, но план тестирования не заменяет. Если API — основная поверхность продукта, полезно отдельно посмотреть наш материал об оценке безопасности REST API.

HTTP-механизмы и потоковый вывод

На уровне протокола вокруг интерфейса генеративного ИИ работают механизмы, хорошо описанные в справочнике MDN. Сам HTTP не хранит состояние между запросами, но приложения обычно держат серверные сессии и связывают с ними запросы через cookie или токены — проверять нужно именно эту связку. HTTP-аутентификация подтверждает личность клиента. Content Security Policy помогает обнаруживать и смягчать часть атак, включая межсайтовый скриптинг и внедрение данных. CORS управляет межсайтовыми запросами, Permissions Policy ограничивает доступные странице API браузера, а Cross-Origin-Resource-Policy смягчает ряд межсайтовых рисков по побочным каналам. Для быстрой проверки конфигурации MDN указывает на инструмент HTTP Observatory.

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

Как ранжировать находки: CWE там, где он применим

MITRE позиционирует CWE Top 25 2025 года как ориентир для инвестиций, политик и практик, которые предотвращают появление уязвимостей. Сопутствующий список CWE Top 10 KEV Weaknesses 2025 ранжирует активно эксплуатируемые слабости на основе каталога CISA Known Exploited Vulnerabilities и служит полезным дополнительным сигналом при расстановке приоритетов.

Находку в системе генеративного ИИ стоит сопоставлять с CWE, когда подходит её техническая первопричина, независимо от того, начался ли сценарий с поведения модели или обычного ввода. Для запуска операций предпочтительно безопасное специализированное API без shell. Если процесс всё же нужно запускать, фиксируют исполняемый файл и опции и проверяют каждый аргумент по разрешённому набору; передача значения отдельным элементом argv сама по себе не устраняет инъекцию аргументов. Исправление на уровне класса применяют ко всем выявленным путям в затронутом компоненте и повторно их проверяют, не заявляя охват непроверенных компонентов.

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

Отчётность для руководства: результаты в терминах NIST CSF 2.0

NIST описывает Cybersecurity Framework 2.0 как инструмент, помогающий организациям понимать и совершенствовать управление киберрисками. Его результаты и профили могут служить общим языком отчётности для находок оценки генеративного ИИ. Повторная оценка после существенной смены модели, конфигурации, источника данных или инструмента — практическая рекомендация этой статьи, а не требование CSF и не универсальное руководство NIST по тестированию генеративных продуктов.

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

Ответственность поставщиков: Secure by Design и Secure by Demand

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

Для заказчиков CISA выпустила руководство Secure by Demand для разговоров при закупке, а вместе с Австралийским центром кибербезопасности — руководство Choosing Secure and Verifiable Technologies. Материал Safe Software Deployment подчёркивает роль надёжного тестирования и измерений, а страница Secure by Design ссылается на руководящие принципы безопасной разработки систем ИИ.

Люди и сервисные учётные записи — разные вопросы

Доступно ли журналирование запросов и действий, на каких условиях и с каким сроком хранения? Поддерживаются ли единый вход и многофакторная аутентификация для людей, которые входят в консоль администрирования? Как устроена аутентификация сервисов: можно ли ограничить API-ключ конкретными операциями, как ключи ротируются, можно ли использовать идентичность рабочей нагрузки вместо долгоживущего секрета? Это разные контуры: MFA защищает человека у консоли и не решает проблему ключа, зашитого в конфигурацию оркестратора. Публиковал ли поставщик отчёты о прогрессе по Secure by Design? Как он устраняет классы слабостей, найденные при тестировании, — точечным фильтром или изменением архитектуры?

Компромиссы: ширина, глубина, воспроизводимость, стенд и продуктив

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

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

SP 800-115 и выбранный в статье пример WSTG 4.2 сами по себе не задают специфичный для ИИ охват. Согласуйте его явно; иначе методология подрядчика определит, какие сценарии модели, извлечения данных, вывода и вызова инструментов будут проверены.

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

Как выбрать подрядчика и что принять в работу

Проверяемое предложение показывает, как будет оценена каждая часть системы, по какому версионированному стандарту и как оформят отчёт и повторную проверку. Строгость, охват, трудозатраты и цену сравнивают как отдельные параметры, не предполагая, что один из них определяет остальные. Методология должна быть явно построена вокруг планирования, выполнения и пост-выполнения в духе SP 800-115, с понятным циклом исправления и повторной проверки. Веб-слой и API — со ссылками на WSTG и версионированные требования ASVS. Охват генеративной части — с названными точками входа запросов и извлечения, приёмниками инструментов и отображения, мерами обращения с данными. Если у продукта есть агентные функции, отдельный вопрос — как подрядчик будет проверять права каждого инструмента; этому посвящён наш материал о тестировании избыточных полномочий AI-агентов.

Тревожные сигналы: обещание «полного покрытия», сканирование набором промптов, выданное за оценку, отчёт без связи находок с первопричинами, размытый «AI red teaming» без целей, приёмников и критериев успеха. До подписания договора разумно попросить обезличенный образец отчёта и образец правил взаимодействия.

Какая оценка нужна именно вам

Ниже — рекомендации, а не предписание: отправная точка для обсуждения охвата.

Генеративная функция добавлена в существующее веб-приложение. Целевая проверка веб-слоя и API по WSTG и ASVS плюс анализ источников и приёмников для отображения вывода модели и потоков данных. В примере с HR-платформой — прежде всего рендеринг markdown и изоляция данных между клиентами.

Агентные интеграции и инструменты. Углублённо проверяют приёмники исполнения: вместо shell предпочитают специализированные безопасные API; если запуск процесса неизбежен, фиксируют программу и опции, разрешают только допустимые аргументы и проверяют инъекцию аргументов. Также проверяют обход каталогов, авторизацию каждого инструмента, журналирование и восстановление действий.

Закупка стороннего генеративного продукта. Проверка доказательств поставщика по вопросам Secure by Demand, договорные права на тестирование и повторную проверку, изучение опубликованного прогресса по Secure by Design, если он есть.

Запрос совета директоров или регулятора. Привязка результатов к профилям CSF 2.0, регулярная периодичность и отчётность о трендах по классам CWE. Если речь идёт о формальном соответствии регуляторным требованиям, это отдельная оценка с участием квалифицированных специалистов; пентест её не заменяет.

Ранний прототип. Облегчённый обзор архитектуры по OWASP Top 10 2025 и CWE Top 25 до вложений в полноценное тестирование помогает выявить изменения схемы вызова инструментов до её закрепления в продукте; фактический объём переделок и стоимость зависят от продукта.

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

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

Итог: воспроизводимая оценка вместо разового обзора

Надёжная оценка безопасности генеративного ИИ не требует изобретать новую область с нуля. Она сочетает порядок планирования и выполнения из NIST SP 800-115 с охватом веба и API по WSTG и ASVS, ранжирует находки с опорой на CWE там, где он применим, переводит результаты на язык CSF 2.0 для руководства и предъявляет поставщикам ожидания Secure by Design. Поверх этой основы явно согласуется охват новых каналов, которые приносит генеративная модель: запросов, извлекаемого контента, сгенерированного вывода и вызовов инструментов.

Одно из центральных решений — охват, и принимается оно до начала работ. Письменная фиксация точек входа, приёмников, сред и разрешений помогает получить находки, которые можно воспроизвести, исправить и перепроверить; без этого типовой «обзор безопасности ИИ» может дать отчёт без понятного пути устранения. Если относиться к оценке как к повторяемой программе, привязанной к изменениям модели и интеграций, риски генеративного ИИ становятся измеримыми и управляемыми — в пределах тех сценариев и конфигураций, которые действительно были проверены.