License watermarking explained

Every artifact MM CRA Toolkit generates (SBOM, DoC HTML, Compliance Bundle) is embedded with a 16-character fingerprint derived from your license key and site domain. This is an anti-piracy measure that makes leaked artifacts traceable back to the buyer they came from.

What the fingerprint is

A 16-character hexadecimal string. Specifically:

substr( sha256( license_key + '|' + lowercase(home_url) ), 0, 16 )

Examples (the exact value differs per install):

mmcra:license-fingerprint: ab12cd34ef567890

The home_url is normalized to its lowercased, untrailing-slashed form so HTTP vs HTTPS and trailing-slash variations produce the same fingerprint. The license key is the secret half of the input — the domain alone is publicly known.

Where it appears

Three places:

1. SBOM (metadata.properties[]) — a property entry { name: "mmcra:license-fingerprint", value: "..." } in the CycloneDX JSON
2. DoC HTML footer — a faint grey line at the bottom of every exported Declaration of Conformity, with the toolkit version and fingerprint
3. Compliance Bundle README — a License fingerprint: ... line in the markdown header of the bundle's manifest

The License page (CRA Toolkit → License) shows your current fingerprint so you know exactly what's embedded.

What it does NOT do

• It doesn't leak your license key. The SHA-256 hash is one-way; an attacker who sees only the fingerprint can't recover the key.
• It doesn't identify your site to anyone but us. We can map a fingerprint back to a license, but a random observer can't.
• It doesn't add a tracking pixel or any kind of network call. The fingerprint is computed locally at artifact generation time. No phone-home is involved.

What happens if a fingerprinted artifact leaks

If a watermarked SBOM or DoC shows up on a "nulled plugins" site or somewhere it shouldn't be:

1. We see the fingerprint in the leaked file
2. We look it up in our license database
3. We know which licensed customer's site generated that artifact

What we do with that information depends on the situation. The most common case is reaching out to the customer to ask whether they're aware their artifacts are public. Sometimes it's not malicious — a developer shared their plugin's SBOM on GitHub for transparency. Sometimes it is — a paid customer is reselling nulled copies. The fingerprint lets us tell the difference.

Why this exists

WordPress plugins are GPL by inheritance — anyone can legally redistribute the code. What they can't legally redistribute is your support, your update channel, or your customers. The watermark protects against the latter by giving us a forensic trail when artifacts leak.

We do NOT actively monitor the internet for leaked SBOMs. If you ask us to investigate a specific leak, we will. Otherwise, the fingerprint sits there doing nothing until someone notices a problem.

How to remove it

You can't — at least not through the toolkit's UI. If you have a genuine reason to ship an artifact without the watermark (e.g. a public-domain SBOM you want to publish without traceable provenance), edit the JSON directly:

jq 'del(.metadata.properties[] | select(.name == "mmcra:license-fingerprint"))' 
  input.cdx.json > output.cdx.json

This is allowed. We're not in the DRM business; the watermark is for our forensics, not for locking you out of your own files.

What we record server-side

Nothing about which fingerprints have been generated. The mapping fingerprint → license is computed on demand by re-hashing every active license key against the leaked domain. Until then, no server-side state exists.