Every week a new "risky plugin checker" query spikes whenever a supply-chain scare hits the DeepSeek Harness ecosystem. If you have been searching for a way to tell whether a DSH plugin is safe, the good news is that most risk is visible in public metadata — you just need to know where to look.
Start With the Install Script
The single highest-signal check is the install script. Patterns like curl|sh, base64 -d, or powershell -enc piping remote content into a shell are red flags regardless of how many stars a plugin has. A clear, auditable install path is the baseline for trust.
Look for the dsh.bundle Declaration
The dsh.bundle declaration is the one contract the runtime enforces. Its absence is a legitimate warning, not a style nitpick — it means the runtime cannot validate what the plugin actually loads. Treat a missing bundle as a "proceed with caution" signal.
Check Maintenance and Archival State
- An archived or read-only repository means no future security fixes — a plugin frozen in time is a liability the moment a new exploit appears.
- Recent commit activity and issue responses are better proxies for safety than star counts.
- Unmaintained code that still works today can break on the next runtime update.
Don't Rely on Stars or Self-Reported Ratings
Stars and self-reported ratings can be inflated. Independent, heuristic scoring that uses real data — maintenance activity, documentation quality, and npm health — gives a far more honest view of plugin quality.
A 30-Second Pre-Install Checklist
- Read the install script; reject curl|sh / base64 / encoded-payload patterns.
- Confirm a dsh.bundle declaration exists.
- Verify the repo is not archived and had a commit in the last 90 days.
- Cross-check the score against an independent rating, not just the README.
None of these checks require deep expertise — just a habit. Build it, and the "risky plugin" problem stops being a mystery and becomes a routine, 30-second decision.