For every plugin or extension you use, a vendor, a marketplace or an admin console decides when new code arrives. Map that path for each ecosystem. Ask who can publish, whether you can pause or approve, and whether a new version can widen permissions. The update path matters more than the install review.
Why updates are the real risk
You review version one. Version two arrives later, from a publisher whose account can be compromised, sold or simply changed. Documentation from several ecosystems shows how differently they handle that moment.
| Ecosystem | What the documentation says about updates |
|---|---|
| Microsoft Office add-ins from the marketplace | Updates and enhancements are automatically deployed to users once you deploy the add-in through the admin center |
| Atlassian Forge | A new version cannot increase scopes, permissions or egress domains without site admin reapproval |
| WordPress plugin directory | Plugins should not install updates from servers other than WordPress.org's, and the plugin team can change a plugin without developer consent for public safety |
| VS Code Marketplace | Each update is malware scanned before it is published, and signed |
These are four different answers to one question. Only some give you a decision point.
Map your own paths
For each plugin type in use, fill in a row.
- Publisher. Who can publish a new version? One person, a team, or an automated pipeline?
- Channel. Does the update come through the marketplace, the vendor's own server, or both?
- Your control. Can you pin a version, pause updates, require approval, or stage a rollout?
- Permission change. Can an update add permissions without asking you?
- Detection. Would you notice a changed network destination or a new scope?
- Rollback. How do you return to the previous version, and how fast?
Where an answer is "we cannot," record it as accepted risk with an owner. See the plan to roll out Office add-ins in phases for one concrete control.
Controls that slow a bad update
- Staged rollout. Give updates to a small group first. See extension staged rollout and rollback.
- Approval on permission growth. Treat any request for broader access as a new review.
- Allowlist by version or publisher where the platform offers it. The post on allow by publisher, extension or version compares those options.
- Monitoring. Watch vendor change notices and advisories for the plugins you run.
- Backups and rollback drills. Practice the return path once, so it works under pressure.
Do not over-pin
Pinning everything forever leaves known vulnerabilities in place. The aim is a deliberate delay, long enough to catch a bad release and short enough to receive fixes. Set a standard window, shorten it for security fixes, and write it down.
Add continuous monitoring
New advisories appear for plugins you already approved. A monitoring process that matches advisories to your inventory shows you which updates are urgent. The interactive demo below shows the idea for software dependencies.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory is matched to a component you already run, then compare that with how your team finds out about plugin issues today.
Safeguard's continuous monitoring, dependency scanning and policy gates apply this thinking to the software you build and ship.
Quick check
Is auto-update always a bad idea for plugins?
No. It speeds up security fixes. The point is to know who controls the update path and to add staging or approval for plugins with broad access.
What is the first thing to record for each plugin?
Who can publish a new version, and whether you can pause, pin or approve it. Without that, you cannot judge update risk.
Sources
- Deploy Office Add-ins in the Microsoft 365 admin center
- Security for Forge apps on the Atlassian Marketplace
- Detailed plugin guidelines, WordPress Developer Resources
- Extension runtime security, Visual Studio Code documentation
Last reviewed: 19 October 2026.
