An agency’s plugin provenance checklist
You did not choose most of the plugins you maintain, and you will still be the one answering for them. This is a routine that fits in an hour a month.
Written for the case where you carry ten to fifty client sites, inherited most of their plugins, and have no mandate to rip half of them out.
Once, per site
- List every plugin, with its slug and origin. Directory or premium. The split matters more than the count, because only one half has a public record to check.
- Record the listed author and the contributor usernames for every directory plugin. This is your baseline. Without it, later checks compare against nothing.
- Record the last release date. Anything past a year is already a candidate for replacement, whoever owns it.
- Mark the plugins that could not be removed without a conversation. Usually far fewer than the number installed.
This is the boring part and the part that makes everything after it possible. A provenance check with no baseline is just a description of today.
Monthly, per site
- Has any listed author changed?
- Has any username appeared in a commit log that was not there last month? This is the one that matters; see the method.
- Has anything dormant suddenly shipped? Quiet for a year, then a release, is worth five minutes.
- Has anything been removed from the directory? Closure is often a security action, and the plugin stays installed and working on the site regardless.
When something fires
A new committer is a question, not an incident. In order:
- Read the diff at that revision. Most of the time it is a version bump.
- Open the new username's WordPress.org profile. What else do they commit to, and since when?
- Check the changelog and support forum for an announced handover. Legitimate transfers are usually stated somewhere.
- Then decide: accept it and record that you did, hold updates on that plugin for a fortnight, or start planning a replacement.
Record the decision either way. The value of this routine is largely that you can show your working later.
Telling a client
Most of the time you should not. A legitimate transfer is not news, and an agency that reports every ownership change trains its clients to ignore them.
Say something when there is a decision for them to make: you want to replace a plugin they rely on, or you are holding updates on something that matters, or a plugin they paid for has been closed. Lead with what you are doing about it. "Plugin X changed hands, we have held its updates for two weeks while we watch it" is a sentence that builds confidence. "Plugin X changed hands" on its own just moves your anxiety to them.
What this routine does not cover
Being straight about the gaps, because they are real:
- Premium plugins. No public record, nothing to compare. They are not safer for being paid; the June 2026 ShapedPlugin compromise was a premium product whose own build pipeline was breached.
- A compromised maintainer account. If an attacker commits as the existing owner, no provenance signal moves at all.
- Malicious code from a legitimate owner. You are checking who, not what. That is what your scanner is for.
Provenance monitoring covers one layer. Run it beside vulnerability scanning and staged updates, not instead of either.
The honest problem with doing this across a fleet
Everything above is per site. Thirty client sites means thirty baselines and thirty monthly passes, and the routine's whole value depends on doing it consistently rather than when you remember.
That is the point at which people stop, and it is worth saying rather than pretending an hour a month scales linearly to thirty sites. If a single view across every site you manage is what you actually need, the honest answer today is that per-site tooling will not give you one.