Dragon Core LTDDragonCore
All guides

Compliance

How to generate an SBOM for a WordPress site (CycloneDX and SPDX)

What a Software Bill of Materials is, why clients now ask WordPress teams for one, what it should contain, and how to export one in CycloneDX or SPDX format.

4 min readUpdated

What an SBOM is

A Software Bill of Materials is a machine-readable list of the components a piece of software is made of: names, versions, suppliers, licences, and identifiers that let a tool match each component against vulnerability databases. It is the ingredients label for software.

Governments and large buyers started requiring SBOMs after a run of supply-chain incidents where nobody could answer "are we running the affected component?" quickly. The EU Cyber Resilience Act makes an SBOM part of a manufacturer's technical documentation, and procurement questionnaires from enterprise customers increasingly ask for one up front. See the CRA checklist for WordPress for the wider picture.

Why WordPress sites get asked

A WordPress site is assembled from dozens of independently maintained components: core, plugins, themes, the PHP runtime, the database server. Each has its own release cadence and its own vulnerability history. That is exactly the situation an SBOM exists to describe. If you run sites for clients in regulated sectors, or you sell a plugin, someone will ask.

What a WordPress SBOM should contain

For each component:

  • Name and version: "WooCommerce 9.8.1", not "the shop plugin".
  • Type: application, library, framework. Plugins and themes are usually recorded as libraries of the WordPress application.
  • Supplier or author, and the licence (GPL-2.0-or-later for most of the ecosystem).
  • An identifier other tools can match on. A Package URL such as pkg:wordpress/plugin/woocommerce@9.8.1 is the useful one for vulnerability matching.

Plus the environment: WordPress core version, PHP version, the database engine and version, and the web server if you know it. The environment is where a lot of real-world exposure lives, and a bill that omits it is half a bill.

What it should not contain: anything about your users, your content, or your configuration. An SBOM describes software, not data.

Formats

  • CycloneDX (OWASP) is the format most security tooling and most buyers ask for. JSON, compact, designed for vulnerability matching. Version 1.6 is current.
  • SPDX (Linux Foundation, ISO/IEC 5962) is the older standard with a stronger licence-compliance heritage. Some public-sector and open-source-programme-office requests specify it.

If you are asked for "an SBOM" with no format named, send CycloneDX JSON. If you can produce both from the same inventory, do.

Generating one with Dragon Compliance

  1. Install Dragon Compliance and open Tools, then Compliance, then Inventory and SBOM. The inventory is built from your installed core, plugins and themes and the server environment. Nothing is uploaded anywhere: the inventory is built and stays on your server.
  2. Press Export SBOM. You get a CycloneDX 1.6 JSON file named by date, ready to attach to a questionnaire.
  3. Record the export. The Evidence tab logs it with a timestamp, which is the "we produced one on this date" proof auditors want.

Inventory and SBOM: every component on the site, exported as CycloneDX in one click.
Inventory and SBOM: every component on the site, exported as CycloneDX in one click.

Dragon Compliance Pro adds SPDX 2.3 export, and snapshots: every inventory export is kept, and two can be diffed to show what changed between dates. That diff is what you send when a client asks "what changed since the last one".

A CycloneDX component, trimmed, looks like this:

json
{
  "type": "library",
  "name": "woocommerce",
  "version": "9.8.1",
  "supplier": { "name": "Automattic" },
  "licenses": [{ "license": { "id": "GPL-3.0-or-later" } }],
  "purl": "pkg:wordpress/plugin/woocommerce@9.8.1"
}

Keeping it current

An SBOM is a snapshot. It is wrong the moment you update a plugin. Two habits keep it useful:

  • Export on a schedule (monthly is common) and after any significant change, and keep the files.
  • Match it against vulnerabilities continuously rather than only at export time. Dragon Compliance's daily scan does this against the Wordfence Intelligence feed, using a local copy so your plugin list never leaves the site.

Findings: known vulnerabilities in installed components, matched to CVEs with severity and status.
Findings: known vulnerabilities in installed components, matched to CVEs with severity and status.

Where to keep it and who to give it to

Store SBOMs with your other compliance records, outside the site itself, so a compromised or reinstalled site does not take the history with it. Share them on request with clients and auditors. Do not publish them on the site: a public, dated list of exactly which plugin versions you run is a gift to an attacker.

Common questions

Does it include the code, or private data? No. Names, versions, licences and identifiers only.

Do inactive plugins count? Yes. Inactive code is still on the server and still exploitable through direct file access in some cases. Include it, and consider removing it.

What about must-use plugins and drop-ins? They are software you run. A good inventory includes them.

Is one SBOM enough for a multisite network? One per network is normal, since plugins and themes are shared. Note which sites have which plugins active if the buyer asks.

Keep reading