Ask five things before launch: who can publish, what can a plugin reach, how does it get updated, how do you stop a bad one, and how will you notice trouble. If any answer is "we have not decided," that gap is your first piece of work.
1. Who can publish?
Decide whether plugins are internal only, partner only or open to anyone. The more open the answer, the more you need identity checks and review. Verified publisher programs, such as the domain proof used by the Visual Studio Marketplace, narrow impersonation but do not prove code is safe. Write down which account protections you require, such as multi factor authentication for publishers.
2. What can a plugin reach?
List what a plugin gets by default. In some hosts the answer is everything: VS Code states that its extension host has the same permissions as the app itself. In others the host restricts it, as Figma does by keeping data access and network access in separate contexts. Draw the line for your product and convert it into a manifest. Your goal is a short list of declared capabilities enforced by the host.
3. How does a plugin get updated?
Updates are where trusted plugins go bad. Chrome disables an extension until the user accepts a new warning permission, which is a model worth borrowing. Decide how you will compare manifests between versions, verify signatures, and let admins pin versions.
4. How do you stop a bad plugin?
You need a kill switch that disables installed copies, not just delisting. The Visual Studio Marketplace removes a verified bad extension, adds it to a block list and has VS Code uninstall it automatically. Decide who can pull the switch, how fast it propagates and how you notify users. Practice it.
5. How will you notice trouble?
Monitoring turns a quiet compromise into an alert. Marketplaces watch downloads and usage for unusual behavior, and Chrome reviews published items periodically. Decide what telemetry you will collect from plugins, such as call volume to sensitive APIs and new network destinations, and who looks at it.
Put the answers in one table
| Question | Your answer | Control | Owner | Done? |
|---|---|---|---|---|
| Who publishes | Identity, MFA | |||
| What it reaches | Manifest, sandbox | |||
| Updates | Diff, signing, pinning | |||
| Stop | Block list, drill | |||
| Notice | Telemetry, reviews |
Steps to run the session
- Gather security, product, support and one plugin developer in one room.
- Draw the data flows between host, plugin and outside services.
- Walk each flow with the five questions.
- Record the gaps, assign owners and set dates.
- Revisit after the first ten plugins ship, because real plugins surprise you.
What this is not
A short exercise is not a full threat model, and it does not replace a deeper review for high risk features. It gets a team to the first useful decisions quickly and makes the larger review sharper.
Quick check
Who should run the session?
Someone who can make decisions about the product, with security in the room. A plugin developer's view is useful because they see how the API gets misused.
How often should it be repeated?
Repeat it when you add a new capability, a new plugin type or a new distribution channel, and at least once a year.
Safeguard supports the follow through: SBOM and dependency scanning, policies and gates for releases, and compliance and evidence automation to record the controls. Start with the free scan.
Sources
- Extension runtime security, Visual Studio Code
- How Plugins Run, Figma Developer Docs
- Permission warning guidelines, Chrome Extensions
- Chrome Web Store review process
Last reviewed: 19 October 2026.
