Install script scanning is the part of DSH Quality people ask about most. When a plugin runs an install script it gets arbitrary code execution on your machine during npm install — which is exactly what a malicious package wants. Here is how our dsh install script scanning works under the hood.
What the Scanner Checks
We inspect the package manifest and scripts that run during install, looking for patterns that should never appear in a well-behaved plugin:
- curl / wget piped to sh or bash — the classic remote-code-execution pattern.
- Base64-encoded commands or obfuscated strings in postinstall.
- Network exfiltration calls (POST to unknown endpoints, reading env files).
- File-system sweepers that touch home directories or ssh keys.
- Package manager reinstall loops or self-modifying scripts.
What It Misses
Heuristics are not a proof of safety. A determined attacker can obfuscate past string matching, fetch a payload at runtime, or hide behavior inside a dependency. That is why the scanner flags "dangerous install script" as a hard veto on the grade — but absence of a flag is not a clean bill of health.
How to Read the Results
- Dangerous install script flag: do not install. Even for evaluation, run it in an isolated environment.
- Missing dsh.bundle: verify the plugin loads before trusting it; it is a warning, not a guarantee of malice.
- No flags: still review the plugin repo if you plan to run it with privileged access.
The goal of the scanner is to make risky dsh plugins visible in seconds. Treat it as your first filter — not your last.