A new plugin or extension store should launch with six controls: signed packages, risk-based review, declared permissions, a reporting route, a block mechanism that reaches installed copies, and monitoring after approval. Public store policies from Chrome, Mozilla, VS Code and WordPress.org show each of these already in use.
The six controls
| Control | What it means | Public example |
|---|---|---|
| Signing | Packages are signed at publish and checked at install | VS Code signs all extensions at publication and checks the signature at install |
| Risk-based review | Some submissions get deeper review | Chrome lists new developers, dangerous permissions, broad hosts and large code |
| Declared permissions | Plugins ask for the narrowest access | Chrome requires the narrowest permissions needed |
| Reporting | A visible route with a response target | VS Code states an initial response within one business day |
| Blocking | Removal that reaches installed copies | VS Code block list and automatic uninstall |
| Monitoring | Review continues after approval | Mozilla can manually review any add-on at any time |
1. Sign at publish
A signature gives clients a way to check integrity and source. It does not prove good intent, so do not market it as safety. Keep signing keys in managed key storage and rotate them on a schedule.
2. Review by risk, not by queue order
Treat all submissions the same and you will either delay good developers or wave through risky ones. Define triggers: new publisher, new permission, large diff, obfuscated or unreadable code, remote code loading. Spend human time where the triggers fire, and automate the rest.
3. Require a permission declaration
Make each plugin declare what it needs, in a machine readable form, and show it at install. Compare the declaration with what the package does during review. An update that adds a permission should not install silently.
4. Publish a reporting route
Put the link on each listing and promise a first response time you can meet. Staff the queue before you launch. A short severity rubric, with impersonation and credential theft at the top, keeps the first hour focused.
5. Build the block mechanism before you need it
Decide how a blocked plugin disappears from a user's machine. Options: client checks a block list on start, the store removes the listing only, or the client uninstalls automatically. Say which one you chose in the policy, and test it with a harmless dummy plugin.
6. Keep watching after approval
Re-review on reports and on a schedule. Watch publisher changes, new permissions and vulnerable bundled libraries. Keep a policy for what happens between a warning and a takedown, including the deadline.
Controls that are easy to forget
- Name squatting and lookalike checks on listing names.
- A rule against creating new accounts to evade enforcement.
- Rate limits and anomaly checks on publishing and downloads.
- Publisher account protection: strong authentication and alerts on token use.
- A plan for the day a publisher account is compromised.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate blocks a risky change before it merges, then think about the same idea at the store's publish step.
Safeguard's policies, gates and guardrails, SBOM and dependency scanning, and zero-day discovery apply to the code behind a store and the plugins in it. You can run a free scan on one plugin to see the output.
Quick check
Does signing make a plugin safe?
No. Signing shows integrity and source. Intent still needs review and monitoring.
Which control matters first?
Reporting and blocking, because they let you respond when something slips through.
Do I need human review for every plugin?
Not necessarily. Focus humans on risk triggers and automate checks for the rest.
Sources
- VS Code: Extension runtime security
- Chrome Web Store: Review process
- Chrome Web Store: Program policies
- Mozilla Extension Workshop: Signing and distribution overview
Last reviewed: 19 October 2026.
