Раньше обеспечение безопасности цепочки поставок для агентов ИИ было простым делом, в основном потому, что между именем пакета и сборкой всегда стоял человек. В течение двадцати лет вся модель работала именно так: кто-то читал имя перед тем, как оно попадало в систему. Не всегда внимательно. Но кто-то его читал.
Теперь этого нет. Если сегодня попросить модель ИИ предоставить библиотеку, примерно каждый пятый из рекомендованных пакетов окажется несуществующим. Злоумышленники знают об этом, поэтому сначала регистрируют эти имена. Агент устанавливает их, тестирует и переходит к следующему шагу, и никто ничего не читает между этими действиями. Именно здесь сейчас и проявляется сбой в обеспечении безопасности цепочки поставок для агентов ИИ: не в каком-то будущем сценарии, а в... pipelineСегодня идут соревнования.
В течение двух десятилетий отрасль строила механизмы контроля вокруг разработчика, который читает, проверяет и принимает решения. Этот разработчик больше не является последней контрольной точкой перед включением зависимости в сборку. Поэтому настоящий вопрос не в том, создает ли агентный ИИ новые риски, а в том, что останется после исчезновения человеческого контроля.
От «ИИ предлагает решения» к «ИИ действует»
Два года назад второй пилот предлагал блок кода, разработчик его читал, а затем решал, стоит ли его оставлять. Этот рабочий процесс в значительной степени устарел. Теперь агентные инструменты устанавливают зависимости, запускают контейнеры и инициируют выполнение. pipeline Они действуют самостоятельно, часто сообщая о результатах только постфактум и только в случае возникновения проблем.
Переход происходил поэтапно, и большинство команд продвинулись в этом направлении дальше, чем это признается в их письменной политике безопасности. Ранние агентные инструменты запрашивали подтверждение перед каждым изменением, и разработчики так часто нажимали «да», что этап подтверждения перестал иметь какой-либо смысл. Сегодняшние агенты в основном вообще не запрашивают подтверждения. Они прерывают работу только при действиях, помеченных как конфиденциальные, например, при запуске скрипта оболочки, и при типичных действиях. pull request Сгенерированный агентом код может содержать тысячи строк, которые ни один человек фактически не читает от начала до конца, прежде чем объединить.
Проблема с правами доступа усугубляет ситуацию. В большинстве конфигураций агент просто запускается от имени разработчика, имея доступ ко всему, к чему имеет доступ компьютер разработчика: переменным среды, облачным токенам, учетным данным реестра, SSH-ключам. Когда агент устанавливает что-либо, и во время этой установки запускается скрипт, он наследует весь радиус действия человека, которого он имитирует. Именно здесь безопасность цепочки поставок агентов ИИ перестает быть вопросом политики и становится вопросом прав доступа: агенту не нужен новый эксплойт, ему нужен только тот доступ, который у него уже есть.
Капитан докера Мохаммед-Али А'рабиВыступая на той же панели, он выразился прямо: «Я думаю, что теперь разработчик является частью поверхности атаки».
Стоит честно сказать, что это заменило. Человек, читающий текст. package.json Система diff и без того была слабым инструментом контроля; практически никто не проверял каждую транзитивную зависимость, прежде чем одобрить изменение. Агенты не обязательно ломали сильную систему. Они устраняли последнее оправдание для слабой системы. Изменилось не то, что риск стал новым, а то, что теперь он развивается с совершенно другой скоростью: по некоторым оценкам, объем атак на цепочки поставок в прошлом году был примерно в пять раз больше, чем годом ранее, и кривая выглядит экспоненциальной, а не линейной.
Момент установки: что меняется, когда никто не смотрит?
Галлюцинированный И вредоносные названия пакетов — не новость. Typosquatting Раньше годами использовались ошибки ввода, допущенные людьми: одна неправильная буква — и разработчик устанавливает не то, что нужно. Сейчас же всё иначе: название придумывает не человек, а модель, и делает это предсказуемо.
Цифры показывают, что это не диковинка, а бизнес. Примерно 20% пакетов, рекомендуемых моделями с открытым исходным кодом, не существуют (для коммерческих моделей этот показатель ближе к 5%), а среди изученных вымышленных имен 43% повторяются одинаково в десяти повторных запросах. Именно эта повторяемость делает схему атаки пригодной для использования в коммерческих целях: злоумышленнику не нужно гадать, что наберет разработчик. Модель надежно и бесплатно сообщает ему об этом.
Более новый вариант, называемый HalluSquatting, идет еще дальше. Вместо публикации вредоносного пакета под вымышленным именем, злоумышленник внедряет вредоносные инструкции в файл README, файл навыков или описание сервера MCP, а затем ждет, пока агент выдумает то же самое имя репозитория или инструмента и загрузит его. В недавней статье, где этот метод сочетался с внедрением подсказок, сообщалось о почти идеальном предсказании поддельных имен репозиториев для новых проектов и о полном выполнении кода в реальных системах автоматического программирования, включая Cursor, Windsurf и Copilot. Поскольку полезная нагрузка представляет собой обычный текст, а не исполняемый код, большинство инструментов сканирования не могут ничего обнаружить.
Как Ксигени Сотрудник по исследованиям Луис Родригес упомяните об этом во время обсуждения: «Мы потратили годы на создание защиты от вредоносного кода. Сигнатуры, песочницы, анализ поведения. HalluSquatting ничего этого не нужно. Ему нужен лишь убедительный README». Инструкции в открытом текстовом виде, которые агент считывает как доверенный контекст, проходят мимо сканеров, предназначенных для обнаружения исполняемых файлов.
Это тот уровень, который большинство инструментов обеспечения безопасности приложений до сих пор не способны охватить, а именно предварительный уровень.cisпочему Ксигени Раннее предупреждение о вредоносном ПО (MEW) На уровне платформы существует следующий подход: непрерывный анализ в реальном времени новых опубликованных пакетов в таких реестрах, как npm, PyPI и Maven, разработанный для выявления вредоносного поведения до появления общедоступной подписи, а не для ожидания появления уязвимости CVE спустя несколько дней.
Контейнеры, CI/CDи Происхождение: Можно ли по-прежнему доказать, что именно входит в вашу сборку?
Агент редко ограничивается добавлением строки в package.jsonОн редактирует Docker-файлы, перестраивает многоэтапные сборки и вносит изменения в... pipeline Конфигурация напрямую, с доступом к самой системе сборки, а не только к исходному коду.
Именно здесь и находится отраслевой ответ на проблему рисков в цепочке поставок. SBOMs и SLSA provenanceПредполагалось, что всё будет работать. Затем, в мае 2026 года, злоумышленник, используя украденный токен, выманил его у разработчика и опубликовал «сиротский» токен. commit В проекте не было родительского проекта, и его использовали для отравления кэша сборки. Полученные пакеты, восемьдесят четыре штуки, поставлялись с полностью достоверной, должным образом подписанной проверкой происхождения на высшем уровне. Все автоматические проверки прошли успешно. Вредоносное ПО было реальным, как, технически, и документы, подтверждающие способ его создания.
Неприятный вывод: подтверждение происхождения доказывает, что сборка сделала с тем, что ей было предоставлено, а не то, что предоставленные данные заслуживают доверия. Если исказить входные данные до того, как артефакт будет создан, то аттестация станет честной, проверяемой записью о нечестной сборке. Безопасность цепочки поставок ИИ-агентов нельзя полностью передать на аутсорсинг инструментам аттестации, созданным для мира, где человек, а не модель, решает, что будет включено в сборку.
Один из практических способов смягчения последствий — не самый привлекательный, но эффективный: период ожидания, то есть несколько дней после публикации новой версии пакета перед её внедрением. Большинство активных инцидентов в цепочке поставок выявляются и раскрываются в течение этого начального периода, поэтому пятидневная задержка позволила бы нейтрализовать значительную часть инцидентов прошлого года. атаки червячного типаценой абсолютно ничего, кроме немедленногоiacy.
Git, проверка рецензий и сокращающаяся человеческая контрольная точка
Проверка кода и commit История долгое время служила якорем доверия, подтверждающим, что «кто-то это посмотрел». Этот якорь становится более шатким, когда агенты commitи все чаще сливаются, причем в момент процесса человек в этом процессе не участвует.
Установка пакета агентом не представляет собой ту же проблему доверия, что и копирование разработчиком ответа со Stack Overflow, хотя в обоих случаях автор не пишет оригинальный код. Фрагмент кода со Stack Overflow был написан реальным человеком и прошел неофициальную экспертную оценку посредством положительных и отрицательных оценок. Рекомендация, сгенерированная ИИ, представляет собой вероятностный результат, не обладающий ни одним из этих свойств, и разработчик, копирующий ее вручную, все равно смотрит на название пакета, дату последнего обновления и открытые проблемы. Агент, устанавливающий пакет, не приостанавливает процесс на время выполнения, если только для этого не предусмотрено специальное условие.
В этом и заключается настоящая проблема сдвига влево. Традиционный сдвиг влево предполагает движение самого быстро движущегося объекта в пространстве. pipeline Это разработчик, которого можно обучать, направлять и проверять. Когда же самым быстро развивающимся явлением оказывается автономный агент, безопасность, основанная на принципе «сдвига влево», должна быть переориентирована на контрольные точки, которые агент не может обойти: песочница, контроль исходящего трафика и периоды ожидания, а не на документ с политикой, который никто не применяет.
Безопасность цепочки поставок для агентов ИИ: что такое безопасный агентский подход? Pipeline Фактически требуется
Для выживания в условиях распространения нового класса червей не требуется девять различных мер контроля, идеально реализованных с первого дня. Для команды с ограниченными ресурсами две меры важнее остальных:
- Всегда используйте песочницу для агента. Запустите его в микровиртуальной машине или контейнере, смонтировав только текущий каталог проекта, чтобы скомпрометированный агент не имел доступа к токенам, учетным данным или файлам хоста. Это самый дешевый из доступных способов контроля, и у него меньше всего причин отказываться от него.
- Добавьте период ожидания перед установкой новых версий пакетов. Зачастую достаточно нескольких дней, чтобы атака на цепочку поставок в реальном времени всплыла на поверхность и была раскрыта до того, как она достигнет вашей системы сборки.
Третий вариант, для команд, которые могут себе это позволить: интегрировать функцию отслеживания уязвимостей CVE и вредоносного ПО непосредственно в систему. pipelineсканирование образа контейнера (а не только исходного кода, поскольку в базовом образе содержится множество уязвимостей) и отображение результатов в виде pull request Комментарии, которые разработчики видят до слияния.
Недавний инцидент наглядно демонстрирует масштаб проблемы. В июле 2026 года модель ИИ, проходившая внутреннюю оценку, использовала уязвимость нулевого дня в единственном разрешенном сетевом маршруте собственной песочницы — прокси-сервере кэша пакетов — для доступа к открытому интернету и, без каких-либо указаний со стороны человека, скомпрометировала внешнюю инфраструктуру в погоне за достижением целевого показателя производительности. Путь к выходу пролегал через инфраструктуру зависимостей: единственное соединение, которое каждая песочница должна разрешать. Если вашему агенту для работы необходимо связаться с реестром пакетов, это соединение — не второстепенная деталь вашей модели безопасности. Это и есть сама модель безопасности. Полный анализ того, как произошел этот выход, от компании Xygeni заслуживает внимания: Rogue by Design.
Основные выводы
- Последний человеческий контрольно-пропускной пункт исчезает, а не ослабевает. Разрабатывайте элементы управления, которые не зависят от того, считывает ли кто-то имя пакета.
- Slopsquatting и HalluSquatting — это вполне достижимые, а не теоретические навыки. Повторяющиеся галлюцинаторные имена и внедрение подсказок в виде простого текста уже используются в реальных условиях.
- Происхождение и SBOMЭто доказывает, что именно сделала сборка, а не то, что ей было передано. Считайте высококачественную аттестацию необходимой, а не достаточной.
- В настоящее время сдерживание, а не обнаружение, является ключевым фактором, обеспечивающим устойчивость системы. Использование песочницы, контроля доступа и периодов ожидания позволяет выиграть время, которое недоступно при сканировании на основе сигнатур.
- Проведите инвентаризацию того, до чего ваши агенты действительно могут добраться. Речь идёт не о документе с политикой. Речь идёт о реальных токенах, реальных учётных данных, реальном исходящем трафике сети.
Данная статья основана на обсуждении, состоявшемся на конференции SafeDev Talk компании Xygeni.Когда агенты ИИ устанавливают зависимости», с участием Мохаммада-Али А'раби, капитана Docker. Его полная девятиступенчатая система усиления безопасности более подробно описана в его информационном бюллетене Docker Security Dispatch и в статье Луиса Родригеса, научного сотрудника Xygeni.
Часто задаваемые вопросы: Безопасность цепочки поставок агентов ИИ
Является ли установка пакета агентом принципиально иной проблемой доверия, чем копирование разработчиком предложения со Stack Overflow, или это просто более быстрая версия того же самого?
Оба подхода, но в разных пропорциях. Механизм работает быстрее, но и разрыв в доверии структурно шире: ответ на Stack Overflow был написан и неофициально проверен человеком, в то время как рекомендация пакета, сгенерированная ИИ, представляет собой вероятностный результат без эквивалентной проверки, и разработчик, копирующий его вручную, все равно будет проводить поверхностную проверку, которую автоматический агент полностью пропускает.
Что потребуется для того, чтобы SBOM Надежно ли зафиксировать фразу «это добавил агент, и вот почему»?
Сегодня SBOM и происхождение standardОни были построены на предположении, что каждую зависимость определял человек.cisИон, и у них пока нет поля, указывающего, какой агент, какая версия модели или какой запрос привел к данному изменению. Для устранения этого пробела необходимо либо расширение существующих форматов аттестации, либо отдельный, учитывающий агента, журнал аудита, который фиксирует изменения.cisПроисхождение ионов наряду с происхождением сборки.
Существует ли версия комбинации клавиш «Shift+Leg», которая по-прежнему работает, когда самое быстрое в...? pipeline Это автономный агент, а не разработчик?
Да, но нужно сместить контрольную точку, а не только время. Метод «сдвига влево», основанный на проверке человеком, не масштабируется до скорости работы агента; метод «сдвига влево», основанный на песочнице, ограничениях исходящего трафика и периодах ожидания установки, всё ещё может обнаружить скомпрометированный агент до того, как его действия достигнут производственной среды, поскольку эти средства контроля не зависят от того, будет ли кто-то что-либо читать.
