Как работают плагины dsh и проверка их безопасности

Что такое плагин dsh и на что он способен?

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

dsh (DeepSeek Harness) — это агентская среда с открытым исходным кодом от DeepSeek AI, построенная на базе фреймворка плагинов под названием Cordis. В README проекта указано, что всё в нем является плагином. Адаптер модели — это плагин. Веб-интерфейс, в котором вы вводите команды, — это плагин. Всё, что вы устанавливаете извне, попадает в ту же структуру и обладает тем же уровнем доверия, что и компоненты, поставляемые с проектом. Если вы еще не развернули систему, начните с установки DeepSeek Harness на VPS и вернитесь сюда, прежде чем добавлять что-либо еще.

Точки расширения, к которым может обратиться плагин, перечислены в AGENTS.md репозитория. По состоянию на август 2026 года они включают:

• LLM (большая языковая модель): провайдер, оплачиваемый через ваш API key
• Shell: возможности bash, включая провайдеры local и pwsh
• Filesystem: доступ к файлам, контролируемый политиками
• Web: провайдеры для поиска и получения данных
• Subprocess: провайдер для работы с деревом процессов
• Workflow: рабочие потоки
• Subagent: делегирование задач другим агентам
• Settings and credentials: ваши сохраненные настройки и переменные окружения

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

Как dsh находит и загружает плагины?

Глобального каталога плагинов не существует. Запущенный dsh представляет собой дерево плагинов, которое формируется при загрузке из упорядоченных уровней, а единицей хранения ваших настроек является профиль. $DSH_HOME по умолчанию использует ~/.dsh, и каждый профиль находится в $DSH_HOME/profiles/<name>. Профили web и headless создаются автоматически при первом использовании на основе поставляемых шаблонов.

Каталог профиля содержит два файла, которые определяют всё:

• package.json, содержащий внешние зависимости плагинов, а также манифест dsh.profile с упорядоченным списком bundles
• cordis.patch.yml, ваш собственный уровень исправлений (patch layer) поверх этих пакетов

ls ~/.dsh
ls ~/.dsh/profiles/web

При загрузке уровни применяются в следующем порядке, при этом последующие уровни имеют приоритет:

1. пустой корень
2. пакеты профиля в порядке, указанном в манифесте
3. cordis.patch.yml профиля
4. $DSH_HOME/cordis.patch.yml
5. любые наложения --patch <path>, переданные через командную строку

Два флага позволяют вывести результат этой композиции без запуска каких-либо процессов:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config выводит составленное дерево в чистом виде. --dump-config добавляет уровни профиля и пользовательских исправлений, поэтому это наиболее точный способ получить инвентаризацию того, что будет загружено при следующей загрузке. Проверяйте этот список, прежде чем доверять машине, которая досталась вам от другого администратора.

Одно предостережение касательно этих файлов исправлений. Конфигурация здесь не является инертными данными, так как формат позволяет использовать значения с тегом !!js внутри блока config плагина. Фрагмент cordis.patch.yml, скопированный с форума, является кодом, поэтому относитесь к нему так же, как к shell-скрипту из того же источника.

Что именно запускает dsh plugin add?

dsh plugin --profile <name> <args> передает свои аргументы pnpm внутри директории этого профиля, поэтому pnpm должен находиться в PATH. Используются команды pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

Таким образом, модель безопасности при установке плагина dsh совпадает с моделью безопасности при установке любой зависимости в стиле npm, с добавлением одного шага, на котором результат загружается в ваш агент. Пакет содержит собственное дерево зависимостей, и каждый пакет в этом дереве оказывается в одном и том же процессе. Всё, описанное в как атаки на цепочку поставок npm достигают сервера, применимо здесь без изменений.

pnpm версии 10 и выше по умолчанию не запускает скрипты сборки зависимостей, а одобрение выполняется для каждого пакета через onlyBuiltDependencies или pnpm approve-builds. Проверьте версию вашего pnpm:

pnpm --version

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

Что нужно прочитать перед установкой плагина dsh

Скачайте опубликованный tarball и изучите его содержимое. Распаковка архива не запускает выполнение кода.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

