dsh-plugin-gate

The plugin marketplace is scaling fast, and the first real-world malware slipped into a third-party package is no longer a hypothetical. dsh-plugin-gate fills the security gap right before dsh plugin add fires: a read-only static scan of the plugin source, whether a local directory or an npm tarball, performed before anything is installed. It never executes scanned code and never writes a file, so the scanning step itself introduces no new attack surface.

The scanner spans six domains with 60 signature rules (31 high / 24 medium / 5 low): npm lifecycle scripts and shell invocations, obfuscation tricks like eval, base64, and char-array packing, credential environment reads and system-path writes, external network callbacks and cloud-metadata endpoints, hardcoded API keys and private-key blocks, and exact-version dependency lookups against the Google OSV feed. Verdicts land as BLOCK, WARN, or PASS, with context-aware downgrading. Comments, documentation examples, and RegExp#exec false positives are automatically de-escalated, while secrets and webhooks stay flagged regardless of context. On the data-protection side, the built-in gate_guard intercepts 12 destructive-command patterns, including rm -rf, format, dd to block devices, and mkfs, plus workspace-boundary checks. Device-level destruction is a hard BLOCK; recursive or force deletes of critical files such as memory.json or .git trigger a WARN demanding explicit target confirmation; everything else passes through. It is heuristic and honest about its limits, deliberately not a sandbox or runtime interceptor.

This is the right pick for developers and team admins who assemble, debug, and ship DeepSeek Harness plugin stacks daily. If you want scan-before-install to be the agents default reflex, or need a lightweight guardrail so a stray agent command cannot nuke the workspace or the memory store, this plugin is that thin-but-sufficient gate. It will not catch novel zero-day malware and will occasionally over-flag innocent code, as the README states plainly. Treat every BLOCK and WARN hit as a conversation with the maintainer rather than an automatic verdict, and you get a pragmatic, low-noise layer of protection exactly where the risk is highest: the moment between finding a plugin and it actually running.