I've spent the last few weeks researching the EU Cyber Resilience Act. The notification duties (Article 14) have applied since 11 September 2026 — weeks ago — so I wanted to see what "ready" actually looks like for a typical small commercial WordPress plugin vendor.

I took a composite release — call it FormsPro 4.3.1, a $99/year form-builder plugin with ~20,000 installs, sold from the vendor's own site. It's a composite of several real plugins, so nobody gets singled out. Then I tried to assemble the evidence packet: the set of artifacts that answers "what did you ship, what was in it, and what did you know, when?"

What I could find — the good news first

  • A version number and a real changelog. 4.3.1 even documents a security fix ("Fixed: validation bypass on file uploads"). Good.
  • The release zip, downloadable from the vendor site.
  • A public GitHub repo with a matching tag.

That's further than most get. Now the gaps — and these are the ones the CRA cares about.

1. Which commit built that zip?

The tag exists. But is the downloadable zip byte-identical to a CI build from that tag, or was it zipped on someone's laptop on a Friday afternoon? There is no build record: no commit hash, no build ID, no builder identity, no timestamp. If a regulator — or an enterprise customer — asks "prove this zip came from that source," the answer is trust me.

2. No SBOM tied to the release

There's a composer.json in the repo, which tells you what the developer intended to depend on. It doesn't tell you what shipped in the zip six months from now: the bundled libraries, the exact versions, the minified JS pulled from npm. The CRA (Annex I) asks for an inventory per product, and the only inventory that matters in an incident is the one tied to the artifact customers actually installed.

3. The security fix has no awareness timestamp

4.3.1 fixed a validation bypass. Was it actively exploited? If yes, the 24-hour early-notification duty — enforceable right now — started ticking at the moment of awareness, not at the moment of full understanding. Is there a timestamped record of when the report came in, who triaged it, and what was decided? I found a changelog line. A changelog line is not an intake record.

4. No scan output, no dispositions

Did anyone scan 4.3.1 before shipping? When a scanner flags a dependency next month, the question won't be "is there a CVE." It'll be: was it a false positive, unreachable code, mitigated, or missed — and who decided that, when? No owner, no rationale, no deadline. A scanner finding without a decision trail is just anxiety with a dashboard.

5. No stated support window

How long is 4.3.1 supported with security fixes? The CRA expects the support period to be stated outright. "We support the latest version" is the industry default — and it's exactly what the regulation is pushing vendors away from.

What the packet should look like

This is the whole thing:

formspro-4.3.1/
  release.json        # version, commit sha, build id, builder, timestamp
  sbom.cdx.json       # CycloneDX SBOM generated against the final zip
  changelog.md
  vuln-intake.log     # every report, timestamped, with triage decision
  scan-results/       # scanner output + per-finding disposition
  support-window.txt  # "4.3.x receives security fixes until 2027-06"

No compliance department, no law firm. About two hours of release hygiene, most of it automatable inside the release workflow. And it's the difference between answering "what was in the March release?" in ten minutes versus two weeks of git archaeology in the middle of an incident.

The Friday 17:20 test still applies: exploit report lands, maintainer's asleep, two versions in the wild. The teams that survive aren't the ones with the best incident response playbook — they're the ones who did this boring work beforehand.

If you ship a WordPress plugin: when a customer asks "what was in the version from March," can you answer with evidence, not memory? Send me a line or two about what would break first; I'm collecting practical lessons from small vendors, no call needed. And if you'd rather automate the evidence side, the founding beta is open: https://getwaybill.io/founding-beta.

Sources

Further reading