Четыре поля в package.json содержат основную информацию, необходимую для анализа. Проверьте scripts на наличие записей preinstall, install и postinstall. Изучите dependencies на предмет незнакомых имен или имен, отличающихся от известных вам лишь одним символом. Проверьте bin, чтобы узнать, какие пути пакет пытается добавить в ваш PATH. Изучите main или exports, чтобы найти точку входа, затем откройте этот файл и проанализируйте его логику.

После этого изучите код, который будет загружен. У плагина, заявленного как инструмент уведомлений, нет причин читать ~/.ssh, обращаться к неизвестному хосту или запускать shell. Если пакет поставляется только в виде упакованного или минифицированного JavaScript, а исходный код отсутствует в публичном репозитории — это повод для отказа от установки. Отдавайте предпочтение плагинам с доступным для чтения исходным кодом и выбирайте решения меньшего объема.

Вы также можете получить информацию из реестра, не устанавливая пакет:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

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

Фиксация версии и сохранение lock-файла

Использование плавающего диапазона версий означает, что код внутри процесса вашего агента может измениться при любой установке или обновлении без вашего участия. Зафиксируйте версию.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

Расположение флагов может отличаться в разных версиях pnpm, поэтому проверяйте результат, а не полагайтесь на команду. После выполнения откройте package.json профиля и убедитесь, что зависимость указана как чистая версия без символов ^ или ~ перед ней. Этот файл определяет, что именно будет установлено.

Затем сохраните lock-файл, который фиксирует всё дерево зависимостей, а не только пакеты верхнего уровня:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Скопируйте его в место, где вы храните резервные копии, вместе с package.json профиля. Эти два файла позволяют восстановить идентичное дерево зависимостей на новом сервере. Запускайте dsh plugin --profile web update только тогда, когда вы решили обновить версии, а не в качестве рутинной очистки, и после этого обязательно просматривайте diff lock-файла.

Для плагина, установленного из git, а не из реестра, фиксируйте коммит, а не ветку. Спецификация вида github:owner/repo#<full commit sha> обеспечивает неизменность дерева. Имя ветки при следующей проверке pnpm вернет то, что находится в ней на текущий момент, — это решение, которое вы делегировали кому-то другому. Сама инфраструктура требует такой же дисциплины, поскольку каждая опубликованная сборка dsh является релиз-кандидатом, и установка без фиксации версии может привести к получению разных результатов в разные дни. Именно здесь кроется причина большинства ошибок установки и версий dsh.

Рынок плагинов и ценность «курируемого» контента

У dsh есть маркетплейс, который устанавливается как плагин. Это многое говорит об архитектуре:

dsh plugin --profile web add dshmarket

После перезагрузки он появляется в разделе Settings, а затем в Plugin Market. В его README прямо указаны ограничения. Установка разрешена только из источников, включённых в курируемый реестр; всё остальное отклоняется. Скрипты сборки по умолчанию заблокированы, и для включения каждого из них требуется отдельное подтверждение для каждого пакета. Терминальные плагины помечаются специальными флагами перед тем, как попасть в веб-профиль. Самое важное утверждение заключается в том, что наличие в списке не является гарантией качества, так как плагины — это сторонний код.

Курируемый список повышает базовый уровень безопасности. Он не проверяет код за вас и не может предсказать, что сделает следующая версия плагина после смены владельца учётной записи сопровождающего. Относитесь к установке в один клик так же, как вы относились бы к curl | bash от того же автора. Стоит повторить ещё одну строку из этого README: экспортированная резервная копия может содержать учётные данные из конфигурации вашего профиля, поэтому никогда не прикрепляйте её к публичным тикетам или на сайты для обмена текстом. Если вам нужен готовый список, а не метод, плагины dsh, которые стоит установить — это сопутствующая статья к данной.

Запуск dsh от имени отдельного пользователя, а не root

Тщательная проверка снижает вероятность проникновения вредоносного кода. Принцип наименьших привилегий определяет, к чему этот код получит доступ в случае успеха. На VPS реализация этого принципа не требует больших затрат.

Создайте для инструмента отдельную учетную запись Unix с собственным домашним каталогом и никогда не запускайте его от имени root:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

В рамках этой сессии запустите инструмент, чтобы он записывал данные в домашний каталог этого пользователя:

npx @deepseek-ai/dsh web

