Оценка безопасности моделей ИИ: охват, тестирование и выбор исполнителя

Условная страховая компания купила у подрядчика дообученную модель, которая читает сканы заявлений об убытках и присваивает им категорию риска. Модель работает во внутреннем кластере, система урегулирования обращается к ней через REST API, а новые версии весов подрядчик раз в квартал выкладывает в общий реестр моделей. Перед подключением новых продуктов служба безопасности просит «проверить безопасность модели» и получает два предложения. В первом — веб-пентест API и отчёт «по OWASP Top 10». Во втором — встречные вопросы: кто вправе загружать веса в реестр, в каком формате они хранятся, увидит ли исполнитель журналы запросов и можно ли получить копию артефакта.

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

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

Из чего состоит оценка безопасности модели

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

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

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

Для генеративных моделей полезный ориентир — OWASP Top 10 for LLM Applications в редакции 2026 года, где цепочка поставки (LLM04 Supply Chain), отравление данных и модели (LLM05 Data and Model Poisoning) и раскрытие чувствительной информации (LLM02 Sensitive Information Disclosure) выделены в отдельные категории. Но это перечень рисков для повышения осведомлённости, а не стандарт верификации и не сертификация: он подсказывает, о чём спросить, а не как проверить конкретную модель. О проверке генеративных систем целиком — в материале об оценке безопасности генеративного ИИ.

Уровень доступа задаёт границы выводов

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

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

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

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

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

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

Артефакт модели и цепочка поставки

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

Первый вопрос — кто может записывать в реестр. Если токен конвейера или учётная запись подрядчика публикуют версии без отдельного согласования, всё остальное зависит от гигиены владельца токена. Второй — формат. Некоторые форматы на основе универсальной сериализации объектов, например pickle в Python, позволяют закодировать объекты, небезопасная десериализация которых исполняет код. Загрузка недоверенного артефакта таким десериализатором поэтому может привести к выполнению кода — проявлению CWE-502. Форматы, хранящие только тензоры, снижают этот риск, но не отвечают на вопрос, чьи это веса. Третий — загрузчик: некоторые библиотеки умеют подтягивать вместе с моделью исполняемый код из репозитория, и такие опции должны быть осознанным решением, а не значением по умолчанию из примера.

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

1. Широкие права на запись в реестрТокен конвейера или учётная запись подрядчика может загружать новые версии весов без отдельного согласования и без проверки происхождения.
2. Подменённый артефактВ реестр попадает файл с изменёнными весами или с исполняемой нагрузкой в формате, который допускает выполнение кода при десериализации.
3. Загрузка без сверкиРазвертывание берёт «последнюю версию» и не сверяет хэш или подпись с эталоном, записанным вне реестра.
4. Тихий эффектКод исполняется на узле инференса или модель начинает иначе классифицировать узкий класс входов; функциональные тесты этого могут не заметить.

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

Отравление данных: что проверить можно, а что нет

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

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

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

Поведение модели: устойчивость и приватность

Находкам модельного уровня нужна своя терминология, иначе их путают с веб-уязвимостями. Удобная основа — NIST AI 100-2 E2025, задающий таксономию и терминологию атак состязательного машинного обучения и мер защиты. В нём, в частности, различаются атаки уклонения (входы, подобранные, чтобы изменить ответ модели при эксплуатации), атаки отравления (воздействие при обучении) и атаки на приватность — например, попытки установить, входила ли запись в обучающие данные, или воспроизвести поведение модели по её ответам.

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

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

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

Генеративные модели: утечки и скрытый контекст

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

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

Если модель доступна через веб-интерфейс или API, к этой поверхности применяется зрелая методика веб-тестирования. OWASP публикует Web Security Testing Guide по тестированию безопасности веб-приложений; в этом материале выпуск 4.2 зафиксирован как пример, а в каждом проекте нужно указывать фактически использованную версию без утверждений о текущем статусе другой редакции. OWASP ASVS задаёт требования к техническим механизмам защиты и ставит целью выровнять разброс охвата и строгости проверок на рынке. В этой статье используется ASVS 5.0.0; на требования рекомендуется ссылаться версионированными идентификаторами вида v5.0.0-1.2.5, поскольку нумерация между версиями меняется, а списки требований доступны в том числе в CSV и JSON. OWASP Top 10 2025 — документ для повышения осведомлённости, поэтому «покрытие Top 10» в отчёте говорит меньше, чем ссылки на конкретные требования ASVS.

Вокруг модели появляются характерные объекты проверки. Изоляция дообученных моделей разных клиентов: может ли клиент А, изменив идентификатор модели в запросе, обратиться к модели клиента Б? Это обычная ошибка объектной авторизации с модельными последствиями — доступом к поведению, обученному на чужих данных. Служебные методы загрузки, отката и переключения версий: кто может их вызвать и проверяется ли это на сервере. Параметры инференса от клиента: без ограничений на размер ответа и число вариантов один запрос может израсходовать чрезмерные ресурсы и создать лишние начисления при тарификации по потреблению. Журналы: запросы и ответы могут содержать персональные данные, поэтому их минимизируют, маскируют, ограничивают к ним доступ и задают сроки хранения.

Подробнее о методике для интерфейсов — в статье об оценке безопасности REST API.

Когда вывод модели становится командой

