Security audit
Every plugin gets an automated scan of its code, dependencies, and permission requests. Automated static analysis — a scalable first line of defense, not a manual review. Scan results are built into every artifact's record rather than bolted on.
16,185 plugins scanned · 0 critical-risk
63 added · 0 critical
Latest: 2026-W40 (2026-09-27) · risk trends over time
Three risk tiers · what we scan · how we rate
What we scan
Known CVEs in direct and transitive dependencies, from public vulnerability databases.
Requests that reach outside the plugin's declared scope — fs.write, network.external, env access.
API keys, tokens, or credentials committed into the repository.
Unpinned dependencies, suspicious install scripts, or post-install hooks.
Risk levels
✓ Static scan live
16,185 artifacts have a static heuristic scan (code execution, hardcoded secrets, exfiltration endpoints, destructive commands); 331 remain pending. Automated static analysis — a scalable first line of defense, not a manual review.
Deep security audit (dependency CVEs, permission sandboxing) is planned next and will layer on top of this defense line. Until then, treat the scan as your first-pass filter and combine it with the verification level and plugin health before installing — one more signal, one less surprise.
What does the dsh.so security scan check?
The scan checks repository code and manifest metadata for hardcoded secrets, suspicious permissions, destructive commands, exfiltration endpoints, unpinned dependencies, install hooks, and other supply-chain signals. Results are stored per plugin and summarized in the daily and weekly security reports.
How does the scan relate to a manual audit?
The scan is static analysis: it inspects code patterns, dependency manifests, and permission requests, and never executes plugin code on anyone's machine — which is what makes it safe to run across every collected plugin as a scalable first line of defense, quickly surfacing known risks like hardcoded secrets, dangerous permissions, and supply-chain red flags. Automation has limits: complex context can be missed and false positives happen. Treat a low-risk rating as a strong triage signal and combine it with the verification level (L4/L5 real tests) and plugin health when deciding — more signals, more confidence.
Source: dsh.so security reports and public repository metadata · Maintained by dsh.so · Last updated