How dsh.so verifies plugins

dsh.so is an independent trust & discovery registry for DeepSeek Harness plugins. This page describes exactly how artifacts move from discovery to verification, what our automation can and cannot tell you, and where the current pipeline stops.

The six-stage pipeline

Trust model: three inequalities

These three statements are load-bearing. Everything else on this page should be read through them.

What we verify

• That an artifact resolves to exactly one reachable GitHub repository.
• That the metadata a user needs before installing exists and is coherent.
• Observable patterns in plugin code and dependencies, via sandboxed scanning.
• Context around those patterns, via a model-driven dynamic security audit that reads a redacted source snapshot — for the subset of plugins the static rules rate at warn or above. It never executes plugin code, and its conclusion can only raise the verdict, never exempt it.
• Maintenance freshness, expressed as an absolute snapshot — never as growth.

What we do not verify

• Absence of malicious behavior. Automated verification cannot guarantee that a plugin is free of malicious logic, now or after any future update.
• Authorial intent. A security finding describes an observable pattern, not the author's state of mind.
• Runtime safety of every execution path. Sandbox scans sample behavior; they cannot enumerate everything a plugin might do on your machine. The dynamic audit reasons about a redacted source snapshot instead of running the plugin, so it observes nothing at runtime either.
• Registry-wide dynamic coverage. The dynamic audit queue holds only plugins whose static verdict is warn or above, and it sees only the source the pipeline managed to collect. A plugin absent from that queue has not been dynamically audited — and an audit with no conclusion is not a pass.
• Endorsement. Nothing on dsh.so is a recommendation. Verified means tested, not trusted.

Limitations

Automated verification cannot guarantee absence of malicious behavior. Scans are point-in-time: a plugin that passes today can change tomorrow, and the registry re-scans on its own schedule rather than continuously. Heuristic scanners produce false positives — a critical bucket is an instruction to look, not a verdict — and false negatives are possible whenever a pattern is new to us. Finally, the index itself has a boundary: plugins outside our discovery surface are invisible here, which is why every count on this site is labeled with its caliber. The dynamic security audit has a second boundary on top of that: it only covers the source the pipeline actually collected, and only for plugins the static rules already rated at warn or above — so its coverage is a subset of the registry, not the whole of it.

False positives and corrections

If your plugin carries a finding you believe is wrong, open an issue on the registry repository with the finding identifier. Confirmed false positives are corrected in the next scan cycle, and the daily snapshot records the correction history rather than overwriting it.

Update frequency

Registry data refreshes on hourly pipelines (discovery, submissions, security reports). A daily snapshot at 03:17 UTC freezes the six-caliber metrics into an append-only history file; every number published on this site cites the snapshot date it came from.

Data sources

• GitHub API — repository metadata, topics, stars, commit activity.
• npm registry — package existence, weekly downloads, repository cross-checks.
• L4 sandbox scans — per-plugin finding buckets.
• Model-driven dynamic security audit — a redacted source snapshot is collected under bounds and audited for context; plugin code is never executed. Only plugins the static rules rate at warn or above enter the queue.
• Manual submissions — reviewed before entering the index.