Агентство по кибербезопасности и защите инфраструктуры США (CISA) и его партнеры из киберведомств стран G7 опубликовали перечень минимальных элементов для спецификации материалов программного обеспечения с ИИ (AI SBOM). Этот шаг может помочь руководителям по информационной безопасности (CISO) оценить безопасность и происхождение систем искусственного интеллекта, внедряемых в корпоративные среды.
Руководство расширяет традиционные концепции SBOM на ИИ, требуя документирования моделей, наборов данных, программных компонентов, поставщиков, лицензий и других зависимостей. Дополнительные минимальные элементы не являются исчерпывающими или обязательными, заявили в CISA, но отражают консенсус экспертов G7 и, как ожидается, будут расширяться по мере развития технологий ИИ.
Для руководителей служб безопасности этот документ более прочно встраивает риски ИИ в сферу надзора за корпоративной цепочкой поставок. Это может сделать AI SBOM частью тех же обсуждений рисков поставщиков, которые уже окружают состав программного обеспечения, облачные сервисы и сторонние технологические платформы.
Однако есть одно важное отличие: AI SBOM требуют видимости, выходящей за рамки состава программного обеспечения, поскольку риск ИИ формируется моделями, данными, инфраструктурой и поведением системы.
«Системы ИИ добавляют новые уровни непрозрачности: происхождение модели, данные для обучения и инференса, история тонкой настройки, промпты, векторные базы данных, сторонние базовые модели, API, логика оркестрации и поведение во время выполнения», — отметила Сакши Гровер, старший менеджер по исследованиям в области услуг кибербезопасности IDC Asia Pacific.
Программное обеспечение с ИИ также отличается тем, что оно вероятностное, и его результаты формируются как происхождением данных, так и кодом, по словам Кейта Прабху, основателя и генерального директора Confidis.
«Программное обеспечение с ИИ по своей сути включает в себя больше, чем просто программное обеспечение», — сказал Прабху. «В дополнение к программным компонентам необходимо отслеживать модели, обучающие данные, промпты и системные инструкции, веса моделей и контрольные точки, а также зависимости от GPU».
Санчит Вир Гогиа, главный аналитик Greyhound Research, более широко охарактеризовал этот сдвиг.
«Вопрос больше не только в том, «какой код находится внутри этого продукта?». Вопрос в том, «какой код, модель, данные, инфраструктура, контроль и решение поставщика формируют поведение этой системы?»», — сказал Гогиа.
Как это использовать
Непосредственное применение руководства может заключаться в управлении закупками и рисками поставщиков. Оно дает командам по безопасности возможность предъявлять требования поставщикам до того, как продукты с поддержкой ИИ будут допущены к эксплуатации.
«Организации должны запрашивать у поставщиков информацию о происхождении модели, источниках обучающих данных, зависимостях программного обеспечения и API, лицензионных обязательствах, методах тестирования безопасности, циклах обновлений, элементах управления мониторингом во время выполнения и границах совместной ответственности», — отметила Гровер.
Уровень проверки также может зависеть от типа поставщика.
«Для крупных поставщиков CISO должны особо добиваться прозрачности в отношении зависимостей от сторонних базовых моделей, географических потоков данных, методов обновления моделей и того, сохраняются ли данные клиентов для обучения или тонкой настройки модели», — добавила Гровер. «Для стартапов акцент должен быть сделан на зрелости процессов управления, отслеживании зависимостей, безопасных практиках разработки, контроле идентификации и оперативном мониторинге на протяжении всего жизненного цикла ИИ».
Тот же подход, основанный на оценке рисков, должен применяться и к тому, как будет использоваться технология. Для развертываний с более высоким уровнем риска, по словам Гогиа, AI SBOM должны стать частью более широкого пакета доказательств от поставщика, подкрепленного документацией о потоках данных, архитектуре безопасности, поведении модели, влиянии на конфиденциальность, результатах red-team тестирования, реагировании на инциденты, логировании и тестировании на инъекции промптов.
Оставшиеся пробелы
Самый большой пробел заключается в том, что AI SBOM может показать, что, по утверждению поставщика, находится внутри системы ИИ, но не доказывает, можно ли доверять этой системе в том виде, в котором предприятие планирует ее использовать.
«Минимальные элементы обеспечивают видимость», — сказал Гогиа. «Они не обеспечивают уверенности. Они сообщают покупателю, что, по словам поставщика, существует. Они сами по себе не доказывают, что каждая зависимость раскрыта, каждый набор данных законен, каждый контроль работает, каждая модель ведет себя в пределах допуска или что каждый путь выполнения отслеживается».
Сложной задачей будет доказать, что документ соответствует действительности. Команды по безопасности могут получить AI SBOM от поставщика, но им все равно необходимо определить, отражает ли он систему, работающую в продакшене, и успевает ли он за изменениями в среде ИИ. Прабху отметил, что даже высококачественный AI SBOM даст лишь частичное представление о рисках ИИ. Такие проблемы, как меняющееся поведение ИИ, галлюцинации, изменение использования промптов и ограниченная прозрачность обучающих данных, по-прежнему могут затруднять руководителям служб безопасности оценку реального риска. По мере созревания систем ИИ, AI SBOM также должны будут развиваться для устранения этих пробелов, добавил Прабху.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Prasanth Aby Thomas