Ответ модели нельзя считать доверенным только потому, что его сгенерировала «своя» система. Если категория риска, имя файла или фрагмент запроса из вывода модели уходят дальше — в SQL, шаблон, командную строку, — к ним применяются те же требования, что и к пользовательскому вводу, включая требование ASVS о защите от внедрения команд ОС. Важная деталь: передача аргументов отдельными элементами массива, без командной оболочки, защищает от интерпретации спецсимволов, но не от внедрения аргументов — значение, начинающееся с дефиса, программа может принять за опцию. Нужны списки допустимых значений, проверка формата и, где утилита это поддерживает, явный разделитель конца опций.

Планирование работ: дисциплина NIST SP 800-115

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, опубликован в сентябре 2008 года и заменил SP 800-42. Он помогает планировать и проводить технические тесты и обследования, анализировать находки и вырабатывать меры по снижению риска. Формально документ делит оценку на три фазы — планирование, выполнение и пост-выполнение (post-execution) — и описывает преимущества и ограничения каждого технического метода. Сам он оговаривает, что не является исчерпывающей программой тестирования, и появился задолго до современных моделей, поэтому даёт дисциплину процесса, а не тест-кейсы для ИИ: это каркас проекта, а не его содержание.

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

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

К трём фазам SP 800-115 мы на практике добавляем цикл устранения и повторной проверки. Это не часть документа, а рабочая привычка, без которой отчёт заканчивается списком находок, а не подтверждённым снижением риска.

Приоритизация: классы слабостей CWE и контекст модели

Сопоставление находки с применимым классом слабости CWE переводит разговор с одного экземпляра на более широкий тип дефекта и помогает планировать системное исправление. CWE Top 25 Most Dangerous Software Weaknesses за 2025 год и анализ 2025 CWE Top 10 KEV Weaknesses могут служить входными данными для приоритизации разработки, но ни один рейтинг не определяет приоритет сам по себе: нужны контекст достижимого пути атаки, возможного ущерба и действующих мер защиты. Анализ на основе KEV ранжирует классы слабостей по их связи с уязвимостями из каталога известных эксплуатируемых уязвимостей CISA.

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

Для системы с моделью картина понятная. Небезопасная десериализация в загрузчике, отсутствие проверки авторизации в API выбора модели, внедрение команд при обработке вывода хорошо ложатся на CWE. Поведенческие находки — уклонение, запоминание данных — нет: их лучше классифицировать по таксономии NIST AI 100-2 и оценивать по влиянию на решения и данные. Как строить такую приоритизацию, разобрано в материале о риск-ориентированной приоритизации уязвимостей.

Что принимать как результат и как проверять исправления

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

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

Компромиссы и ограничения общих стандартов

Ширина и глубина конкурируют за один бюджет: глубокий тест поведения может упустить ошибку авторизации в API, широкий обзор по стандартам — дефект в загрузчике. Хорошее предложение показывает этот компромисс явно и объясняет выбранный баланс.

Общие рамки оставляют пробелы. SP 800-115, WSTG, ASVS, CWE и CSF — документы по тестированию, верификации и управлению рисками, а не стандарты защиты моделей, поэтому тест-кейсы модельного уровня должны входить в задокументированную методику исполнителя. Ссылка на рамку — не доказательство охвата ИИ.

Стандарты меняются: например, WSTG 4.2 можно зафиксировать как использованную редакцию, у OWASP Top 10 есть редакции 2017, 2021 и 2025 годов, ASVS предупреждает о смене идентификаторов между версиями, а нумерация OWASP Top 10 for LLM Applications 2026 года отличается от прежних редакций. В каждом случае указывают версию, действующую для конкретной оценки, без плавающего утверждения о «последней» или разрабатываемой редакции. Поэтому в договоре и отчёте фиксируют точные версии, иначе находки разных лет не сравнить.

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

Отчётность для руководства и регулярность оценок

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

Чтобы отчёт не лёг в архив, его превращают в рабочие артефакты: применимые к веб-контролям требования ASVS в CSV или JSON импортируют в систему учёта задач, чтобы у каждого такого контроля были владелец и статус; для остальных компонентов используют соответствующие им критерии, а применимые классы слабостей CWE — для улучшения практик безопасной разработки; версии стандартов и хэши проверенных артефактов записывают, чтобы следующая оценка измеряла реальные изменения.

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

Как выбрать исполнителя

Сравнивать поставщиков стоит, когда ответы на технические вопросы выше уже есть, иначе сравниваются формулировки, а не предложения. Попросите каждого исполнителя описать охват одинаковыми терминами. Какие компоненты входят в работы — API, модель, артефакт, реестр, конвейер — и при каком уровне доступа? Какой документ и какая точная версия применяются к каждому компоненту? Какие проверки модельного уровня добавлены сверх веб-тестирования и где описана методика? Как программные находки сопоставляются с применимыми классами слабостей CWE, а находки модельного уровня — с результатами CSF 2.0 и категориями таксономии NIST AI 100-2? Какие ограничения у каждого метода? Как проверяются ИИ-инструменты, если исполнитель ими пользуется? Какие разрешения и правила обращения с данными будут регулировать работы?

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

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

Итог: как выглядит достоверная оценка модели

Достоверная оценка безопасности модели ИИ проводится при наличии письменного разрешения каждой стороны, уполномоченной разрешать тестирование в своей зоне, и явно определяет охват применимых слоёв: артефакта и цепочки поставки, поведения модели, приложения и API, управления. SP 800-115, WSTG, ASVS, CWE и CSF 2.0 дают ей дисциплину процесса и общий язык отчётности, а таксономия NIST AI 100-2 — словарь для находок модельного уровня, но ни один из этих документов не заменяет методику проверки самой модели.

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