Безопасная установка AI-инструментов: имени мало

Знакомое название продукта не устанавливает издателя

На пакете написано Claude. Кто получит право выполнить код на вашей машине? Безопасная установка AI-инструментов начинается с выяснения этой связи до выдачи доступа к репозиторию или учётным данным. Имя в npm, убедительное описание и знакомое слово в названии не доказывают разрешения от вендора продукта.

19 октября 2026 года GitHub опубликовал malware-advisory для восьми npm-пакетов с AI-тематикой, перечисленных ниже. Это повод проверить установку, но не доказательство компрометации официальных продуктов Claude, Codex или ChatGPT. Руководство основано на advisory и официальной документации; оно не заявляет об анализе или запуске образцов вредоносного кода. [1][2][3]

Flagged package names; do not install

claude-desktop-setup       @decoopus/claude-setup
codex-setup                chatgpt-desktop-setup
@decoopus/chatgpt-setup     chatgpt-pro-activator
chatgpt-pro-setup-tool     api-anthropic

Удаление пакета из реестра не раскрывает поведение payload

Проверенные advisory классифицируют пакеты как вредоносные, но не содержат анализа поведения этой группы. По состоянию на 20 октября рассмотренные источники не устанавливают, какие файлы читались, атаковали ли конкретное хранилище ключей и какое закрепление создавалось. Назвать семейство инфостилера означало бы заполнить пробел историей вместо доказательств. Общая тематика также не доказывает одного оператора. [1][2][3]

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

Начните с вендора и проследите канал распространения

Для Claude Code Anthropic указывает официальный пакет @anthropic-ai/claude-code и предлагает собственные каналы установки. Похожее имя setup-пакета не наследует эту связь. Метод применим к любому инструменту: начинайте с документированной страницы установки вендора и следуйте точному каналу для своей платформы вместо выбора пакета в поисковой выдаче. [4]

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

Proposed approved-tool record

Vendor documentation URL -> exact distribution identity
Version + platform        -> expected artifact
Publisher / signing key   -> trust anchor
Artifact hash             -> recorded bytes
Update mechanism          -> owner and review policy
Runtime permissions       -> separately approved access

Контрольной сумме нужен доверенный эталон

Контрольная сумма доказывает совпадение байтов с ожидаемым хешем. Если недоверенный распространитель выдаёт и файл, и хеш, совпадение не устанавливает автора. Anthropic документирует подписанные release-манифесты начиная с Claude Code 2.1.89; более ранние содержат хеши без этой отделённой подписи. Сначала проверьте подпись манифеста по документированному отпечатку ключа, затем сравните бинарный файл нужной платформы с аутентифицированным манифестом. [4]

В Windows официальные native-бинарники также имеют Authenticode-подпись. Команды ниже не запускают исполняемый файл. Проверьте и действительность подписи, и ожидаемого издателя Anthropic, PBC: произвольной действительной подписи недостаточно. Это документированные шаги проверки, а не утверждение, что для статьи скачивался или проверялся бинарник. [4]

# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
  Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256

# Compare signer and hash with the vendor's documented trust chain.

Подтверждённое происхождение не определяет допустимые права

Подпись и provenance отвечают на вопросы происхождения. Они не доказывают отсутствия вредоносного поведения или уязвимостей. npm прямо поясняет это для provenance: механизм связывает пакет с исходниками и данными сборки для проверки, но не удостоверяет безвредность. Используйте результат как часть свидетельств об артефакте, а не основание выдать ему все ключи машины. [5]

Мой следующий вопрос — к чему получит доступ установленная программа. Для одобренного инструмента проверьте содержимое репозитория, переменные окружения, хранилища учётных данных и сетевой доступ процесса. Разделяйте рабочий доступ разработчика и production-ключи, дополнительные права выдавайте осознанно. Это рекомендация о полномочиях исполнения в целом, а не утверждение о конкретном способе сбора данных удалёнными пакетами.

Делает ли отключение install-скриптов CLI безопасным?

Параметр npm ignore-scripts подавляет скрипты package.json при установке, но документация указывает: явно вызванные скрипты, например npm run, продолжают выполнять запрошенную команду. Это не песочница для программы, которую вы затем запускаете. Если команда блокирует lifecycle-скрипты, а потом запускает непроверенный CLI, она принимает новое решение об исполнении. Оценивайте его отдельно. [6]

Есть и цена совместимости: нормальным пакетам могут требоваться установочные шаги. Нужен явный, проверенный допуск с объяснением, а не глобальное отключение контроля из-за одного неработающего инструмента. В записи об одобрении различайте изучение метаданных, установку и выполнение. Они дают разные доказательства и открывают разные возможности; один этап не должен незаметно подменять следующий.

Если пакет уже установлен, сохраните доказательства

Malware-advisory рекомендуют считать машину с установленным пакетом скомпрометированной и заменять раскрытые секреты с другого компьютера. Вместе с командой реагирования изолируйте среду, сохраните записи установки и процессов, установите доступные ей учётные данные. Одно удаление пакета не доказывает исчезновения созданного доступа или закрепления. [1][2]

Это намеренно не утверждение о конкретном payload. Можно серьёзно отнестись к сдерживанию и точно обозначить неизвестное. Храните в материалах инцидента идентификаторы и версии пакетов, доказательства выполнения и перечень проверенных учётных данных. Не вставляйте действующие секреты в задачу и не создавайте их замену на недоверенной рабочей станции.

Сделайте установку инженерным решением

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

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