Keep a register with one row per plugin, extension or marketplace app, and give each row one named owner: a person who knows why it is installed and decides when to update or remove it. Without an owner, closure notices, advisories and access reviews have nobody to land on.
Why owners matter
Plugins accumulate. Someone installs a browser extension for a project, a CMS plugin for a campaign, a chat app for a pilot. Years later nobody remembers why. When the marketplace closes a plugin or an advisory lands, the question "whose is this?" has no answer, and the time to respond doubles.
An owner is not a security person. It is the business or technical user who benefits from the plugin. Security supports with the process.
Register fields
| Field | Why it matters |
|---|---|
| Name and ecosystem | Browser, editor, CMS, SaaS marketplace |
| Version at approval and current version | Detects drift |
| Publisher | Who to contact, and a way to spot changes of control |
| Purpose | A one line reason it exists |
| Owner and backup owner | Someone to decide and someone to cover leave |
| Data and permissions | The scopes, folders, mailboxes or tokens it holds |
| Install source | Marketplace, direct upload, vendor server |
| Approval date, approver, evidence | Audit trail |
| Update mode | Automatic, manual, pinned |
| Next review date | Keeps the entry alive |
| Exit note | Replacement and revocation steps |
You can build this in a spreadsheet. The goal is that the fields exist, not that you buy tooling.
How to fill it in the first time
- Export what the platforms know. Admin consoles list installed apps and extensions. Our guides on auditing installed editor extensions and browser extensions in your asset inventory show where to look.
- Assign provisional owners. Use the installer or the team that uses it. Ask them to confirm.
- Challenge the orphans. Anything with no owner and no clear purpose is a removal candidate.
- Record data and permissions. Pull scopes from the platform where you can. For Teams and Google Workspace, admin consoles show what apps can reach.
- Set review dates. Higher access means shorter intervals.
Keeping it current
- Tie it to onboarding and offboarding. When an owner leaves, reassign their entries. See offboarding checklist for identity and secrets.
- Tie it to approval. A new plugin does not go live until a row exists.
- Review quarterly. Delete rows for removed plugins and flag ones with no recent activity.
- Use the register during incidents. When an ecosystem announces a problem, search the register first.
Software dependencies belong in the same habit
Libraries your developers import carry the same ownership problem at larger scale. The demo below shows how a dependency inventory shows what you run.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and look at how many components appear that nobody chose on purpose. Then think about who would own each one.
Safeguard's asset discovery and SBOM generation produce that inventory for the software you build, and a free scan at gold.safeguard.sh/scan shows a first view.
Quick check
Should the owner be someone in security?
No. Pick the person who uses or requested the plugin. Security provides the review process and keeps the register standard.
What do I do with plugins nobody owns?
Ask who uses them. If nobody does, remove them after a short notice period and record the removal.
Last reviewed: 19 October 2026.
