Цепочка поставок скиллов

Цепочка поставок и вредоносные скиллы

Скилл — это текстовый файл, который ты скачиваешь у незнакомого человека и кладёшь в проект, чтобы агент с доступом к твоему коду, твоему окружению и твоим ключам прочитал его и сделал то, что там написано. Сформулированное так, оно звучит достаточно тревожно и без исследований. Исследования тоже есть.

Что нашли

Со сцены: 76 вредоносных скиллов

• Кто и где: Кшиштоф Хушча (Krzysztof Huszcza, Chris), product leader AI security, Snyk — бонусный эпизод подкаста AI Native Dev «76 Malicious AI Skills Were Hiding in Plain Sight», в разговоре с Саймоном Мейплом (Tessl)
• Что показали: на волне взрывного роста OpenClaw сообщество массово заливало скиллы в каталог ClawHub. Snyk проанализировал этот корпус целиком — примерно в марте — и разделил находки на два класса: скиллы с чисто вредоносным кодом и скиллы с prompt injection в текстовой части.
• Цифры: около 76 скиллов с малварью (спикер оговаривается: «I don't remember the exact number»); отдельно на DevCon звучала оценка, что до 20% всех скиллов на OpenClaw — вредоносные.
• Что это меняет: атаки на кодинг-агентов перестали быть теоретическим упражнением. Это цепочка поставок в чистом виде, просто в новой упаковке — и с двумя векторами вместо одного.

Формулировка Хушчи про первый класс находок: «We found... 76 skills that had purely malicious code. So, malware.»

Вектор первый: в скилле бывает не только markdown

Скилл — это MD-файл с инструкцией и, часто, код рядом. Ставя чужой скилл, ты кладёшь себе на машину исполняемый код, который агент возьмёт и выполнит. Ничего экзотического здесь нет — это классическая атака на цепочку поставок, знакомая по npm и PyPI.

Экзотика в другом. Традиционные сканеры этот вектор ловят плохо, и по структурной причине: код внутри скилла может вообще не исполняться сам по себе. Он может лишь влиять на то, что сгенерирует агент. Сканер, обученный искать вредоносное поведение исполняемого артефакта, смотрит на файл, не находит вредоносного поведения — и пропускает.

Вектор второй: prompt injection в естественном языке

Вторая половина находок Snyk — инъекции в текстовой части скилла. Здесь традиционные сканеры бесполезны уже не частично, а полностью: вредоносная нагрузка написана человеческим языком и не является кодом ни в каком смысле. Сканировать нечего.

Механика, которую описывает Хушча: «Agents are not very good at distinguishing between your instruction and context that is passed through third parties.» Агент плохо отличает инструкцию пользователя от контента, пришедшего от третьих лиц. Захваченный агент дальше выкачивает секреты из окружения, в котором он запущен, — а запущен он обычно там, где эти секреты есть.

Чтобы ловить такое, нужен отдельный классификатор, оценивающий, содержит ли естественный язык попытку перехватить агента. Snyk такой построил — и это ровно тот класс инструмента, которого раньше в цепочке поставок просто не существовало, потому что раньше в зависимостях не было текста, обращённого к исполнителю.

Сканировать нужно в реестре, а не после скачивания

Это главная архитектурная позиция эпизода, и она короткая: скан должен стоять на стороне реестра, до того как артефакт оказался на машине. Скан, который стоит после скачивания, — по формулировке Хушчи, «might actually be game over».

Логика прямая. Если скилл уже лежит на диске, а агент в этой сессии уже читал файлы проекта, вопрос «а не выполнил ли он что-нибудь по дороге» становится вопросом расследования, а не проверки. Гейт, стоящий после установки, защищает от повторного использования, но не от первого.

Отсюда следует и роль реестра: он работает как точка контроля. Джеймс Мосс (Tessl) перечисляет, какие политики на него естественно ложатся:

• only approved skills — все собственные скиллы и узкий белый список сторонних;
• обязательный порог скана безопасности (у Tessl — через партнёрство со Snyk);
• minimum release age — запрет ставить пакеты моложе N дней.

Сканы привязываются к версиям

Отдельный класс риска, который проговаривают Мейпл и Хушча: разработчик поставил безопасный скилл, а потом подтянул апдейт. Если версионирования нет, при обновлении ты тащишь неизвестно что — и проверка, сделанная неделю назад, относится к другому артефакту.

Поэтому в реестр добавили версионирование скиллов, а скан Snyk привязывается к конкретной версии. Semver, о котором шла речь в предыдущей статье, становится здесь ещё и единицей аудита: у версии есть результат скана, у «последнего main» — нет.

Почему minimum release age — не бюрократия

Со сцены: npm-инцидент, который прошёл мимо

• Кто и где: Джеймс Мосс, Tessl — «Using skills to pay the bills», AI Native DevCon 2026
• Что показали: за три-четыре недели до доклада произошёл инцидент в цепочке поставок npm, который в кулуарах называли «mini Shai-Hulud». Он затронул зависимости самой Tessl. Отличительная черта той малвари — персистентность: она прописывала на машину глобальный хук Claude Code, чтобы переустанавливаться после чистки.
• Цифры: в пакетном менеджере Tessl стоял minimum release age «несколько дней»; за это время инцидент нашли и почистили.
• Что это меняет: Tessl не пострадали, не сделав ничего специального. Политика «не ставим ничего моложе N дней» — самая дешёвая защита из существующих: она не требует ни анализа, ни экспертизы, ни доверия к сканеру.

Побочный урок из того же инцидента — аргумент против любого глобального состояния для скиллов и хуков. Малварь зацепилась именно за глобальный хук: то, что стоит на машине один раз и действует везде, — идеальная точка закрепления.

Внутренний реестр: вектор другой, ущерб тот же

Легко решить, что вся эта история — про публичные каталоги и незнакомых авторов. Хушча приводит внутренний случай самого Snyk, который эту иллюзию снимает.

Разработчик написал скилл, который раздавал агентам доступ к продакшен-секретам мимо согласованного пути (paved path), без выдачи секретов на время задачи (just-in-time), с избыточными правами. Скилл работал, был удобен, им пользовались. «When our security team saw that developers are using a skill like that, they freaked out.»

Никакого злого умысла здесь нет, и в этом суть. У внутреннего реестра вектор угрозы принципиально другой: не злоумышленник снаружи, а свои разработчики, не до конца понимающие, чему они открывают доступ агенту. Скилл — очень удобный способ по неосторожности раздать права: он выглядит как документация, а действует как конфигурация доступа.

Смежное архитектурное соображение звучало в эпизоде «Inside Anthropic» от инженера applied AI team: в их системе агент получает собственные ключи и права, а не работает под правами вызвавшего его человека, и права ограничены по каналам — у каждого канала свой набор инструментов, ключей и доступов. Помимо прочего это делает аудит осмысленным: в логе видно «это сделал агент», а не «это сделал ты». Применительно к скиллам это ставит вопрос, который стоит задать про каждый свой скилл: под чьими правами исполняется то, что скилл велит агенту сделать?

Сканер как обратная связь, а не только как гейт

Интереснее всего у Хушчи не гейт, а петля. Его личная практика: pre-commit hook со сканером перед пушем собственного скилла в GitHub. Скилл выкачивал данные из Slack — сканер предупредил, что в этих данных возможен prompt injection. Автор не стал спорить с гейтом: он попросил агента добавить базовые защиты прямо в скилл.

Петля, в которой сканер даёт фидбек, а агент правит скилл, полезнее блокировки: блокировка сообщает «нельзя», а фидбек сообщает «вот что именно ты сделал». Хушча честно отмечает ограничение: проверки для «моего скилла» и для «скачанного скилла» — это разные наборы, и вторые уже сделаны, а первые ещё нет.

Куда эти проверки движутся, он тоже называет:

• не создаёт ли скилл конфигурацию lethal trifecta — агент может подвергнуться инъекции и при этом имеет канал эксфильтрации;
• не заставляет ли скилл передавать секреты в plaintext;
• не может ли он выполнить деструктивное действие в проде.

Ценность этой петли в том, что автор заранее видит последствия написанного, ещё до того, как скилл увидят другие.

Что вокруг этого строится

Хушча описывает три продуктовых направления (продукт Evo), и они хорошо очерчивают периметр задачи:

1. Управление цепочкой поставок — видеть, какие скиллы и MCP-серверы реально используют разработчики на всех машинах, оценивать риск и накладывать политики. Пример политики: MCP-сервер не должен ходить под personal access token.
2. Безопасность того, что агент генерирует, — код и подтягиваемые им зависимости.
3. Контроль поведения агента во время выполнения — утечки секретов, prompt injection на лету. На момент записи это направление выходило в открытую бету (open preview), общедоступный релиз планировался позже. По словам Хушчи, для команд безопасности оно самое горячее.

Ещё одно наблюдение оттуда же, снимающее иллюзию выбора: разница между агентами с точки зрения безопасности минимальна. Codex, Claude Code, Cursor по вектору риска почти одинаковы, главное различие — поддерживает ли агент хуки. Практический вывод: инструменты защиты должны подходить к разным агентам, а скиллы лучше держать на уровне проекта (project-level): они ставятся один раз в проект, и агентские директории ссылаются на общую папку.

Что это значит для команды

Свести всё можно к одному правилу: скилл надо ревьюить как зависимость, а не как документ.

Из него следует набор рабочих требований:

Вопрос	Как проверяется
Откуда взялся скилл	Реестр с политикой approved skills, а не ссылка из чата
Проверен ли он	Скан на стороне реестра, привязанный к конкретной версии
Что изменилось при обновлении	Пиннинг версий и дифф перед апдейтом
Что он исполняет	Ревью кода и скриптов рядом со SKILL.md
Что он читает и куда отправляет	Проверка на lethal trifecta и обращение с секретами
Под какими правами	Явные права агента, just-in-time секреты, никаких продакшен-секретов в скилле
Как быстро мы ставим новое	Minimum release age в несколько дней

Итоговая рекомендация Хушчи звучит скучно ровно настолько, насколько скучно звучат все работающие рекомендации по безопасности: не включать полное автоподтверждение на всё подряд, не ставить скиллы без причины, использовать sandbox, брать скиллы из доверенных реестров и проверять их. Его же формулировка про главное: «Don't outsource thinking to your agent. Just think for yourself what you're doing.»

И честная оговорка, без которой совет был бы неполным: полноценно изолировать агента в sandbox сегодня всё ещё непросто — инструментов не хватает. Sandbox при этом нужен, но полагаться только на него нельзя.

Коротко

• Snyk нашёл в публичном каталоге около 76 скиллов с малварью, а оценка доли вредоносных на OpenClaw доходила до 20%. Спикер сам оговаривается, что точное число помнит приблизительно.
• Векторов два: исполняемый код внутри скилла (традиционные сканеры ловят его плохо, потому что код может лишь влиять на генерацию) и prompt injection в тексте (сканеры не видят его в принципе — нужен отдельный классификатор).
• Сканировать надо в реестре, до попадания артефакта на машину: «download and scan after — might actually be game over», и сканы должны быть привязаны к версиям.
• Minimum release age в несколько дней спас Tessl во время npm-инцидента с персистентным глобальным хуком — самая дешёвая из работающих защит.
• Внутренний реестр опасен по-другому: угроза — не злоумышленник снаружи, а свой разработчик, раздавший агентам продакшен-секреты мимо согласованного пути.
• Практический вывод один: скилл — это зависимость, и ревьюить его надо как зависимость, включая вопрос о том, под чьими правами исполняется написанное в нём.