Require every plugin to ship an inventory of its libraries, scan it at submission and again when new advisories land, and set a clear fix window by severity. Block or flag plugins that miss it. The plugin code may be fine while an outdated bundled library is the real risk.
Why bundled libraries matter
A plugin is a package of someone else's code plus its own. Marketplaces already treat the dependency side as a policy matter.
The Visual Studio Marketplace documentation says that if a vulnerability is found in an extension dependency, the extension is removed from the Marketplace and added to the block list, and an installed copy is automatically uninstalled by VS Code. Atlassian's requirements say an app must not use third-party libraries with known critical or high vulnerabilities, must fix them as quickly as possible when discovered, and must not use end of life Node.js runtimes or unmaintained libraries. Mozilla's policies allow only release versions of third-party libraries and forbid modifying them.
Three checkpoints
| Checkpoint | What to run | What to do on a finding |
|---|---|---|
| Submission | Inventory plus vulnerability match | Reject or require a fix for critical items |
| Update | Same scan, plus diff versus last build | Flag newly added libraries |
| Ongoing | Re-match the installed base on new advisories | Notify partner, start the fix clock |
The ongoing check is the one teams skip. A plugin that passed in spring may carry a vulnerable library by autumn without any change to its code.
Steps to build the process
- Ask for an inventory. A software bill of materials in a standard format is best. Without one, build it yourself from the package.
- Match against advisory data and record the match with the plugin version.
- Add reachability context where you can. A vulnerable function that the plugin never calls is a different priority than one on a hot path. Treat it as a ranking aid, not a waiver.
- Set fix windows by severity and publish them.
- Notify the partner with the library, version and fixed version if one exists.
- Escalate with a warning, then a block, if the window passes.
- Track unmaintained libraries separately, because they never get a fixed version.
Common pitfalls
- Treating a dev dependency and a shipped dependency the same way. Only what ships matters to users.
- Trusting the lockfile in the repository and not the built bundle. The bundle is what customers run.
- Alerting without owners. Each plugin needs a named contact who can act.
- Forgetting transitive libraries, which are often where the vulnerable version hides.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a component and follow it to its parent. Notice how a library several levels down still shows up in the inventory, which is exactly where plugin risk tends to hide.
Quick check
Should a plugin be blocked for any vulnerable library?
Not for every finding. Block on critical or high issues that go unfixed past the window, and use warnings for lower severities.
Who owns the fix, the marketplace or the partner?
The partner owns the plugin and its libraries. The marketplace owns the policy, the detection and the enforcement.
Safeguard provides SBOM and dependency scanning, reachability analysis and policies that can gate a release, and autonomous remediation with fix PRs is available but off by default. The free scan shows a plugin's inventory in minutes.
Sources
- Extension runtime security, Visual Studio Code
- Security requirements for cloud apps, Atlassian
- Add-on Policies, Firefox Extension Workshop
Last reviewed: 19 October 2026.
