
В прошлой статье говорили про использования LLM хакерами, и обещал как раз продолжение, как защищить свое рабочее пространство, ну в общем, к делу :)
Когда последний раз вы проверяли библиотеку на уязвимости? Или софт, что вы ставите и используете - проверяли? Ну, вот и я также - почти что никогда (раньше)
Суть вот в чем, мы в одной из прошлых статей то и обсуждали, что разработка своих скиллов - это естественная история, но и использование oss скилов - аналогично, особенно когда эти скиллы не просто MD файл, а полноценный инструмент взаимодействия
Но, проблема в том, что скилл это не конфиг и не просто “промпт” в SKILL.md - это буквально может быть и исполняемым кодом и самое важное - с твоими правами :)
Меня зовут Эдгар Сипки. Я инженер и более 10 лет работаю с backend-системами, AI / LLM-инструментами. Выступаю на AI Conf, TeamLead Conf, HighLoad, отбираю доклады на Golang Conf в программном комитете. А в своём тг-канале делюсь прикладными AI-инструментами и подходами для разработки - подписывайтесь :)
Но, зачем мне боятся то скиллов?
Есть исследование на 42 447 скиллов с маркетплейсов, и в итоге 26.1% содержат уязвимости, 5.2% - скорее всего вредоносные . Но и это еще не все, каждый четвёртый - с дырой, f каждый двадцатый - закладка, к примеру промпт-инъекции, сбор env-переменных с твоими ключами, отправка контекста наружу, в общем полный набор
А, кстати, еще :)
Скиллы с исполняемыми скриптами уязвимы в 2.12 раза чаще, лежит в скилле .py или .sh - проверять обязательно стоит
Но, как говорится
NVIDIA выкатили SkillSpector - сканер скиллов ДО установки, а ставится одной строкой:
И дальше просто:
Что умеет:
на вход - git-URL, zip, директория или одиночный SKILL.md ;
на вход - git-URL, zip, директория или одиночный SKILL.md ;
64+ паттерна в 16+ категориях (в новых релизах уже 68/17): инъекции, эксфильтрация, тайпсквоттинг, MCP tool poisoning и пр.;
64+ паттерна в 16+ категориях (в новых релизах уже 68/17): инъекции, эксфильтрация, тайпсквоттинг, MCP tool poisoning и пр.;
два этапа: быстрая статика (regex/AST/YARA/ OSV.dev ), а поверх - опциональный LLM-анализ для оценки намерения;
два этапа: быстрая статика (regex/AST/YARA/ OSV.dev ), а поверх - опциональный LLM-анализ для оценки намерения;
на выходе - risk_score 0-100, вердикт SAFE / CAUTION / DO_NOT_INSTALL и отчёт в terminal / json / markdown / sarif .
на выходе - risk_score 0-100, вердикт SAFE / CAUTION / DO_NOT_INSTALL и отчёт в terminal / json / markdown / sarif .
А сам-то сканер не словит инъекцию?
И вот тут у меня прокрались сомнения как раз таки, ведь в чем суть, сам сканер работает не просто проверяя по ключевым словам (но да, это конечно тоже) но и проверяет же также через llm, то первое о чем я задумался: если внутри скилла лежит злая инструкция, а SkillSpector скармливает его LLM - не уговорит ли скилл сканер сказать "всё чисто"? Короткий ответ - “нет”, и вот почему
Статика идёт первой и она детерминированная. Regex/AST/YARA/проверка зависимостей не "читают" инструкции - они матчат паттерны. Уговорить regex невозможно.
Статика идёт первой и она детерминированная. Regex/AST/YARA/проверка зависимостей не "читают" инструкции - они матчат паттерны. Уговорить regex невозможно.
LLM здесь - классификатор, а не агент. У него нет инструментов, файловой системы и сети. Его единственный выход - структурный вердикт (JSON), он физически ничего не может "сделать" по просьбе скилла.
LLM здесь - классификатор, а не агент. У него нет инструментов, файловой системы и сети. Его единственный выход - структурный вердикт (JSON), он физически ничего не может "сделать" по просьбе скилла.
В промпте анти-джейлбрейк. Стадия намеренно защищена от "проигнорируй прошлые инструкции".
В промпте анти-джейлбрейк. Стадия намеренно защищена от "проигнорируй прошлые инструкции".
Сама попытка инъекции - это улика. Текст вида "ignore previous instructions" триггерит паттерны Instruction Override / Hidden Instructions. То есть инъекция не прячется от сканера, а наоборот подсвечивает скилл.
Сама попытка инъекции - это улика. Текст вида "ignore previous instructions" триггерит паттерны Instruction Override / Hidden Instructions. То есть инъекция не прячется от сканера, а наоборот подсвечивает скилл.
SkillSpector обрабатывает содержимое скилла как данные для анализа, а не как команды к исполнению. Ровно этого не хватает уязвимым агентам - они принимают чужой текст за свои инструкции :)
P.S. Да, поэтому явно точно не стоит проверять скиллы своим же кодинг агентом
Короче говоря: сканер сдвигает шансы в твою пользу, но думать всё равно тебе :)
Главная боль из исследования - не "нет инструмента", а "я забываю им пользоваться". Поэтому делаем так, чтобы проверка происходила сама, я рекомендую создать алиас который резолвит репо, прогоняет SkillSpector и ставит скилл, только если он прошёл:
Теперь вместо npx skills add owner/repo ты пишешь safeskill owner/repo - и в итоге тебе явно тяжелее продолбаться с этой историей
А если скан ругается, но ты всё равно хочешь поставить - алиас спросит подтверждение [y/N], так что финальное решение остаётся за тобой.
Алиас - это для рук. Но в эпоху antigravity, cursor agent mode, vs code agent и так далее, где ты уже даже прямого доступа к терминалу не имеешь - я сделал скилл , который заставит агента сам проверять новый скилл перед установкой :)
Короче, скиллы - это суперсила, и отказываться от них глупо. А самая важная мысль, ребята, " разделяте данные и инструкции" ведь ровно это нехватает нам.
И самое важное, не забываете что скиллы и агенты часто работают имея полностью вшаи же права, так что не забывайте проверять.
Пусть агент остаётся 🐢, который думает, а не ⚡, который слепо исполняет :)