Как проверить репозиторий GitHub перед установкой скилла или MCP

Недавно я собирал себе набор скиллов для Claude Code и поймал себя на том, что не знаю, как проверить репозиторий GitHub, который мне подсунул сам агент. Первая попытка вышла наивной, я посмотрел на число звёзд, успокоился и чуть не запустил установку из архива в релизах.

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

Почему совет агента ещё не проверка

В июле 2026 года исследователи безопасности компании Island раскрыли кампанию FakeGit. Около 7 600 вредоносных репозиториев на GitHub, примерно 6 600 фальшивых профилей и больше 14 млн скачиваний файлов из релизов. Больше 800 подделок выдавали себя за ИИ-скиллы и MCP-серверы на GitHub. По сути, ровно за то, что сейчас подключают к агентам.

Самое неприятное нашлось в тестах. Gemini и ChatGPT сами, без всякой ссылки, рекомендовали вредоносный репозиторий. Claude Code в одном из прогонов посоветовал безопасный вариант, но назвал вредоносный допустимой альтернативой и повторил его шаги установки. В других прогонах он распознал подозрительное содержимое и отказался. Island назвала этот приём AgentBaiting, по сути «приманкой для агента». Вы просите агента найти бесплатный MCP-сервер для Walmart, а он может поставить репозиторий злоумышленника первым в ответе, приняв вредоносный README за обычную документацию.

Каталог тоже не гарантия. Anthropic проверяет коннекторы своего каталога по критериям листинга, но аудит безопасности MCP-серверов не проводит. Поэтому ни рекомендация Claude, ни место в списке не заменяют вашу собственную проверку.

Где на самом деле опасность: шаг установки

Опасный код редко прячется там, куда вы смотрите. Вредит, как правило, не исходник, а команда установки, которую запускают на доверии и не открывают. Даже у легального проекта Ollama официальная установка устроена так:

curl -fsSL https://ollama.com/install.sh | sh

Скрипт скачивается из интернета и сразу выполняется в оболочке. Вы его не видите. Ollama от этого не становится вредоносом, но такую команду сначала стоит разобрать. Скачайте скрипт отдельно и прочитайте, что он делает.

Есть вариант, после которого читать уже нечего. Island советует сразу отказываться от любого скилла или MCP-сервера, который ставится через скачиваемый исполняемый файл. Подделки FakeGit вели как раз на ZIP-архивы из релизов. Если README предлагает скачать архив или exe вместо установки из исходников или через пакетный менеджер, закрывайте вкладку.

Цена ошибки высокая. Установленная программа получает к компьютеру гораздо больше доступа, чем любая подозрительная ссылка в письме. А на той же машине обычно лежат почта, пароли и вход в банк, а не только рабочие проекты.

Как проверить репозиторий GitHub: признаки подделки

FakeGit маскировалась дёшево. Имя пользователя отличалось от настоящего на один символ, а небольшое число звёзд создавало вид солидного проекта при беглом взгляде. Отсюда признаки, которые стоит проверить на странице репо. Перечислим основные.

• Имя владельца. Сверьте его посимвольно с известным оригиналом, а не на глаз, а если оригинала вы не знаете, поищите MCP-сервер в официальном MCP Registry, который при публикации проверяет право издателя на пространство имён через GitHub или домен.
• Звёзды и возраст. Смотрите, соответствует ли число звёзд возрасту репозитория. Расхождение говорит о возможной накрутке.
• Форки и участники. Оценивайте не только звёзды, но и форки и список контрибьюторов.
• Шумиха и зрелость. Громкий запуск ничего не говорит о том, насколько проект готов и кому он принадлежит.

Про последний пункт есть показательный пример. ArtCraft, набор бесплатных открытых приложений, похожих на программы Adobe, это настоящий проект, а не подделка. Через 11 дней после выхода у одного его приложения Photocraft было 44 000 звёзд на GitHub. При этом по собственной дорожной карте проекта оно покрывало примерно 25–35% того, что профессионалу нужно каждый день. Тысячи людей поставили набор, не задумавшись о проверке. Так что «много звёзд, значит, проверено» – скорее миф. Звёзды могут набираться быстрее, чем кто-то успевает посмотреть код.

Проверьте автора, а не только код

Около 6 600 фальшивых профилей составляли вторую половину FakeGit. Поэтому проверка начинается с того, кто опубликовал код. Откройте профиль, посмотрите прошлые проекты, поищите имя и контакты автора за пределами GitHub.

Такой поиск быстро показывает связи. У ArtCraft, например, проверка автора выводит на то, что разработчик Брэндон Томас раньше руководил компанией storyteller.ai, а контактная почта проекта до сих пор ведёт туда. Ничего плохого это само по себе не значит. Зато вы уже знаете, с кем имеете дело. Хорошая альтернатива отличается не громким запуском, а тем, что за ней стоит компания с историей, которую можно проверить и с которой можно спросить, если что-то пойдёт не так.

Как проверить плагин и скиллы Claude Code до установки

Плагин Claude Code может принести сразу скиллы, хуки и MCP-серверы. Что именно он добавит, видно ещё до установки. Запустите Claude Code, введите /plugin, на вкладке Discover выберите плагин и нажмите Enter. Откроется карточка плагина с блоком Will install («Будет установлено»): там перечислены команды, агенты, скиллы, хуки и MCP-серверы. Блок говорит только, что хук есть, но не что он запускает. Поэтому в той же карточке выберите View on GitHub или Open homepage, найдите папку плагина и прочитайте три места: в hooks/hooks.json команду каждого хука, в .mcp.json команду или адрес каждого сервера, в папке bin/ каждый файл. Полную опись без запуска сессии выдаёт команда, если сначала склонировать репозиторий с плагином к себе:

