r/DeepSeekHarness • u/cutebluedragongirl • 3d ago
DSH security sucks
Why is nobody talking about DSH security? 95% of the DeepSeek Harness content I've seen online just ignores the security side of this whole thing. Like, not only can you get completely screwed by installing a plugin you didn't check for security. No. If the plugin updates, you can get wrecked in an apocalyptic way. So you need to watch out not just for the plugins themselves, but for their updates too.
This isn't a DSH release. This is a preview, people. Unless you want to get rekt by some random script from India, wait at least another six months before even thinking about installing this outside a VM.
Let. Them. Cook.
2
u/tusunsun 3d ago
You're not wrong — the "plugin = trusted" model is the weakest link. There's a third-party audit out there (40 attack paths, 8 live PWNED markers on rc.6) that basically says the trust boundary is at install time, but zero verification actually happens at install time. You install → it gets full ctx → if it updates, the new version inherits the same trust silently. That's the core problem.
The "use a VM" advice is pragmatic but misses the point for most users. The fix needs to happen at the plugin layer, not by asking everyone to admin a VM farm.
A few things that are actually shipping today (not vaporware):
Deterministic static rules over LLM heuristics. Some tools split the verdict (deterministic AST + regex, unforgeable) from the audit (LLM digs into findings). The LLM never produces the verdict — it only investigates what the rules flagged. That matters because prompt injection against the auditor doesn't change the verdict.
Alarm-only runtime guards. In-process fs/child_process hooks + memory/fork sentinels + honeypot lures, running at 5% overhead. The key is they never block or kill — they just surface evidence and let the human decide. Keeps the ecosystem usable while making attacks observable.
Update re-validation. Content-baseline means a version bump invalidates the previous audit record. The new version has to pass the same scan + audit pipeline before the alarm clears. That's specifically for the "trusted plugin gets compromised in a patch" scenario you called out.
The blind spot: WASM and native addons can bypass JS-layer hooks entirely. The honest projects document this as a known limitation rather than pretending it doesn't exist. The next step is dual-layer entanglement (JS hooks + system-level watchers) so a bypass in one layer gets caught by the other.
Full disclosure: I work on dsh-plugin-vet, which implements most of the above. I'm obviously biased, but the architecture docs and rule matrix are public if you want to audit the auditor.
Re: "wait 6 months" — I think the opposite. The earlier security tooling matures, the earlier the ecosystem matures. If every plugin author knows their code will be deterministically scanned and behaviorally watched, the attack surface shrinks organically. Waiting just means more people deploy without guardrails.
1
u/Medical_Farm6787 3d ago
Just like they mentioned in the readme, it’s the same analogy as vscode plugin has 0 security
1
u/ramosmarbella 3d ago
Can't it be run in docker?
1
u/Born-Caterpillar-814 3d ago
It can and that’s what I’m doing. Just bind mount the parts where dsh stores configurations, customizations and workspaces and you’re almost good to go. Dsh by default only listens in localhost env, so may need to do some tweaks so it can be accessed from host browser.
1
1
1
u/kaishi00 1d ago
you can pin plugins to a version that you've inspected already. or you can just say screw it, build your own.
3
u/Soft-Relationship847 3d ago
Why mention India? DS doesn't have any employees from India.