Comparing DSH plugins and VS Code extensions starts with one uncomfortable fact: they look alike and protect you very differently. A VS Code extension usually runs with the same trust you give the editor itself, and that is the core of vscode extension risk. The DSH plugin security model takes the opposite route, treating every plugin as untrusted until a scan says otherwise. This piece walks through both plugin security models side by side, so you can see where dsh plugin safety genuinely differs and where the two systems are closer than the marketing suggests.
The VS Code extension security model
How it works:
- Extensions run in the same process as VS Code
- Full access to your filesystem
- Can execute arbitrary commands
- Installed from the Microsoft Marketplace or directly from a file
Where the risk sits:
- One malicious extension can compromise the whole environment
- No sandboxing between extensions
- Privilege escalation is possible
- Supply chain attacks arrive through a compromised dependency
None of this makes extensions unsafe by default. It means the model leaves the checking to you, and most people do not have the time for it.
The DSH plugin security model
How it works:
- Plugins run in isolated sandboxes
- Filesystem access is limited by default
- Security scanning is mandatory
- Quality scoring is independent of install counts
What that buys you:
- Each plugin runs in isolation from the others
- Pre-install security warnings
- Real-time threat detection
- A scoring method you can read and audit
Side-by-side comparison
| Security aspect | VS Code extensions | DSH plugins |
|---|---|---|
| Sandbox | No | Yes |
| Filesystem access | Full | Limited |
| Scanning | Optional | Mandatory |
| Quality scoring | Community ratings | Independent analysis |
| Install warning | Rare | Always |
What this means in practice
If you install VS Code extensions, be selective. Check download counts and ratings, look at recent commits and who maintains the project, and stay with publishers you have reason to trust.
For DSH plugins, the platform does more of the security work before you decide. Scanning runs at install time, quality grades from A to D are shown up front, and suspicious patterns raise a warning instead of waiting for you to find them.
Best practices that apply to both
- Limit what you install. Only add what you actually use
- Review before installing. Check reputation and purpose
- Keep things updated. Security fixes ship with updates
- Monitor permissions. Know what each tool can reach
FAQ
Are DSH plugins completely safe?
No system is. The DSH model adds layers that VS Code extensions do not have, but a layer is not a guarantee.
Can I use both DSH and VS Code extensions?
Yes. They usually do different jobs. DSH fits a CLI workflow, VS Code fits IDE work.
How does DSH scan for threats?
Static analysis of install scripts, dependency checks, and pattern matching against known attack vectors.
A security model is less a matter of taste than a matter of who does the first pass. If you would rather the platform did it, the DSH model is built that way. Our scoring method, including how security and maintenance are weighted, is published on dshquality.com. Two follow-ups worth your time: /blog/plugin-supply-chain-security-team-enforcement on where attacks actually come from, and /blog/setting-up-a-plugin-allowlist-for-your-dev-team on turning this into a team rule.