Примерно за 20 месяцев после запуска Model Context Protocol ИИ успел стать не игрушкой для демо, а частью реальной разработки: агенты пишут код, сами подтягивают пакеты и ходят по инструментам без лишних вопросов. На этом фоне цепочка поставок кода резко усложнилась: теперь риск сидит не только в зависимостях, но и в моделях, промптах и MCP-инструментах, которые участвуют в сборке.
Об этом пишет The Hacker News, разбирая, как меняется логика software supply chain security, когда код в пайплайн приносит не только человек, но и ИИ. Если раньше главный вопрос звучал довольно приземленно — какие библиотеки, версии и транзитивные зависимости попали в проект, — то теперь к нему добавился другой: кто именно принял решение что-то сгенерировать, скачать, запустить или встроить. Для российских команд, которые активно экспериментируют с AI-ассистентами в разработке, история неприятно практическая: старые сканеры видят артефакт на выходе, но плохо понимают, как он вообще появился.
Контекст понятен любому, кто пережил SolarWinds, Log4Shell или историю с XZ Utils. Все три кейса в разное время показали одну и ту же неприятную вещь: атака на разработку давно идет не только через строку кода, написанную инженером, а через все, что помогает этой строке появиться в проде. В материале The Hacker News к этому ряду добавляют кампанию Shai-Hulud — самораспространяющуюся волну вредоносных пакетов, которая в 2026 году прошлась по toolchain разработчиков. Вывод из этой истории жесткий, но логичный: знать, что лежит в репозитории, по-прежнему необходимо, но уже недостаточно. Цепочка поставок кода теперь включает еще и тех, кто подсказывает, какой код писать и какие зависимости тащить.
Здесь и происходит главный сдвиг, который многие команды пока недооценивают. ИИ-сгенерированный код легко принять за еще один источник технического долга и прогнать через привычный набор SAST, SCA и policy-checks. Проблема в том, что это лечит симптомы, а не источник риска. Если ассистент предложил пакет, разработчик его быстро одобрил, а потом этот пакет оказался лишним, уязвимым или откровенно вредоносным, формально сканер может заметить это слишком поздно. Еще хуже, когда автономный агент сам вызывает инструмент по MCP, тот тянет следующий, а решение о доверии вообще не проходит через человеческую голову. Отдельная категория риска — промпты как вход в пайплайн. Если атакующий подсовывает модели инструкцию в репозитории, документации или другом источнике, который агент читает, он уже влияет не на человека, а напрямую на процесс сборки.
По сути, вопрос происхождения никуда не делся, просто расширился. Раньше безопасники спрашивали: откуда эта библиотека и можно ли ей доверять. Теперь тот же вопрос приходится задавать модели, агенту, MCP-серверу и конфигурации, через которую они работают. Для зрелой программы безопасности этого мало назвать новым классом рисков и разослать еще один PDF с рекомендациями. Нужно тянуть lineage не только до бинарника или контейнера, но и до самого пайплайна: какие модели использовались, какие инструменты они вызывали, какие настройки менялись от коммита до рантайма. Это звучит как бюрократия, пока не вспоминаешь, что агент способен сгенерировать тысячу строк правдоподобного кода до обеда, а потом так же бодро встроить в проект пару сомнительных решений, которые никто не выбирал осознанно.
Вторая проблема не в том, что находок станет больше, а в том, что их и без того слишком много. Авторы материала прямо говорят: команды тонут в alerts, и идея «давайте еще сканировать вывод ИИ» делает очередь длиннее, но не делает защиту умнее. Здесь на первый план выходит приоритизация по реальной эксплуатируемости, а не по количеству сработок. Иными словами, мало собрать каталог уязвимостей; нужно понимать, что из этого вообще достижимо в рантайме, что реально связано в рабочую цепочку атаки и что агент может протащить в прод незаметно. Для разработчиков и платформенных команд это неприятная, но полезная мысль: безопасность придется строить не вокруг красивого отчета с сотнями findings, а вокруг доказуемого понимания того, какие из них действительно опасны для конкретной системы.
Рынок, похоже, тоже перестал делать вид, что тема нишевая. В июне 2026 года Gartner выпустила первый Magic Quadrant по Software Supply Chain Security. Сам по себе квадрант не решает проблем и не чинит пайплайны, но сигнал дает четкий: категория, которую многие компании годами закрывали кусками из DevSecOps, AppSec и compliance, доросла до отдельного рынка с бюджетом и сравнением поставщиков. Это важно и для бизнеса, и для ИТ-руководителей. Как только у темы появляется собственная строка расходов, разговор быстро перестает быть академическим. Вопрос уже не в том, использовать ли ИИ в разработке, а в том, кто отвечает за контроль его действий, журналирование решений и границы доверия.
Для русскоязычной ИТ-аудитории из этого следует довольно прозаичный вывод. Если в компании AI-ассистенты уже пишут тесты, генерируют CRUD, предлагают зависимости, формируют IaC или дергают внешние инструменты, значит, цепочка поставок кода у вас уже изменилась, даже если внутренние политики еще живут в эпохе «проверим SBOM и успокоимся». Следующий этап зрелости — не запретить ИИ и не обложить его формальными согласованиями, а научиться видеть его как полноценный элемент сборочного контура: с происхождением, правами, журналами действий и ограничениями по доступу. И главный вопрос ближайшего года будет звучать уже не «может ли ИИ писать код», а «кто и чем будет доказывать, что этому коду, инструментам и решениям вообще можно доверять».