Риски безопасности ИИ: понимание новой угрозы для цепочки поставок и ее последствий.

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

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

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

📌 Рекомендации OWASP по рискам в цепочке поставок LLM В этом вопросе все предельно ясно. Безопасность цепочки поставок ИИ — это работа по обеспечению безопасности всей цепочки зависимостей. Она охватывает модели, данные, инструменты и инфраструктуру, от которых зависит система ИИ для ответа на вопросы, получения информации, принятия решений и выполнения действий.

Основные темы, рассмотренные в данном анализе:

• Что включает в себя безопасность цепочки поставок с использованием ИИ?и чем это отличается от традиционной безопасности цепочки поставок программного обеспечения.
• Риск проявляется на практике, начиная от чрезмерно сложных соединителей и заканчивая отравленными источниками извлечения данных.
• Почему ограничительные меры на уровнях модели по-прежнему полезны, но сами по себе недостаточны
• Как комплексные платформы обеспечивают безопасность цепочки поставок с использованием ИИ за счет повышения прозрачности моделей, инструментов и облачных ресурсов.

Что такое безопасность цепочки поставок с использованием ИИ и почему она более опасна?

Настоящая безопасность цепочки поставок с использованием ИИ. Это включает в себя обеспечение безопасности всех компонентов, от которых зависит система искусственного интеллекта, включая модели, данные, инструменты, коннекторы и облачную инфраструктуру.

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

• Сама модель
• Данные, используемые для обучения, тонкой настройки, привязки или извлечения.
• Уровень оркестровки, который маршрутизирует запросы и вызовы инструментов.
• Инструменты и коннекторы, обеспечивающие доступ к внутренним и сторонним системам.
• Облачная инфраструктура, которая размещает и предоставляет доступ к этим сервисам.
• Личности и секреты, позволяющие одному компоненту вызывать другой.

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

Где на практике проявляются риски, связанные с ИИ в цепочке поставок

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

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

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

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

Почему инструменты и агенты увеличивают риск

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

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

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

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

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

Почему традиционных мер защиты ИИ недостаточно

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

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

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

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

Что должны делать компании для обеспечения безопасности цепочки поставок ИИ?

Первый шаг — составить полную карту стека искусственного интеллекта.Это означает выявление:

• Какие модели используются?
• На какие источники данных они полагаются
• Какие фреймворки оркестровки используются в их системах?
• Какие агенты активны?
• К каким инструментам и разъемам они могут получить доступ
• Какие облачные сервисы размещают или предоставляют доступ к этим компонентам?

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

✅ Рекомендации:

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

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

Платформенный подход к обеспечению безопасности цепочки поставок с использованием ИИ.

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

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

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

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

Заключение

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

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