Цепочка поставок
Программные зависимости, контейнерные образы, модельные артефакты, датасеты, промпты, агентные конфигурации и внешние сервисы проверяются раздельно по AI-SUPPLY1–AI-SUPPLY6 и AI-DATA-CHECK1. Проверка одной категории не подтверждает безопасность другой.
Сторонние датасеты
Происхождение и целостность стороннего датасета проверены
Идентификатор требования: AI-SUPPLY1
Применимость
Требование применяется к датасету или RAG-корпусу, полученному от внешнего автора, поставщика или публичного источника.
Требование
До использования должны быть зарегистрированы источник, автор или поставщик, дата получения, версия, условия использования и контрольная сумма принятого объекта. Если автор публикует подпись или контрольную сумму через независимый доверенный канал, она проверяется до распаковки и преобразования. Если независимое подтверждение недоступно, это не подменяется собственной контрольной суммой: риск источника и решение о допуске фиксируются отдельно.
Карточка поставщика дополнительно содержит контакт и точную версию принятого внутреннего объекта; скачивание и импорт выполняются изолированной идентичностью по пути подготовки. Продуктивная система использует только принятую внутреннюю копию, а не внешний изменяемый URL.
Реализация
Полученный объект сначала помещается в область приемки, недоступную продуктивному обучению и поиску. После проверки его неизменяемый идентификатор связывается с записью AI-DATA1.
Проверка
Повторно получите или выберите сохраненный исходный объект, вычислите контрольную сумму и сопоставьте ее с записью приемки и, если доступно, публикацией автора. Измененный объект либо объект без требуемого решения не должен пройти в следующую стадию. Несовпадение контрольной суммы переводит партию в карантин; при провале изолируются и производные объекты — индекс или модель.
Артефакт
- Запись приемки.
- Повторное получение и сопоставление суммы.
- Исходный и внутренний хеши.
- Тест карантина.
Содержимое стороннего датасета проходит приемную проверку
Идентификатор требования: AI-DATA-CHECK1
Применимость
Требование применяется к внешнему, пользовательскому или иному недоверенному набору до обучения, дообучения, оценки или публикации в RAG.
Требование
Для конкретного типа данных владелец должен определить автоматические и ручные проверки: ожидаемый объем и число объектов, форматы и типы полей, обязательные метаданные, категории чувствительных данных, структурные аномалии, дубликаты и выбросы, согласованность источника, управляющие и скрытые символы, неожиданные исполняемые объекты и признаки внедренных инструкций. Результат проверки связывается с точным идентификатором или контрольной суммой входной версии и версиями примененных валидаторов.
Для мультимодального набора дополнительно проверяется скрытое содержимое, если выбранный анализатор способен его выявлять; отсутствие такой возможности указывается как слепая зона, а не как успешная проверка.
Реализация
Объект с ошибкой парсинга, неизвестным типом, запрещенным полем или превышением утвержденного порога не публикуется автоматически. Он отклоняется либо помещается в карантин с причиной, владельцем и решением ручного рассмотрения. Порог статистической аномалии и объем ручной выборки утверждаются политикой конкретного сценария. DSPM может сканировать поддерживаемое хранилище, но не преобразует данные и не доказывает их отсутствие; Guardrails не сканирует корпус вне потока запросов.
Проверка
- Подайте допустимый набор и синтетический набор с неверным объемом, отсутствующими метаданными, несовместимым типом, чувствительным полем, управляющим или скрытым символом и поврежденным объектом.
- Проверьте связь отчета с точной входной версией, автоматическое решение, запись причины, карантин и ручное решение там, где оно предусмотрено.
Ни один отклоненный объект не должен появиться в опубликованной версии. Отсутствие отклоненного объекта подтверждается и в индексе; при провале производные индексы перестраиваются.
Артефакт
- Тестовый набор с ошибками.
- Связь отчета с входной версией.
- Версии валидаторов.
- Подтверждение отсутствия объекта в индексе.
Сторонние модели
Формат, загрузчик и поведение сторонней модели проверены до допуска
Идентификатор требования: AI-SUPPLY2
Применимость
Требование применяется к модели, весам, токенизатору или коду загрузки, полученным вне утвержденного внутреннего конвейера.
Требование
Модельный комплект должен быть связан с проверяемым источником и контрольными суммами. До доступа к продуктивной сети, секретам и данным проверяются формат сериализации, сопутствующий код, пользовательский загрузчик и зависимости; первый запуск выполняется в изолированной среде по AI-MODEL2. Формат, не требующий исполнения произвольного кода при загрузке, предпочтителен, но одно название формата не является свидетельством безопасности.
Реализация
Статическая проверка файла и динамический запуск отвечают на разные вопросы. Объем поведенческих тестов, тестовые входы и критерий допуска определяет владелец риска; стандарт не приписывает облачному сканеру способность анализировать веса или скрытое поведение.
Проверка
Сопоставьте комплект с источником и контрольными суммами, повторите загрузку в изолированной среде и наблюдайте файловые, процессные и сетевые действия. Несовпадение, неожиданное исполнение либо попытка внешней записи блокируют допуск до отдельного решения. После проверки среда первичной загрузки удаляется.
Артефакт
- Комплект с источником.
- Наблюдение за действиями при загрузке.
- Конфигурация среды первичной проверки.
Сторонняя модель проходит формальную процедуру приемки
Идентификатор требования: AI-SUPPLY3
Применимость
Требование применяется до первого продуктивного использования стороннего модельного комплекта и после его существенного изменения.
Требование
Процедура должна включать заявку с назначением, проверку источника и условий использования, проверку целостности, анализ формата и загрузчика, изолированный запуск, результаты утвержденных поведенческих тестов, решение о допуске и регистрацию точной версии. Запрашивающий не должен единолично утвердить свой комплект, если политика организации требует независимого рассмотрения. Подтверждение привязывается к точному хешу пакета приемки; контроль развертывания принимает только утвержденный пакет.
Реализация
Запись приемки связывается с AI-MODEL1, а продуктивный выпуск — с AI-REL1. Повторное использование другой версии по старому решению не допускается.
Ручная проверка
- Выберите работающую стороннюю модель и восстановите заявку, проверенный комплект, результаты, решение и запись реестра.
- Подмените тестовую контрольную сумму или версию: старое решение не должно разрешать новый комплект.
Отсутствующий или просроченный пакет приемки также отклоняется.
Артефакт
- Запись приемки.
- Тест подмены контрольной суммы.
- Пакет приемки и его хеш.
- Подтверждение или исключение.
Уязвимости программных компонентов
Уязвимости зависимостей и контейнерных образов управляются
Идентификатор требования: AI-SUPPLY4
Требование
Организация должна вести перечень программных зависимостей и образов, получать сведения об уязвимостях, определять срок исправления с учетом риска и не выпускать компонент, нарушающий утвержденный критерий. Исключение должно указывать конкретную версию и компенсирующую меру. Сканирование охватывает зависимости приложения и загрузчика модели; находки связываются с манифестом выпуска. При отсутствии контейнера результат N/A допустим для ветви образа, но ветвь зависимостей остается применимой.
Реализация
Container Registry может сканировать Docker-образы вручную, при загрузке или по расписанию; область и результаты описаны в документации сканера и инструкции по сканированию. Сканер не анализирует модельные веса, поведение модели, RAG-корпус или внешний сервис.
Проверка
- Сопоставьте дайджест продуктивного образа и версии зависимостей с актуальными результатами.
- Проверьте обработку тестовой находки и невозможность выпуска версии, которая нарушает утвержденный критерий.
Откат к ранее принятому дайджесту выполняется только после проверки его уязвимостей.
Артефакт
- Дайджест образа.
- Актуальные результаты сканирования.
- Тест выпуска.
- Отчет о зависимостях.
- Событие повторного развертывания.
Воспроизводимый состав выпуска
Для выпуска известен состав программных и ИИ-компонентов
Идентификатор требования: AI-SUPPLY5
Требование
Для каждого выпуска должен быть сохранен воспроизводимый перечень программных зависимостей, образов, модели, адаптеров и токенизатора, конфигурации, промптов, примененных Guardrails и экземпляра модели, инструментов и MCP, внешнего провайдера и источников данных или индекса.
Для программной части рекомендуется формировать SBOM в стандартном машиночитаемом формате. Для модели и данных может потребоваться отдельный манифест, поскольку программный SBOM не описывает их смысл и происхождение.
Если конвейер формирует SBOM, подпись или аттестацию, на них дается ссылка, но они не называются нативным контролем Yandex Cloud.
Реализация
Документированные функции Container Registry включают хранение и распространение Docker-образов и сканирование уязвимостей. Эти результаты сами по себе не являются полным SBOM или аттестацией выпуска. Организация выбирает отдельный инструмент формирования и проверки и связывает результат с дайджестом выпуска.
Проверка
Восстановите состав работающей версии из сохраненного манифеста и сравните контрольные суммы с фактическими объектами. Неописанный компонент или плавающая версия означает, что выпуск невоспроизводим. Проверка должна обнаружить намеренно пропущенный или измененный компонент.
Артефакт
- Сохраненный манифест.
- Сравнение с фактическими объектами.
- Хеш манифеста.
- Карточки компонентов.
Изменение риска поставщика
Изменение компонента или внешнего сервиса вызывает повторную оценку
Идентификатор требования: AI-SUPPLY6
Требование
Владелец должен определить официальные каналы и публичные источники уведомлений поставщика о безопасности и обрабатывать сведения о компрометации, критической уязвимости, отзыве, изменении условий или недоступности модели, данных, библиотеки, образа или внешнего API. Процедура должна позволять определить затронутые выпуски, ограничить использование, заменить компонент и повторить связанные проверки.
Реализация
Для внешнего сервиса учитываются изменение API, модели, региона обработки, условий хранения и телеметрии. Yandex Cloud не управляет правами и жизненным циклом внешнего поставщика, если отдельная интеграция прямо не документирована. Security Deck и YCDR используются только для сигнала, который фактически поступает в настроенный контур, и не заменяют мониторинг поставщика.
Ручная проверка
Возьмите тестовое уведомление об отзыве версии и проследите поиск затронутых систем, решение об ограничении, замену и повторную проверку. Реестр должен позволять сделать это по точной версии, а не только по названию продукта. Имитация изменения версии, уведомления или эндпоинта должна создавать повторную оценку и предотвращать незаметное расхождение продуктивной среды; работа с неизвестной версией не продолжается незаметно.
Артефакт
- Тестовое уведомление.
- Поиск систем.
- Решение об ограничении.
- Затронутые манифесты выпусков.
- Тикет.