SkillSpector от NVIDIA: просканировал 41 свой скилл ИИ-агентов — что нашлось на самом деле
Скиллы стали главным способом расширять ИИ-агентов: в Claude Code, Codex CLI и Gemini CLI это каталоги с инструкциями и скриптами, которые агент читает как свою операционную систему. Ставится такой каталог одной командой — и вместе с ним на вашу машину приезжает чужой код с доступом к файлам, репозиториям, базе клиента и API-ключам.
NVIDIA подошла к этому как к классической проблеме цепочки поставки и выложила SkillSpector — открытый сканер безопасности скиллов, который отвечает на один вопрос: «можно ли это ставить?». Я поставил его и прогнал по всем 41 своим скиллам. Рассказываю, что нашлось на самом деле — spoiler: почти всё самое громкое оказалось ложными срабатываниями, но одну реальную проблему сканер поймал.
Зачем нужен сканер скиллов
Исходная цифра из исследования NVIDIA, на которое ссылается README: из датасета в 42 447 скиллов проанализировали 31 132, и 26,1% содержат уязвимости, а 5,2% показывают вероятный вредоносный замысел. Скиллы с исполняемыми скриптами уязвимы в 2,12 раза чаще остальных.
Для бизнеса, который внедряет агентную автоматизацию, это новая поверхность атаки, о которой пока мало кто думает. Мы давно привыкли проверять пакеты в package.json на известные CVE и не запускать непонятные скрипты из интернета. Но скилл — это гибрид: наполовину документация для модели (промпт-инъекции, «отравление» памяти агента, скрытые инструкции игнорировать отказы), наполовину код (эксфильтрация данных, privilege escalation, supply chain). Обычный антивирус вторую половину увидит, первую — нет.
SkillSpector закрывает обе. Это статический анализатор с 71 паттерном в 17 категориях: инъекции в промпты, эксфильтрация данных, повышение привилегий, скрытие системного промпта, отравление памяти, чрезмерная автономность агента, «рогейн»-поведение MCP-серверов (когда сервер меняет описание инструментов после установки), YARA-сигнатуры малвари и AST-анализ опасного кода с трекингом потоков данных. Плюс онлайн-проверка зависимостей по CVE через OSV.dev.
Важно понимать границы: сканер не исполняет скилл — это defense-in-depth, а не песочница. Он не поймает поведение, которое проявляется только в рантайме, и не прочитает картинки или обфусцированный байткод. Зато он ловит то, на что человек при беглой установке не посмотрит вообще никогда.
Как выглядит проверка
Установка через uv одной командой, без загрязнения системы:
uv tool install git+https://github.com/NVIDIA/skillspector.gitПроверка чужого скилла перед установкой:
skillspector scan https://github.com/user/some-skill --no-llmСканер выдаёт риск-скор от 0 до 100 с полосами LOW / CAUTION / HIGH / CRITICAL и, главное, код возврата: 0 — ставить можно, 1 — риск выше 50, 2 — ошибка скана. Это устойчивый контракт для CI и скриптов установки: проверка скилла превращается в такой же рутиный шаг, как проверка подписи пакета. Отчёт можно вывести в JSON, Markdown или SARIF.
Флаг --no-llm держит весь анализ локально: наружу уходят только имена зависимостей для проверки CVE. Необязательный LLM-режим (семантическая оценка «что автор имел в виду») отправляет содержимое файлов настроенному провайдеру — для клиентских и вообще чувствительных проектов его просто не включаем.
Эксперимент: 41 скилл под сканером
У меня в ~/.agents/skills/ живёт 41 скилл — от SEO-инструментов до автоматизаций CRM. Часть написана руками, часть выросла из рабочих сессий. Идеальная выборка для калибровки: я точно знаю, что малвари там нет.
Результат: 11 скиллов получили максимальный скор 100/CRITICAL с вердиктом DO_NOT_INSTALL. Если бы это были чужие скиллы, я бы их не поставил. Разбираю, что именно триггерило — это и есть самое поучительное в сканере.
Скилл про безопасность матчится сам на себя. senior-security — скилл, который ищет утечки секретов. Его собственные регулярки для .env и токенов сканер справедливо распознал как «доступ к креденшелам»: 20 находок Privilege Escalation. Ложное срабатывание по определению: инструмент обнаружения содержит сигнатуры того, что обнаруживает. То же с code-reviewer, в справочнике которого лежат примеры опасного кода.
Локальный dev-инструмент читается как SSRF. Скилл impeccable с живым превью в браузере ходит fetch('http://localhost…') — 12 находок Server-Side Request Forgery. Для инструмента разработчика это нормальное поведение; тревожным оно было бы в скилле, которому localhost не нужен.
YARA-правило сработало на YAML. У md-slides сигнатура «MCP metadata poisoning» сработала на… YAML frontmatter с полями tools: и description: в обычном скилле. Классика сигнатурного анализа: комбинация безобидных признаков выглядит подозрительно.
Незакреплённая версия — замечание справедливое. senior-qa получил 20 находок «MCP server referenced without pinned version» за npx playwright без пина версии. Формально это не атака, но rug-pull-риск: что сегодня npx тянет одно, завтра — другое. Это уже гигиена, которую стоит чинить.
Что сканер поймал реального
Одна находка оказалась не ложной. Семь скиллов тащили в себе каталоги __pycache__ со скомпилированными .pyc-файлами — Python сам создаёт их при запуске скриптов, и они случайно попали в репозитории.
Это именно то, о чём предупреждает сканер: скомпилированный байткод стандартный анализ пропускает, и это классическое место для сокрытия полезной нагрузки — вредоносный .pyc рядом с чистым .py не увидит ни человек, ни часть инструментов. Убрал каталоги (пересоздадутся при следующем запуске), заодно стало чище.
Мораль эксперимента двоякая. С одной стороны — не паникуйте при виде CRITICAL: смотрите улики (файл, строка, совпавший паттерн), а не только вердикт. С другой — даже на заведомо чистых, написанных своими руками скиллах сканер нашёл то, что стоило почистить. На чужих скиллах из интернета плотность реальных проблем по данным NVIDIA — порядка процентов, и проверить дешевле, чем разбирать последствия.
Как встроить в процесс
Для себя я зафиксировал три правила, они же — ответ на вопрос «а что делать с этим всем»:
Чужие скиллы — только через сканер. Одна команда до установки, код возврата как гейт. Если скор выше 50 — читаю JSON-отчёт с уликами и решаю осознанно. Это занимает секунды.
Свои скиллы — периодический аудит. Раз в месяц прогонять весь каталог: ловится и мусор вроде __pycache__, и дрейф (скилл, в который со временем добавили curl с токеном в аргументах — реальный паттерн эксфильтрации).
Ложные срабатывания — через baseline, а не через отключение. У сканера есть механизм подавления принятых ложняков (baseline-файл). Глушить конкретные находки с комментарием «почему ок» — правильный путь; отключать сканер целиком — нет.
Если вы внедряете ИИ-агентов в бизнес-процессы — особенно с доступом к CRM, базе клиентов или серверам — приходите обсудим архитектуру с безопасностью по умолчанию: от ограниченных мандатов для агентов до проверки всей цепочки поставки. Напишите мне в Telegram.
📞 +7 (906) 311-77-69 · ✉ hello@automata.sale · 💬 Telegram: @automatasale · 🌐 automata.sale
ИП Урядов Евгений Евгеньевич · ИНН 645112058391 · ОГРНИП 312645301900058 Работаем по России, Беларуси и Казахстану
Automata может помочь:
Частые вопросы
Что такое SkillSpector?
Открытый сканер безопасности от NVIDIA (лицензия Apache 2.0), который анализирует скиллы ИИ-агентов и MCP-серверов до установки: 71 паттерн уязвимостей в 17 категориях, от инъекций в промпты до YARA-сигнатур малвари. Скилл при этом не исполняется — это статический анализ, а не песочница.
Сканер выдал CRITICAL — значит, скилл вредоносный?
Нет. В моём случае 11 из 41 скилла получили максимальный скор 100/CRITICAL, но почти все находки оказались ложными срабатываниями на легитимный функционал: скилл для поиска секретов матчится сам на себя, локальный fetch на localhost читается как SSRF. Вердикт — повод разобрать улики, а не приговор.
Уходят ли мои данные в облако при сканировании?
В режиме --no-llm нет: анализ идёт локально, наружу уходят только имена зависимостей для проверки CVE в базе OSV.dev. LLM-режим (необязательный, для семантического анализа) отправляет содержимое файлов настроенному провайдеру — для чувствительных проектов его просто не включайте.
Какие скиллы самые рискованные?
По исследованию NVIDIA, скиллы с исполняемыми скриптами уязвимы в 2,12 раза чаще остальных. Из 31 132 проанализированных скиллов 26,1% содержат уязвимости, а 5,2% показывают признаки вероятного вредоносного замысла.
Как встроить проверку в свой процесс?
Прогоняйте сканер перед каждой установкой чужого скилла и ориентируйтесь на код возврата: 0 — ставить можно, 1 — риск выше 50 из 100, 2 — ошибка скана. Это занимает секунды и превращается в обычный шаг установки, как проверка подписи пакета.
Работаю удалённо — цены и условия для вашего города: