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
Discovery
Candidate plugins are discovered by crawling the GitHub topic dsh-plugin and by manual submission through the site. Discovery is deliberately broad: it is not a quality judgment.
Repository validation
Each candidate must point to a reachable GitHub repository. The owner/repo slug is normalized to lowercase and cross-checked so that index entries resolve to exactly one repository.
Metadata validation
We require the fields a user needs before installing: name, description, license, and a working install command. Artifacts missing these are held out of the verified denominator.
Verification
Multi-stage verification runs against the repository and manifest. The registry does not yet expose per-artifact verification stage flags, so no artifact is marked Verified today. Not verified means untested — it never means unsafe.
Security scanning
Every indexed artifact is scanned in an L4 sandbox. Findings are bucketed into critical / warning / info. A finding records a pattern we can observe; it says nothing about intent.
Health assessment
Maintenance signals such as the latest commit date feed the activity view (plugins whose last commit is within 90 days are shown as active). Activity is a freshness signal, not a quality score.
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.
- 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.
- 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.
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.
- Manual submissions — reviewed before entering the index.
data/metrics-history/snapshots.jsonl.