I tried to build a CRA evidence packet for a WordPress plugin release. Here's what was missing.

#cybersecurity #compliance #wordpress #sbom

I've spent the last few weeks researching the EU Cyber Resilience Act for a side project. 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.

Not legal advice — I'm a software engineer, not a lawyer. This is release hygiene that happens to overlap with what the CRA asks for.

I'm building Waybill to generate exactly this packet from a release workflow: SBOM per release, a versioned evidence archive, and vulnerability intake with real deadlines. Founding beta is $29/mo.

The full write-ups behind this post:

Question for the WordPress vendors here: if an enterprise customer emailed you today asking "what was in the version you shipped in March" — how long would it take you to answer with evidence, not memory?

DEV Community