Веб-интерфейс по умолчанию работает на http://127.0.0.1:3080. Оставьте этот параметр без изменений. Любой, кто получит доступ к этому порту, сможет управлять агентом, имеющим доступ к командной оболочке. Таким образом, публикация порта 3080 равносильна предоставлению удаленного доступа к оболочке без прав root через удобный интерфейс. Вместо этого подключайтесь к нему со своего ноутбука через SSH-туннель:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Затем убедитесь, что ни один процесс не прослушивает публичный адрес:

ss -lnt | grep 3080

Локальный адрес должен выглядеть как 127.0.0.1:3080. Если вы видите 0.0.0.0:3080, то единственным препятствием между злоумышленником и вашим агентом является сетевой экран. Принципы, описанные в разделе безопасный запуск Claude Code на VPS, в полной мере применимы и к dsh. Выделите агенту один рабочий каталог, который ему разрешено изменять, и не храните на этой машине ничего, что вы не сможете восстановить. Еще лучше — рассматривайте этот сервер как одноразовую виртуальную машину для агентов-программистов, поскольку переустановка VPS занимает час, а аудит безопасности — целую неделю.

Где хранятся ваши ключи и почему прав доступа к файлам недостаточно

dsh хранит API-ключи в $DSH_HOME/.credentials.yaml, а переменные окружения — в $DSH_HOME/.env; настройки моделей находятся в $DSH_HOME/settings.yaml, а история сессий — в $DSH_HOME/storages. Какой именно ключ должен находиться в каждом из этих файлов и какие данные покидают сервер в разных режимах работы — тема раздела настройка API-ключей, моделей и эндпоинтов dsh. Рекомендуем разобраться с этим до установки плагинов, так как каждый подключенный ключ становится доступным для чтения плагином. Ограничьте доступ к двум наиболее важным файлам:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Режим 600 предоставляет владельцу права на чтение и запись, а всем остальным пользователям — никаких прав. Полезно знать это в обеих нотациях (числовые и символьные режимы chmod). Оценивайте возможности защиты объективно. Права доступа защищают файлы от других учетных записей на сервере. Они не защищают от плагина, так как плагин выполняется от имени владельца файлов внутри процесса, который их считывает. Именно поэтому изоляция секретов от AI-агентов подразумевает, что их вообще не следует хранить на машине. На сервере с dsh должен находиться только один ключ для модели, который необходим для работы. Ваши облачные учетные данные и ключи подписи должны храниться в другом месте.

Почему плагин, считывающий веб-страницы, меняет модель угроз

Web seam предоставляет плагинам инструменты для поиска и получения данных. Плагин, который загружает страницу в вашу сессию, извлекает текст, написанный злоумышленником. Модель промптов не разделяет инструкции и данные, поэтому загруженная страница может содержать строку, адресованную вашему агенту, а среда выполнения с доступом к оболочке (shell) находится в одном шаге от её исполнения.

Механизм контроля уже существует в среде выполнения. dsh-base, первый пакет в каждом профиле, содержит песочницу и политику подтверждения действий. Используйте его. Сессия, способная загружать недоверенные страницы, должна требовать подтверждения для любых операций записи или исполнения, чтобы загруженная инструкция не могла стать самостоятельным действием. В Ограничение действий агента через подтверждения описано, как определить границы этих ограничений. Взаимосвязь работает в обоих направлениях, так как ваш собственный сервер — это страница, которую может загрузить чей-то агент, что рассматривается в блокировке AI-краулеров на вашем сервере.

Как проверить, что изменил плагин?

Сделайте снимок состояния до установки, выполните установку, сделайте снимок после, а затем изучите разницу.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

Diff показывает, какие записи плагин добавил в составное дерево после установки. Если плагин, установленный ради одной небольшой функции, добавляет множество записей, которые вы не можете объяснить, — это повод остановиться и изучить исходный код перед запуском. dsh plugin --profile web why <package-name> отвечает на другой вопрос: какая из ваших прямых зависимостей потянула за собой конкретный пакет.

Установленные пакеты попадают в $DSH_HOME/profiles/node_modules, поэтому вы также можете просмотреть дерево на диске:

ls ~/.dsh/profiles/node_modules

Держите второй профиль, в котором вы никогда не проводите эксперименты. Если установка нарушает работу системы, загрузка dsh --profile <clean-name> за секунды покажет, был ли причиной плагин.

