Automate everything that is cheap, repeatable and objective: malware scans, dependency checks, manifest diffs, name checks and usage monitoring. Keep people for judgement calls: whether a requested permission fits the plugin's stated purpose, and whether new behavior in an update is expected.
What real marketplaces do
Public documentation shows a consistent pattern. The Visual Studio Marketplace runs a malware scan on every new extension and every update, and the extension is not published until the scan is clear. It also runs dynamic detection by executing the extension in a sandboxed clean room VM, monitors downloads and usage for unusual patterns, and blocks name squatting on official publishers and popular extensions.
Chrome Web Store review uses a combination of manual and automated systems. All submissions go through the same system, new items and updates alike, but some signals make a reviewer look harder: new developers, new extensions, dangerous permission requests and significant code changes.
Mozilla adds human code review and functional testing, and asks for source code that can be reproduced from the submitted build.
A split that works
| Check | Automate | Human review |
|---|---|---|
| Known malware and bad packages | Yes | On a hit |
| Dependency vulnerabilities | Yes | On exceptions |
| Manifest permission diff versus last version | Yes, to flag | Yes, to decide |
| Does a permission match the stated purpose? | No | Yes |
| Name similarity to existing plugins | Yes, to flag | Yes, to decide |
| Runtime behavior in a sandbox | Yes | When behavior looks odd |
| Developer identity | Partly | Yes for high-risk plugins |
Use risk signals to route work
Chrome's review documentation is a good model for routing. It lists broad host permissions, sensitive execution permissions and the amount of hard-to-review code as factors that increase review time. You can do the same: score each submission and send low-risk updates down a fast path while high-risk ones wait for a person.
A simple score might add points for a new publisher, a new sensitive permission, a jump in code size, a new network destination, or code that is obfuscated. The point is not the exact weights. The point is that reviewer time goes where the risk is.
Do not review only at submission
Chrome states that existing items are also reviewed periodically, because attackers change tactics and policies change. Plan for the same. A plugin that was clean in March can ship a bad update in June, or inherit a vulnerable library in September. Re-scan the installed base when new advisories land, not only when a developer clicks submit.
Steps to stand up a first pipeline
- Pick the three objective checks you can run on every submission this quarter.
- Add a manifest diff and make any new sensitive permission a mandatory human review item.
- Write the reviewer checklist so two reviewers reach the same answer.
- Record every decision and its reason. Auditors and developers will both ask.
- Add re-scans on a schedule and on new advisories.
- Publish your rejection reasons so developers can fix issues before they submit.
Try it yourself
Click through it at your own pace, or open it full screen.
The demo shows a gate that blocks a change on a policy result. Look at how a failed check stops the merge, then picture the same pattern as a submission gate for plugins.
Quick check
Can a fully automated pipeline replace human reviewers?
Not for permissions and intent. Automation finds known bad patterns. It cannot reliably decide whether a requested capability makes sense for what the plugin says it does.
Should updates get the same review as new plugins?
Yes. Chrome and the Visual Studio Marketplace both apply their checks to updates as well as first submissions, because an update is how a trusted plugin turns bad.
Safeguard can sit inside such a pipeline on the dependency side: SBOM and dependency scanning for each submission, with policies and gates that decide pass or block. The free scan is a quick way to see the output on one plugin.
Sources
- Extension runtime security, Visual Studio Code
- Chrome Web Store review process
- Add-on Policies, Firefox Extension Workshop
Last reviewed: 19 October 2026.
