[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > Цепочка поставок

# Цепочка поставок

{#supply-chain}

Программные зависимости, контейнерные образы, модельные артефакты, датасеты, промпты, агентные конфигурации и внешние сервисы проверяются раздельно по `AI-SUPPLY1`–`AI-SUPPLY6` и `AI-DATA-CHECK1`. Проверка одной категории не подтверждает безопасность другой.

## Сторонние датасеты {#third-party-datasets}

### Происхождение и целостность стороннего датасета проверены {#third-party-dataset-provenance-integrity-verified}

{#ai-supply1-id}

Идентификатор требования: `AI-SUPPLY1`

{#ai-supply1-applicability}

**Применимость**

Требование применяется к датасету или RAG-корпусу, полученному от внешнего автора, поставщика или публичного источника.

{#ai-supply1-requirement}

**Требование**

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

Карточка поставщика дополнительно содержит контакт и точную версию принятого внутреннего объекта; скачивание и импорт выполняются изолированной идентичностью по пути подготовки. Продуктивная система использует только принятую внутреннюю копию, а не внешний изменяемый URL.

{#ai-supply1-implementation}

**Реализация**

Полученный объект сначала помещается в область приемки, недоступную продуктивному обучению и поиску. После проверки его неизменяемый идентификатор связывается с записью `AI-DATA1`.

{#ai-supply1-check}

**Проверка**

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

{#ai-supply1-artifacts}

**Артефакт**

* Запись приемки.
* Повторное получение и сопоставление суммы.
* Исходный и внутренний хеши.
* Тест карантина.

### Содержимое стороннего датасета проходит приемную проверку {#third-party-dataset-content-intake-check}

{#ai-data-check1-id}

Идентификатор требования: `AI-DATA-CHECK1`

{#ai-data-check1-applicability}

**Применимость**

Требование применяется к внешнему, пользовательскому или иному недоверенному набору до обучения, дообучения, оценки или публикации в RAG.

{#ai-data-check1-requirement}

**Требование**

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

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

{#ai-data-check1-implementation}

**Реализация**

Объект с ошибкой парсинга, неизвестным типом, запрещенным полем или превышением утвержденного порога не публикуется автоматически. Он отклоняется либо помещается в карантин с причиной, владельцем и решением ручного рассмотрения. Порог статистической аномалии и объем ручной выборки утверждаются политикой конкретного сценария. [DSPM](../../security-deck/concepts/dspm.md) может сканировать поддерживаемое хранилище, но не преобразует данные и не доказывает их отсутствие; Guardrails не сканирует корпус вне потока запросов.

{#ai-data-check1-check}

**Проверка**

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

Ни один отклоненный объект не должен появиться в опубликованной версии. Отсутствие отклоненного объекта подтверждается и в индексе; при провале производные индексы перестраиваются.

{#ai-data-check1-artifacts}

**Артефакт**

* Тестовый набор с ошибками.
* Связь отчета с входной версией.
* Версии валидаторов.
* Подтверждение отсутствия объекта в индексе.

## Сторонние модели {#third-party-models}

### Формат, загрузчик и поведение сторонней модели проверены до допуска {#third-party-model-format-loader-behavior-checked}

{#ai-supply2-id}

Идентификатор требования: `AI-SUPPLY2`

{#ai-supply2-applicability}

**Применимость**

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

{#ai-supply2-requirement}

**Требование**

Модельный комплект должен быть связан с проверяемым источником и контрольными суммами. До доступа к продуктивной сети, секретам и данным проверяются формат сериализации, сопутствующий код, пользовательский загрузчик и зависимости; первый запуск выполняется в изолированной среде по `AI-MODEL2`. Формат, не требующий исполнения произвольного кода при загрузке, предпочтителен, но одно название формата не является свидетельством безопасности.

{#ai-supply2-implementation}

**Реализация**

Статическая проверка файла и динамический запуск отвечают на разные вопросы. Объем поведенческих тестов, тестовые входы и критерий допуска определяет владелец риска; стандарт не приписывает облачному сканеру способность анализировать веса или скрытое поведение.

{#ai-supply2-check}

**Проверка**

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

{#ai-supply2-artifacts}

**Артефакт**

* Комплект с источником.
* Наблюдение за действиями при загрузке.
* Конфигурация среды первичной проверки.

### Сторонняя модель проходит формальную процедуру приемки {#third-party-model-formal-acceptance-procedure}

{#ai-supply3-id}

Идентификатор требования: `AI-SUPPLY3`

{#ai-supply3-applicability}

**Применимость**

Требование применяется до первого продуктивного использования стороннего модельного комплекта и после его существенного изменения.

{#ai-supply3-requirement}

**Требование**

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

{#ai-supply3-implementation}

**Реализация**

Запись приемки связывается с `AI-MODEL1`, а продуктивный выпуск — с `AI-REL1`. Повторное использование другой версии по старому решению не допускается.

{#ai-supply3-manual-check}

**Ручная проверка**

1. Выберите работающую стороннюю модель и восстановите заявку, проверенный комплект, результаты, решение и запись реестра.
1. Подмените тестовую контрольную сумму или версию: старое решение не должно разрешать новый комплект.

Отсутствующий или просроченный пакет приемки также отклоняется.

{#ai-supply3-artifacts}

**Артефакт**

* Запись приемки.
* Тест подмены контрольной суммы.
* Пакет приемки и его хеш.
* Подтверждение или исключение.

## Уязвимости программных компонентов {#dependency-vulns}

### Уязвимости зависимостей и контейнерных образов управляются {#dependency-container-image-vulns-managed}

{#ai-supply4-id}

Идентификатор требования: `AI-SUPPLY4`

{#ai-supply4-requirement}

**Требование**

Организация должна вести перечень программных зависимостей и образов, получать сведения об уязвимостях, определять срок исправления с учетом риска и не выпускать компонент, нарушающий утвержденный критерий. Исключение должно указывать конкретную версию и компенсирующую меру. Сканирование охватывает зависимости приложения и загрузчика модели; находки связываются с манифестом выпуска. При отсутствии контейнера результат `N/A` допустим для ветви образа, но ветвь зависимостей остается применимой.

{#ai-supply4-implementation}

**Реализация**

[Container Registry](../../container-registry/index.md) может сканировать Docker-образы вручную, при загрузке или по расписанию; область и результаты описаны в [документации сканера](../../container-registry/concepts/vulnerability-scanner.md) и [инструкции по сканированию](../../container-registry/operations/scanning-docker-image.md). Сканер не анализирует модельные веса, поведение модели, RAG-корпус или внешний сервис.

{#ai-supply4-check}

**Проверка**

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

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

{#ai-supply4-artifacts}

**Артефакт**

* Дайджест образа.
* Актуальные результаты сканирования.
* Тест выпуска.
* Отчет о зависимостях.
* Событие повторного развертывания.

## Воспроизводимый состав выпуска {#reproducible-release}

### Для выпуска известен состав программных и ИИ-компонентов {#release-software-ai-components-known}

{#ai-supply5-id}

Идентификатор требования: `AI-SUPPLY5`

{#ai-supply5-requirement}

**Требование**

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

Для программной части рекомендуется формировать SBOM в стандартном машиночитаемом формате. Для модели и данных может потребоваться отдельный манифест, поскольку программный SBOM не описывает их смысл и происхождение.

Если конвейер формирует SBOM, подпись или аттестацию, на них дается ссылка, но они не называются нативным контролем Yandex Cloud.

{#ai-supply5-implementation}

**Реализация**

Документированные функции [Container Registry](../../container-registry/index.md) включают хранение и распространение Docker-образов и сканирование уязвимостей. Эти результаты сами по себе не являются полным SBOM или аттестацией выпуска. Организация выбирает отдельный инструмент формирования и проверки и связывает результат с дайджестом выпуска.

{#ai-supply5-check}

**Проверка**

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

{#ai-supply5-artifacts}

**Артефакт**

* Сохраненный манифест.
* Сравнение с фактическими объектами.
* Хеш манифеста.
* Карточки компонентов.

## Изменение риска поставщика {#supplier-risk-change}

### Изменение компонента или внешнего сервиса вызывает повторную оценку {#component-external-service-change-triggers-reassessment}

{#ai-supply6-id}

Идентификатор требования: `AI-SUPPLY6`

{#ai-supply6-requirement}

**Требование**

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

{#ai-supply6-implementation}

**Реализация**

Для внешнего сервиса учитываются изменение API, модели, региона обработки, условий хранения и телеметрии. Yandex Cloud не управляет правами и жизненным циклом внешнего поставщика, если отдельная интеграция прямо не документирована. [Security Deck](../../security-deck/index.md) и [YCDR](../../ycdr/index.md) используются только для сигнала, который фактически поступает в настроенный контур, и не заменяют мониторинг поставщика.

{#ai-supply6-manual-check}

**Ручная проверка**

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

{#ai-supply6-artifacts}

**Артефакт**

* Тестовое уведомление.
* Поиск систем.
* Решение об ограничении.
* Затронутые манифесты выпусков.
* Тикет.