Record, for every installed plugin, its ID, version, publisher, declared permissions, install date and who installed it. Update the record on every change. When a plugin turns out to be bad, that table answers the first question: who is affected right now.
Why you need it before the incident
Marketplaces can remove a plugin and add it to a block list, as the Visual Studio Marketplace describes, and Chrome can disable one after an unresolved violation. Those actions depend on the host knowing what is installed. Your own product faces the same need, and so do your customers' administrators. VS Code's enterprise controls, for instance, let admins allow or block by publisher, plugin and version, which only works if they can see what exists.
Fields worth capturing
| Field | Why |
|---|---|
| Plugin ID and name | Unique identity |
| Publisher and verification state | Who to contact, how much to trust |
| Version | Targets version level blocks |
| Declared permissions and domains | Judges blast radius |
| Bundled libraries (SBOM reference) | Matches new advisories |
| Install source and date | Spots sideloaded copies |
| Installed by and scope | Names the owner |
| Last update seen | Finds stale copies |
Steps to build it
- Collect from the host. Report installed plugins from the product itself, not only from the marketplace.
- Include sideloaded and private plugins. Installs from files or private feeds are often the ones nobody reviewed.
- Attach the manifest and a library list at install time.
- Normalize versions so the same plugin appears once with many installs.
- Re-check on a schedule and on new advisories, comparing the inventory to the latest data.
- Expose it to customer admins in the UI and by API.
- Test with a question. Pick a plugin and ask: how many tenants run version 2.1, and who installed it? If it takes more than a minute, fix the gap.
Common gaps
- Counting only marketplace installs and missing sideloads.
- Recording the plugin but not its permissions, so you cannot size the risk.
- Keeping the data in a spreadsheet that no one updates.
- Forgetting plugins bundled by other plugins as dependencies.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tied to assets and owners. A plugin inventory is useful for the same reason: every issue lands on a named item with someone responsible.
Quick check
Is the marketplace's install count enough?
No. It misses sideloaded copies, private feeds and offline installs, and it says nothing about the permissions or versions in your customers' environments.
How fresh should the inventory be?
Fresh enough to act during an incident. Reporting on every change plus a regular full sync keeps it current without heavy load.
Safeguard's asset discovery and SBOM features are built for this kind of inventory, and continuous monitoring ties new advisories to what you run. The free scan is a first look.
Sources
- Extension runtime security, Visual Studio Code
- Manage extensions in enterprise environments, Visual Studio Code
- Chrome Web Store review process
Last reviewed: 19 October 2026.
