A WordPress site SBOM should list WordPress core, every plugin and theme, must-use plugins, drop-ins and any Composer or JavaScript libraries, each with a name, version and source. A plugin list alone is incomplete, because several kinds of code sit outside the normal Plugins screen.
The layers to include
| Layer | How to collect it | Notes |
|---|---|---|
| Core | The installed version, checked against WordPress.org with the core checksum command | One entry per site |
| Plugins | The WP-CLI list command with JSON output | Include inactive ones until deleted |
| Themes | The matching theme list command | Include parent and child themes |
| Must-use plugins | The list command with the must-use status | No update notices, so list carefully |
| Drop-ins | The list command with the dropin status | For example object-cache.php |
| Composer packages | The composer.lock file | Includes transitive packages |
| Front end libraries | package-lock.json or similar | Only if shipped to production |
The WP-CLI handbook confirms the list command reports status values including active, active-network, inactive, must-use and dropin, and optional fields including version and title.
Fields worth recording
For each component: name, version, supplier or author, source (WordPress.org, vendor, custom, Composer), license where known, install status, and the date you last checked. The Plugin Handbook header fields include License and Version, which you can read from the main plugin file.
How to build it
- Export core, plugin, theme, must-use and drop-in lists for each site.
- Add the Composer lock file if the project uses one.
- Merge into one CycloneDX or SPDX document, or a clean spreadsheet if a formal format is not required.
- Store it with the date and the site name.
- Refresh on every deploy or at least weekly.
What it will miss
Libraries bundled inside a plugin's own folder often do not appear in any manifest. Premium plugins may not give you a changelog. Be honest about gaps in the document itself, with a notes column such as bundled code not enumerated. Our post on what an agency can ask a SaaS supplier for in an SBOM covers asking suppliers.
Who uses it
Clients ask for them in questionnaires, insurers ask about inventories, and your own team needs one the day an advisory lands. See why agencies keep a software inventory.
Where Safeguard fits
Safeguard produces SBOMs and scans dependencies for Composer and other ecosystems, and you can try a free scan at gold.safeguard.sh/scan. Plugin folders without a manifest still need the WP-CLI export above.
Try it yourself
Click through it at your own pace, or open it full screen. See how components, versions and licenses appear in a single inventory.
Keeping it honest
An SBOM that claims completeness it does not have is worse than a partial one. Add a short scope note at the top: which layers were collected, which were not, and how the data was gathered. When a client or insurer reads it, they see what it covers and what to ask next. When an advisory lands, your team knows where to look beyond the document, such as plugin folders with bundled libraries.
Quick check
Do I need a formal SBOM format?
Not always. A consistent table is useful, and CycloneDX or SPDX helps when a client or tool expects one.
Should inactive plugins be listed?
Yes, until they are deleted, since their files are still on the server.
Sources
- wp plugin list, WP-CLI handbook
- wp core verify-checksums, WP-CLI handbook
- Header Requirements, Plugin Handbook
Last reviewed: 19 October 2026.
