Introduction

In the plugin mechanism of DSH, dynamic plugins are often installed or run via cordis_define and cordis_run. Performing static reviews on plugin source code, providing clear judgments, and retaining operator approval and whitelist entry points are common requirements when handling dynamic plugins. dsh-plugin-security-review provides such a guard: it reviews dynamic plugin source code, handles installation or execution based on a security-first strategy, and provides two tools: plugin_security_review and plugin_security_audit.

What is this

dsh-plugin-security-review is a DSH plugin installation security review guard maintained by ShanHaiFish, licensed under MIT.

Its positioning is to perform static security reviews around the source code of dynamic plugins for cordis_define / cordis_run, handling installation or execution with BLOCK / ASK / WARN / ALLOW, and providing review, audit, approval popups, and local whitelist capabilities. The static bundle form is automatically loaded with the profile layer stack.

Core Features

  • Perform static security reviews on the source code of dynamic plugins installed or run via cordis_define / cordis_run.
  • Handle installation or execution based on BLOCK / ASK / WARN / ALLOW judgments.
  • Provide plugin_security_review / plugin_security_audit review tools.
  • The static bundle form is automatically loaded with the profile layer stack.
  • Support browser approval popups: Approve / Approve+Whitelist / Reject.
  • Support trusted-local whitelist, allowing direct passage based on prefixes / pluginIds / fingerprints.
  • Persist code fingerprints after manual approval of ASK, and automatically allow passage on subsequent hits of the same fingerprint.
  • Code changes invalidate the original fingerprint approval.

Installation and Enablement

Recommended static bundle form:

dsh plugin --profile web add dsh-plugin-security-review

For unpublished or offline debugging, you can use file: local installation:

dsh plugin --profile web add file:/path/to/dsh-plugin-security-review

After restarting dsh web, call the parameterless plugin_security_audit, it should display:

Guard: Running (v1.8.1)

Typical Usage

Approval Popup

The static bundle form supports browser approval popups with options:

  • Approve
  • Approve+Whitelist
  • Reject

After successful manual approval of ASK, the code fingerprint will be persisted; subsequent hits of the same fingerprint will automatically allow passage. After code changes, the original fingerprint approval becomes invalid.

trusted-local Whitelist

The local whitelist file is located at:

<DSH_HOME>/storages/plugin-security-gate/trusted-local.json

Configurable fields:

{
  "prefixes": ["<prefix>"],
  "pluginIds": ["<pluginId>"],
  "fingerprints": ["<sha256>"]
}

When hitting the trusted-local whitelist, the corresponding cordis_define / cordis_run will be allowed directly.

Fallback to Official Approval UI

If you want ASK to fallback to the official approval UI, you can configure:

<DSH_HOME>/storages/plugin-security-gate/config.json

Content is:

{"askMode":"seam"}

Capability Declaration

Append the capability declaration at the end of the purpose in cordis_define:

CAPABILITIES: spawn,network,env,fs

Dynamic Plugin Fallback Form

The dynamic fallback form is used for profiles without bundle capabilities; the basic steps are:

  1. Read package-source.js and manifest.json.
  2. Call cordis_define.
  3. Call cordis_run to activate.
  4. Call plugin_security_audit to verify.

The dynamic fallback form does not persist across DSH processes and requires reloading after restart; this form does not provide browser approval popups.

Applicable Scenarios and Notes

Suitable for the following scenarios:

  • Need to install or run dynamic plugins in DSH.
  • Need to perform static reviews on plugin source code for cordis_define / cordis_run.
  • Need to retain manual approval, code fingerprint approval, and local whitelist entry points.

Usage notes:

  • According to the DSH plugin installation mechanism, plugins run with the permissions of the current dsh process; source code and licenses should be checked before installation.
  • When source code is unsearchable, the behavior is fail-closed, i.e., ask.
  • The trusted-local whitelist is used to counter high-risk installations without operator confirmation, not to secure the agent itself.
  • In full-access deployments, the agent can also write to the trusted-local file.
  • Adding the guard’s own id/prefix to the trusted-local whitelist will disable the guard’s self-protection.
  • Writing to the trusted-local whitelist failure is only logged and does not affect code fingerprint approval; the read side remains fail-closed.
  • peerDependencies requirements:
  • @deepseek-ai/dsh-tools: ^0.1.1-rc.2
  • @deepseek-ai/dsh-cordis-host-runner: ^0.1.1-rc.2
  • The community directory is an independent site with no official affiliation with DeepSeek or ShanHaiFish, and should not be written as an official app store.

Conclusion

The value of dsh-plugin-security-review lies in putting a static review, a clear judgment, a manual approval, and a set of whitelist rules all on the same path before dynamic plugin installation. It is suitable for DSH / Agent developers to use when managing the installation and execution of dynamic plugins.

GitHub Repository:

https://github.com/ShanHaiFish/dsh-plugin-security-review

Community Directory Page: Specific URL not provided in verified materials.