A security checklist before installing plugins
A ten-minute check of source, command, permissions, credentials, and rollback path — distinguish missing evidence from explicit risk before granting a plugin access.
8 min read
After this tutorial you will
- Complete a ten-minute pre-install review of source, command, permissions, and rollback
- Distinguish missing evidence, a need for confirmation, and a clear reason to stop
- Use an isolated profile to limit the blast radius of an unfamiliar plugin
Compatible version
Compatible with: dsh 0.1.x. This is a user-side decision checklist, not a security certification or a substitute for code review.
Why review plugins before installing
A plugin can read files, call a network service, launch an external program, or give an agent another action it can invoke. Risk does not automatically mean “do not install.” It means you should know why a capability is needed and whether you can stop and recover.
The useful question is not “is it safe?” but why does it need these capabilities, and can I get out cleanly if it fails?
The ten-minute checklist
1. Source: do I know where the code comes from?
Check that the npm package or GitHub repository in the command matches the detail page and README; that the repository is public and attributable; and that the README explains purpose, setup, and limits. A star count cannot replace this evidence, especially for a sub-package inside a larger repository.
2. Command: do I understand what will run?
Read the profile, source, version/ref, local path, and extra flags. Pause when you see a download piped directly to a shell, a request to disable protections or broadly allow build scripts, a temporary or anonymous source, or a command that disagrees with the README.
The compatibility checker highlights some risky patterns in indexed text. It is a prompt to investigate, not a green light; no finding is not a code audit.
3. Permissions: are capabilities proportional to the job?
| Capability | A reasonable purpose | A reason to investigate |
|---|---|---|
| Project-file access | Code search or document analysis | A theme scanning your whole home directory |
| Network access | Calling a named API | No stated domains or data flow |
| Child process | A known conversion tool | Arbitrary shell or persistent background process |
| Token | A particular external service | A request to paste it into a README, command, or repository |
More permissions are not automatically bad. Every permission should have an explanation you can repeat back.
4. Credentials: where will a token go?
Never paste API keys, cookies, SSH keys, or production configuration into chat, command history, a README, or a tracked project. Prefer a supported settings or environment-variable mechanism. Check whether configuration is logged, which service receives the token, what remains after uninstall, and whether a smaller revocable test token is available.
5. Rollback: how do I leave if it goes wrong?
Before installation, record the plugin ID, original command, profile, relevant configuration, and removal path. Test unfamiliar or higher-permission plugins in a dedicated profile first. Rollback is not failure; it is what makes a trial safe and repeatable.
Three outcomes
| Outcome | Typical case | Next step |
|---|---|---|
| Safe enough to try | Source, command, permissions, and rollback are clear | Run a minimum validation in the correct profile |
| Needs confirmation | Old docs, missing platform declaration, unclear permission reason | Read upstream docs/issues or test in isolation |
| Stop | Secret request, disabled protection, or unexplained script | Do not install; retain the link and ask the maintainer if needed |
Common questions
Does a high machine-audited evidence score mean I can trust it?
No. It means the directory can verify more facts, such as a README, command, license, or compatibility field. It does not prove there are no vulnerabilities or that the plugin fits your environment.
Do I need this for a theme?
The review can be quick, but should not disappear. A theme normally needs little privilege; network, broad file access, or shell requests are exactly the reason to pause and ask why.
Next up
After the review, use the minimum-validation process in Plugin install troubleshooting.