Most teams cannot answer the question that decides whether a security advisory costs an afternoon or a week: which projects actually run the affected plugin. That gap is where the plugin inventory value lives, and it is also why your plugin list is a security asset rather than housekeeping. Once you know how to run a plugin list security audit, it stops being paperwork and becomes the step that scopes an incident in minutes. Below is how to know what plugins you have installed without asking anyone to remember, what that record is worth on the three days you actually need it, and the shortest way to keep it current.
What a plugin inventory is worth
The list itself carries almost no value on a quiet Tuesday. Its worth shows up under pressure, in four specific situations.
- Advisory response. A published vulnerability gets scoped by querying the list instead of grepping every repo and hoping.
- Duplicate discovery. Two plugins solving the same problem means two things to review and two sets of permissions granted for one job.
- Drift detection. The developer running a plugin nobody else has is either ahead of the team or has drifted, and both are worth a conversation.
- Offboarding and handovers. A written record survives the person who installed it.
None of this requires new tooling. It requires one file that is updated when something changes.
| Question you get asked | Without an inventory | With an inventory |
|---|---|---|
| Which projects use the affected plugin? | Grep every repo, then guess | One query |
| How many machines are exposed? | Unknown until someone answers in chat | A count, immediately |
| Did we ever install it? | Nobody remembers | In the record, with dates |
| What else came from the same author? | Another round of searching | Grouped and listed |
The three days the list pays for itself
Every team that keeps one hits these eventually, usually within a year.
- The advisory day. Something you installed is named publicly. With a list, answering is a query. Without one, it is a day of searching followed by an answer nobody fully trusts.
- The audit day. Someone asks for evidence of what runs in the build. The list is the evidence, and building it retroactively always takes longer than expected.
- The incident day. Something behaves oddly, and narrowing the suspects starts with knowing what is installed. The permission patterns behind bad installs are covered at /blog/how-install-script-scanning-works.
An inventory is not found security work. It is the part you do once so the other three days are not spent looking for the list.
Building one in an afternoon
This is a spreadsheet job. Do not wait for a platform decision.
- Export the installed plugin list from one machine and put it in a shared file with today's date.
- Add three columns per entry: version or commit, source (registry, repo, or local path), and date added.
- Repeat on each developer machine and each CI image. The CI column is the one people forget, and it often has the most restrictive permissions.
- Mark every entry that touches network access, credentials, or files outside the project directory.
- Put one person in charge of rerunning the export monthly. Rotation is where most inventories quietly die.
The scores attached to each entry do not need to be in the file. Link the plugin pages instead, because grades move and the file should not have to. The four inputs behind every grade are explained at /blog/dsh-quality-score-decoded.
Keeping it current without adding process
Inventories fail for the same reason most checklists fail: they ask people to remember. Attach the update to something that already happens.
- Regenerate the export when a machine is set up or wiped, not on a calendar nobody follows.
- Make adding a plugin require a line in the file, the same way adding a dependency requires a pull request. The allowlist write-up at /blog/setting-up-a-plugin-allowlist-for-your-dev-team covers this gate from the team side.
- Diff on update rather than trusted including by hand, so changes surface automatically.
- Keep the historical versions. A plugin that was fine two versions ago is relevant context when a new release is flagged.
FAQ
- Is a plugin inventory worth it for a solo developer? Yes, and the reason changes rather than disappears. For one person the value is mainly reinstall speed after a machine wipe, plus a record of what you grant permissions to.
- How often should it be refreshed? Whenever the set changes. A monthly regeneration catches drift; anything longer usually means the record has already gone stale.
- Do scores belong in the inventory? Reference them rather than copying them. Grades move with maintenance and publishing activity, and a frozen number in a spreadsheet becomes wrong quietly.
- What if we already have a dependency manifest? Keep both. A manifest covers packages your code imports; plugins run as tooling inside your editor or harness and usually are not in it.
- Does this replace scanning? No. The inventory tells you what to check; scanning tells you what it does. Independent scoring rather than self-reported claims is the subject of /blog/why-independent-plugin-scoring-beats-self-reported-ratings.
Start with one machine today and add the rest this week. Every plugin in your list has a score page on dshquality.com, and the scoring behind those pages is independent rather than self-reported. The review habit that keeps the list honest is described at /blog/dsh-plugin-review-process, and everything we publish is at /blog.