Plugin4Shell: чем опасны плагины ИИ-агентов для бизнеса

Что случилось: плагин прошёл проверку и всё равно оказался чужим

SHA-пиннинг – способ прибить плагин к проверенному коммиту: один раз посмотрели код, записали хеш, дальше версия сама не меняется. Or Nevo, Dor Granat и Niv Hoffman показали, что агенты передают этот хеш в Git, но не сверяют, какой коммит Git в итоге отдал. Владелец репозитория публикует ветку или тег с именем, похожим на закреплённый SHA, – проверка формально проходит, а код приезжает другой (AIR Security).

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

Почему патч закрывает не всё

Если у вас Claude Code или Codex – убедитесь, что версии не ниже 2.1.179 и 0.146.0. Google решила Gemini CLI не чинить, а объявить устаревшей и увести пользователей на Antigravity. GitHub ответил, что на его платформе нельзя создавать теги и ветки, похожие на хеши коммитов, значит эксплуатация невозможна. Исследователи возражают: маркетплейсы плагинов живут далеко не на одном GitHub (Help Net Security).

Меня в этой истории смущает не отсутствие патчей, а отсутствие CVE. Без идентификатора уязвимость не приедет ни в один сканер зависимостей и ни в один отчёт вендора. Узнать о ней можно только прочитав новость – то есть случайно.

Чем это грозит компании, которая сама код не пишет

Прямо – ничем. Косвенно – ровно настолько, насколько у вас есть подрядчики и аутстафф-инженеры с доступом в ваш репозиторий. Агент запускается на машине разработчика и забирает себе всё, что там лежит: ключи к облаку, SSH, конфиги, токены CI, иногда прод через туннель. Плагин получает это следом. Новый периметр галочкой в договоре не закрывается: NDA никак не влияет на то, какие расширения стоят у инженера в ~/.config.

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

77% уверенности против 44% контроля

Harness опрашивал не абстрактные компании, а те, что уже вывели агентов минимум в живой proof of concept: от 1000 сотрудников, от 100 разработчиков. 77% уверены, что держат полную инвентаризацию агентов, MCP-серверов и моделей, активным обнаружением пользуются 44%. 41% выборки заявляют «теневого ИИ у нас нет», не имея ничего, чем это можно проверить. Там же: 76% рассчитывают отключить сбойнувшего агента за четверть часа, а мгновенный kill switch есть у 33%.

Как мы в CRT держим агентов на коротком поводке

Мы работаем в AI-first режиме, у нас есть отдельная роль AI Software Engineer, так что вопрос «что именно исполняется на машине инженера» встал раньше, чем вышло это исследование.

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

Работающий вариант оказался скучным. Список разрешённых плагинов и MCP-серверов с версиями. Автообновление выключено, обновление – осознанное действие с ревью диффа. Технические учётки и короткоживущие токены с минимальными правами вместо личных кредов инженера. Никакого прямого доступа агента в прод. В формате аутстаффинга список согласуется с клиентом и живёт в его контуре безопасности.

Что спросить у подрядчика на этой неделе

Какие агенты и версии используются на моём проекте; какие плагины и MCP-серверы установлены и кто их ревьюил; включено ли автообновление расширений; под какими учётками и ключами работает агент. Четыре вопроса на пятнадцать минут. Если в ответ звучит «у нас всё под контролем» без списка – это и есть те самые 77% против 44%.