claude --plugin-dir <папка> plugin details <имя>

Пять вопросов перед установкой

Если репозиторий и автор не вызвали подозрений, остаётся ответить себе на пять вопросов. Они подходят для скилла, MCP-сервера и вообще любой программы.

1. Кто за этим стоит и что этот человек или команда делали раньше?
2. На что живёт проект? Если он бесплатный, на чём зарабатывает автор.
3. Откуда берётся код? Из исходников, которые можно прочитать, или из готового бинарника. Если перед вами всё же установщик, проверьте, подписан ли он известным издателем, а предупреждение системы об отсутствии подписи прочитайте, а не пролистывайте.
4. Куда уходят ваши файлы и платёжные данные?
5. Если проект завтра исчезнет, сможете ли вы забрать свою работу?

Для скиллов есть ещё один пункт. Скилл в репозитории может сам выдать себе широкий доступ к инструментам через поле allowed-tools. Поэтому прочитайте его до того, как запускать Claude Code в чужом репозитории. Кстати, если скиллам не нужно выполнять встроенные shell-команды, это можно запретить в настройках Claude Code:

"disableSkillShellExecution": true

Если хотя бы на один вопрос ответа нет, это повод остановиться. Ставя код от того, о ком вы ничего не знаете, вы не можете быть на 100% уверены в том, что внутри. Лучше подождать или поискать альтернативу.

Автоматическая оценка репо: что ловит и чего не видит

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

Из открытых инструментов есть OpenSSF Scorecard. Он автоматически оценивает репозиторий по набору эвристик безопасности и ставит балл от 0 до 10 по каждой проверке. При этом Scorecard оценивает практики проекта. Вредоносный код он не ищет.

У любой такой оценки есть слепые зоны.

• Проверка по поверхности репо не распаковывает ZIP и не разбирает бинарник внутри. А FakeGit прятала настоящую нагрузку именно там.
• Ухоженный популярный репозиторий, который стал вредоносным в одном новом релизе, ещё какое-то время получает высокую оценку. Репутация отстаёт от реальности.

Ключевые термины

• MCP-сервер – Подключаемый к ИИ-агенту сервер, который даёт ему доступ к внешним инструментам и данным и потому работает с правами на вашем компьютере или в аккаунтах.
• AgentBaiting – Приём, при котором злоумышленник готовит репозиторий так, чтобы ИИ-агент сам нашёл его и порекомендовал пользователю.
• curl | sh – Команда установки, которая скачивает скрипт из интернета и сразу выполняет его в оболочке, не давая его прочитать.
• Накрутка звёзд – Искусственное увеличение числа звёзд на GitHub, чтобы молодой репозиторий выглядел популярным и проверенным.
• Подписанный установщик – Установочный файл с цифровой подписью известного издателя, по которой система проверяет, кто его выпустил.
• Payload – Вредоносная нагрузка, которую прячут, например, в архиве или бинарнике из релиза, а не в видимом коде репозитория.

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

Сведите всё в один порядок и проходите его каждый раз, когда агент советует новый скилл или MCP-сервер.

• Не считать совет агента или место в каталоге проверкой
• Сверить имя владельца посимвольно
• Сравнить звёзды с возрастом репо, посмотреть форки и участников
• Проверить автора, то есть его профиль, прошлые проекты и связи за пределами GitHub
• Прочитать команду установки до запуска, особенно вида curl | sh
• Отказаться от установки через ZIP или exe из релизов, даже если всё остальное выглядит прилично
• Для плагина Claude Code открыть Will install и прочитать hooks, .mcp.json и bin/
• Для скилла прочитать allowed-tools и при необходимости отключить shell-команды
• Ответить на пять вопросов
• Прочитать код с реальным доступом, даже если автоматическая оценка высокая

Порядок занимает несколько минут и, скорее всего, отсечёт многие грубые подделки вроде FakeGit. Решение в нём принимаете вы, а не агент. Не ставьте следующий предложенный скилл, пока не пройдёте этот список.

Проверьте себя

1. Агент в Claude Code предложил MCP-сервер и сам нашёл его на GitHub. Что из этого следует?

• А. Ничего: агенты сами выдавали вредоносные репозитории, читая их README как документацию, поэтому проверка всё равно нужна
• Б. Можно ставить, если у репо больше 100 звёзд
• В. Репозиторий уже проверен – агент прочитал README

2. В README популярного проекта установка – одной командой curl ... | sh. Что разумно сделать?

• А. Запустить, раз проект популярный
• Б. Сначала открыть и прочитать скрипт, который скачивается, а уже потом решать
• В. Считать проект вредоносным и уйти

3. Какие признаки должны насторожить на странице репозитория? (Верных ответов несколько.)

• А. Последний коммит был вчера
• Б. У проекта есть лицензия и примеры
• В. Репо три недели, а звёзд десятки тысяч, при этом мало форков и контрибьюторов
• Г. Имя владельца отличается от известного на один символ

4. Автоматическая проверка поставила репозиторию высокую оценку. Как к ней относиться?

• А. Как повод не читать код, который получит реальный доступ
• Б. Как гарантию: можно давать доступ к ключам
• В. Как «явных красных флагов нет», а не «проверено и безопасно»

5. Бесплатный инструмент без известной компании за ним. Какой вопрос важнее всего задать до установки?

• А. Кто его автор, что делал раньше и на чём зарабатывает
• Б. Есть ли у него красивый сайт
• В. Сколько у него звёзд