Как удалить плагин dsh?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Удаление зависимости не всегда приводит к удалению конфигурации. Записи, добавленные в профиль cordis.patch.yml, остаются на месте, так как этот файл принадлежит вам, и инструментарий не будет перезаписывать его автоматически. Откройте файл и удалите блок, в котором упоминается удаленный пакет.

less ~/.dsh/profiles/web/cordis.patch.yml

Затем перейдите к этапу, который не исправит ни одна команда удаления. Если вы удалили плагин из-за потери доверия к нему, помните: всё, что он мог прочитать, он уже прочитал. Обновите API key для DeepSeek в консоли провайдера, а также обновите все остальные данные, которые хранились в $DSH_HOME. После этого проверьте, к каким ресурсам в вашей сети имел доступ unix-аккаунт, от имени которого работал плагин.

Краткая версия

• Изучите опубликованный tarball перед установкой, начиная с scripts и входного файла.
• Фиксируйте точную версию или конкретный коммит для git-спецификации и сохраняйте lockfile.
• Выполняйте установку в отдельный профиль и держите чистый профиль, с которого можно загрузиться в случае сбоя.
• Сравнивайте --dump-config до и после каждой установки.
• Запускайте обвязку (harness) от имени отдельного пользователя unix, на loopback-интерфейсе, с доступом по SSH.
• Храните на сервере один API-ключ и меняйте его в день удаления плагина, которому вы больше не доверяете.

Все это не повод отказываться от плагинов. Модель плагинов делает dsh полезным инструментом, а обвязку, которую нельзя расширить, придется заменить. Это повод знать, что именно вы установили, от кого, какой версии, и запускать всё это там, где вы сможете выполнить пересборку.

FAQ

Изолирует ли dsh плагины друг от друга?

Нет. Плагин загружается в процесс harness через Cordis и получает доступ к документированным интерфейсам взаимодействия, включая shell, файловую систему, web, подпроцессы, subagent и учетные данные. dsh-base, первый пакет в каждом профиле, содержит песочницу и политику одобрения, которые определяют допустимые действия инструментов агента; именно эта политика обеспечивает вашу защиту. Границы разрешений для каждого отдельного плагина отсутствуют, поэтому честная модель безопасности подразумевает, что установка плагина означает распространение вашего доверия на его автора и на каждый пакет в дереве его зависимостей.

Можно ли установить плагин dsh, не запуская его скрипты установки?

pnpm 10 и более поздние версии блокируют скрипты сборки зависимостей по умолчанию, а dsh plugin ... add перенаправляет запросы в pnpm, поэтому в актуальной версии pnpm установка не запускает скрипты пакета, если вы не одобрили этот пакет. Проверьте свою версию с помощью pnpm --version. Это не делает непроверенный плагин безопасным. Собственный код плагина запускается при следующей загрузке, так как harness загружает его намеренно, на что не влияют никакие ограничения времени установки.

Где фактически хранятся плагины dsh и их конфигурация?

$DSH_HOME по умолчанию использует ~/.dsh. Профили находятся в $DSH_HOME/profiles/<name>, каждый из них содержит package.json с зависимостями плагинов, манифест dsh.profile с упорядоченными пакетами и слой исправлений cordis.patch.yml. Установленные пакеты размещаются в $DSH_HOME/profiles/node_modules. Ключи находятся в $DSH_HOME/.credentials.yaml, значения переменных окружения — в $DSH_HOME/.env, а файл $DSH_HOME/cordis.patch.yml на уровне домашней директории применяется ко всем профилям. Запустите dsh --profile web --dump-config, чтобы увидеть итоговую конфигурацию без запуска системы.

Безопасно ли устанавливать плагины из маркетплейса dsh?

Маркетплейс ограничивает установку источниками из проверенного реестра и блокирует скрипты сборки, пока вы не одобрите их для каждого пакета отдельно, что является реальным улучшением по сравнению с копированием имени пакета из чата. В его собственном README по-прежнему указано, что размещение в каталоге не является одобрением, так как плагины представляют собой сторонний код от других разработчиков. Изучайте исходный код и фиксируйте версию. Запускайте harness от имени пользователя и, по возможности, на машине, потерю которой вы можете себе позволить.