Регуляторы больше не согласны с принципом «доверие как политика».
Раньше эта цепочка была проблемой внутренней зрелости, чем-то, над чем программа безопасности могла работать со временем:
Разработчик доверяет сгенерированному ИИ коду, потому что он компилируется. Рецензент доверяет сгенерированной ИИ сводке, потому что она выглядит правдоподобно. Команда безопасности доверяет выводу сканера, потому что конвейер горит зеленым. Аудитор доверяет доказательствам, потому что контрольный список заполнен. Ни на одном этапе никто не проверяет сам объект. Каждый человек лишь подтверждает, что предыдущий шаг выглядел нормально.
Теперь это не так. Закон ЕС об ИИ, Закон о киберустойчивости (Cyber Resilience Act), NIS2 и DORA теперь предполагают или требуют документированную инвентаризацию и подтверждаемый надзор за системами с поддержкой ИИ. Стандарт ISO 42001 превращает эту базу в реальную систему управления с ответственными лицами, оценкой рисков, контролем жизненного цикла и мониторингом. Ни один из этих фреймворков не примет «зеленый конвейер» в качестве доказательства. Они задают другие вопросы: можете ли вы предоставить инвентаризационный список и можете ли вы доказать, что политика соблюдалась.
Это пробел, с которым большинство организаций скоро столкнутся на собственном горьком опыте. Только 22% организаций имеют сегодня официальную политику управления ИИ. Пробел глубже, чем просто внедрение: руководство считает, что примерно 27% ИИ-активов стандартизированы и управляются; практики, работающие с ними напрямую, оценивают этот показатель в 12%. Именно такой разрыв между отчетом о соответствии и реальным положением дел обучен находить аудитор.
Но насколько сложно составить список ИИ-активов?
Цепочка поставок ИИ больше, чем вы думаете, и растет быстрее
Искусительно представлять ИИ в цепочке поставок как несколько вызовов LLM API. На практике ИТ-инфраструктура продолжает расширяться, включая фреймворки агентов, способных к автономным действиям, уровни оркестрации и все чаще серверы MCP, соединяющие ассистенты с инструментами, файлами и данными.
Каждая загружаемая командой модель поставляется не только с весами. Она содержит скрипты загрузки и файлы настройки, которые выполняются в среде в тот момент, когда модель загружается — без запроса на слияние (pull request), без код-ревью, без шлюза безопасности. Файл на базе pickle может содержать исполняемые опкоды и хелперы пересборки Torch, способные проводить атаки десериализации. Вызов trust_remote_code=True передает загруженному скрипту права на выполнение во время работы. Помощники по программированию усугубляют проблему с другой стороны: модель рекомендует пакет, пакет оказывается вредоносным, а уязвимость не записана в код — она установлена.
Разработчики, использующие ИИ, пишут код в 3–4 раза быстрее своих коллег, но создают уязвимости в 10 раз чаще (Cloud Security Alliance, 2026). Значительная доля того, что накапливается под этой цифрой, вообще не является уязвимостью в коде — это неуправляемая модель, сервер MCP с избыточными правами или файл навыков, содержащий инструкцию, которую никто не проверял. Ничто из этого не соотносится с контрольным списком, составленным до появления этого класса активов.
Инструменты AppSec никогда не были предназначены для решения этой задачи
Дело не в плохом поведении разработчиков. Дело в давлении. Разработчики работают под дедлайном, стремясь побыстрее добраться до статуса «готово», и непроверенные инструменты ИИ отлично в этом помогают. Команды безопасности обычно знают, какие корпоративные платформы ИИ официально одобрены, но у них гораздо меньше видимости в отношении расширений браузера, плагинов IDE, CLI-агентов и MCP-серверов, которые разработчики используют ежедневно.
Большинство инструментов AppSec не могут ответить на этот вопрос, потому что они изначально не были созданы для работы с этим классом активов. SAST читает исходный код. SCA читает заявленные зависимости. Ни один из них не может открыть файл .pt, .pth или .pkl и рассказать, что внутри.
Причина, по которой инструменты не видят этого, заключается в том, что компоненты ИИ ведут себя не так, как цепочки поставок программного обеспечения, под которые создавались регуляторные требования и AppSec. Значительная их часть вообще не является зависимостями. Это вызов API к эндпоинту модели, системный промпт в конфигурационном файле, файл навыка, определение агента.
Вопрос риска меняется соответствующим образом: не «уязвима ли эта версия?», а «отравлена ли эта модель?», «не слишком ли много прав у этого сервера MCP?», «содержит ли этот файл навыков внедренную инструкцию, которую никто не проверил?». Ни один из этих вопросов четко не соотносится с контрольным списком, составленным до появления этого класса активов.
По сути, ИИ добавляет второй, более сложный слой, который традиционные инструменты AppSec сегодня не могут обнаружить, включая:
- Кто или что создало этот код?
- К какому контексту модель имела доступ при его генерации?
- Если агент вызывал инструменты, то какие именно и какие данные он читал?
- Была ли проверка с участием человека реальным решением или формальной отметкой на пути к релизу?
Ничто из этого не заменяет существующие средства контроля. SCA по-прежнему важен; фреймворк оркестрации или библиотека ИИ вполне могут содержать критическую уязвимость CVE, и именно для ее обнаружения создавался SCA. Риски, специфичные для ИИ, требуют выхода за рамки этого подхода, а не его отмены.
Решение: единая инвентаризация, соотнесенная с требованиями регуляторов
Нельзя управлять тем, чего нет в инвентаризации. И нельзя провести инвентаризацию, попросив ИИ отчитаться о самом себе. Это просто превращает обнаружение в очередное голословное утверждение.
Здесь на помощь приходит безопасность цепочки поставок ИИ (AI Supply Chain Security). Это не навесной сканер, а детерминированное обнаружение каждой модели, сервера MCP, агента и набора данных во всех ваших приложениях.
Сканеры LLM подключаются непосредственно к местам хранения моделей: репозиториям Hugging Face, внутренним реестрам, локальным каталогам, репозиториям Git — и выполняют статическую аналитику по всей поверхности проекта: исходному коду Python, блокнотам и бинарным форматам моделей, включая PyTorch, Keras и файлы на базе pickle, выискивая небезопасную десериализацию, опасные загрузчики моделей, выполнение оболочки, а также специфические опкоды и хелперы пересборки, которые позволяют модели выполнять код во время загрузки. Модель никогда не запускается. Никаких потерь производительности, никакого нарушения работы конвейера ML. Такая же строгость распространяется на серверы MCP (оценивается соответствие разрешенных инструментов подключенного сервера заявленным функциям) и на фреймворки агентов.
Каждое сканирование формирует один артефакт: AI-BOM (спецификацию компонентов ИИ), представляющую собой экспортируемую инвентаризацию каждой модели, пакета SDK, агента, сервера MCP, навыка и набора данных во всей инфраструктуре, соотнесенную напрямую с требованиями документации законов ЕС об ИИ, NIS2, DORA и ISO 42001.
Ландшафт регулирования и стандартов ИИ: как Checkmarx может помочь
Политика без шлюза — это совет, а не управление. Обеспечение соблюдения политик означает, что компонентам ИИ присваиваются оценки, назначаются владельцы и устанавливаются шлюзы с той же дисциплиной, что и для любых других уязвимостей безопасности, с использованием обнаружения, достаточно детерминированного, чтобы служить доказательством, а не оценки уверенности от самой модели, оценивающей свою работу.
И поскольку внедрение ИИ больше не ограничивается только инженерным отделом, управление не может останавливаться и на традиционном периметре AppSec. Каждый сотрудник все в большей степени является разработчиком чего-либо: скрипта, автоматизации, внутреннего инструмента — а это значит, что управлению нужны легковесные средства контроля, охватывающие те части организации, которые раньше вообще не попадали в поле зрения безопасности.
Сама по себе видимость — это еще не финишная прямая. Получив ее, вам все равно нужно оценить и классифицировать то, что вы видите. Само управление распадается на два связанных, но разных вопроса, которые предъявляют различные требования к доказательствам:
- Процесс — то, как разработчики используют ИИ при создании ПО. Какие помощники кодирования одобрены, какие данные могут передаваться в промпт, можно ли принимать сгенерированный код напрямую, какой требуется ручной контроль и как обеспечивается ответственность.
- Продукт — какой ИИ внедрен в то, что вы выпускаете. Какие LLM или провайдеры задействованы, какие данные они обрабатывают, является ли сценарий использования высокорисковым, регулируемым, ориентированным на клиента или критически важным для безопасности, и какую документацию или мониторинг это влечет за собой.
Если рассматривать это как единый неразделимый разговор об «управлении ИИ», в итоге вы получите лишь частичное покрытие для каждого из направлений.
Это различие важно потому, что обязательное соблюдение требований является текущим драйвером, а не будущим. Ландшафт нормативно-правового регулирования и стандартов в сфере ИИ расширяется, и организации, которые опередят события, — это не те, что запрещают инструменты ИИ, и не те, что пускают их на самотек. Это те, кто сможет не на словах, а с помощью доказательств точно сказать, какой именно ИИ находится в их конвейере, на что он способен и кто за него отвечает.
Хотите послушать беседу целиком? Недавно мы встретились с лидерами в области исследований безопасности, продуктов для цепочек поставок ИИ и глобального консультирования по AppSec для участия в панельной дискуссии в прямом эфире — «Shadow AI в жизненном цикле разработки ПО (SDLC)» — где обсуждались видимость, риски MCP и путь к регулируемому ИИ.
Теги:
Управление ИИ
Инвентаризация ИИ
Безопасность цепочки поставок ИИ
AI-BOM
Соответствие требованиям AppSec
Закон ЕС об искусственном интеллекте
ISO 42001
Безопасность MCP
