A security advisory on a Wednesday
A popular plugin announces a serious vulnerability. The studio knows it has used that plugin, but on which sites? Some are in the management dashboard, some are not. Some are hosted by the studio, some by clients. A developer starts logging into sites one by one, and by the end of the day has checked most of them.
A week later the host announces it is retiring an older PHP version. Same question, same process. Then a client asks which of their three sites still use the old page builder. Same again.
Why nobody has the full picture
- Sites were built over many years, by different people, on different stacks.
- Only some sites are connected to a management tool, often the ones on maintenance plans.
- Sites hosted by clients or other providers are outside the studio's own servers.
- Information like PHP version, DNS host and page builder is scattered or unrecorded.
- Responsibility for each site is informal, so questions go to whoever remembers.
The studio knows each site well when it builds it, and less well every month after that.
What not knowing costs
Response to security issues is slow, which is exactly when speed matters. Developer time is spent logging into sites to answer simple questions. Some sites are missed entirely, and they are usually the ones most at risk. Clients who ask about their exposure get a slow or vague answer.
The site inventory we build
- Every client site you look after is listed, whether you host it or not, with client, plan and responsible developer.
- For sites you manage, platform, version, plugins, themes and PHP version are read regularly through your management tool or a small reporting plugin.
- For sites you do not manage directly, a public scan records what can be seen from outside.
- Hosting, DNS provider and mail setup are recorded from DNS lookups and your records.
- The inventory is searchable: which sites run this plugin, which are on this PHP version, which use this page builder, which are hosted with this provider.
- Public vulnerability feeds are matched against the inventory, and affected sites are flagged to their responsible developer automatically.
- Host announcements, such as PHP retirements, can be turned into a list of affected sites in one search.
| Question | Before | With the inventory |
|---|---|---|
| Which sites run this plugin? | Log into each site | One search |
| Which sites are on an old PHP version? | Ask the host, check each site | One filter |
| Who is responsible for this site? | Ask around | On the record |
| Are client-hosted sites affected? | Often unknown | Scanned and recorded |
| Which sites does this advisory affect? | Manual check | Flagged automatically |
The inventory also supports your other processes: update runs, maintenance reports, licence tracking and client offboarding all read from the same list.
The next advisory
A vulnerability is announced. The inventory matches it against every site straight away and flags the affected ones to their developers. Sites on maintenance plans are updated through the tested update routine. Clients on sites the studio does not maintain get a short, honest note that their site uses the affected plugin and what to do. The day continues as planned.
Could you answer these questions quickly?
- You cannot quickly list which client sites run a given plugin.
- Only some sites are in your management tool.
- PHP versions and hosts are not recorded for every site.
- Security advisories mean a day of logging into sites.
- Responsibility for each site is informal.