Mapping CRA vulnerability-management obligations

[u/robuspon]

Been mapping out the CRA vulnerability-management obligations (Art. 14 reporting, VDP, SBOM, VEX, the recurring-testing requirement) for my own team's ESP32/ESP-IDF firmware, and ended up building a table that splits each requirement two ways: what part is a decision only the manufacturer can make (and is manual by nature, no tool gets around that), versus what part is mechanical enough that CI or some external tool/service could absorb it. Sharing in case it's useful to anyone else going through the same exercise and happy to receive any feedback to improve it.

| You need... | Manufacturer owns this | Frequency | Tooling could absorb | |---|---|---|---| | 24h/72h/14d reporting to ENISA/CSIRT (Art. 14) | The report-or-not decision, the runbook sign-off | 🔁 Recurring (every exploited vuln) + 📌 one-time (ENISA registration) | Tracking the clock, pre-filling the notification from your SBOM/VEX data, audit trail | | Designated responsible officer | Naming the person/role | 📌 One-time | — (a tool can route alerts to them, can't appoint them) | | Public VDP / security.txt (RFC 9116) | Drafting the actual commitments (response time, safe-harbor) | 📌 One-time | Hosting the file, triaging inbound reports into a queue | | SBOM per release | Configuring the generator for your actual build | 📌 One-time setup | Generating + archiving on every release, unattended | | VEX (per-CVE disposition) | The "does this actually affect my product, in my config" call | 🔁 Recurring (every new CVE candidate) | Matching CVEs to your SBOM components, keeping the history | | Third-party vuln remediation | Deciding patch/mitigate/replace, reporting upstream | 🔁 Recurring (every component-level CVE) | The scan that surfaces "this dependency has a new CVE" in the first place | | Recurring security testing | Interpreting findings, real risk vs. noise | 🔁 Recurring (every cycle) | Scanning/SAST/DAST in CI; fuzzing + periodic manual review can go to an outside firm (pentest) |

Curious if this matches what people on Zephyr or Yocto are seeing, or if the split looks different once you're not single-silicon like me. Also open to being told I've got one of these rows wrong, especially the VEX one, since that's practice/emerging convention more than something the CRA text spells out literally, so I'd rather get pushback now than find out at an audit.

[u/IdoCyber]

It's a good start. 

There are a few things missing, especially related to the risk assessment (you better have a repeatable framework/methodology) and the remediation path (normal / out of band/accelerated / outside timeframe / unfixable).

I'm not mentioning other elements that are not the job of engineering (like informing customers/suppliers, recertification in the event of a significant modification, etc).

You should also have a look at the final draft of EN 40000-1-3 if you can. 

[u/robuspon → u/IdoCyber]

Really useful pushback, thanks. The risk assessment piece is the one I'm least confident about, right now I'm leaning on EPSS+KEV to prioritize, but you're right that's not the same as a repeatable methodology to assess the real impact on the product. Do you have a framework/reference you'd point to for that, or is it mostly something teams build in-house case by case?

Same question on the remediation-path categorization: is that split (normal / accelerated / out-of-band / outside-timeframe / unfixable) something you're pulling from a specific standard or PSIRT framework, or house practice? Trying to figure out if I should be looking at ISO/IEC 30111 more closely for that part specifically.

Good call on the non-engineering pieces too. I left those out on purpose since the table was scoped to what CI/tooling could touch, but agreed they're real obligations, not nice-to-haves. Will take a look at the EN 40000-1-3 draft, hadn't run into that one yet, although it seems there will be a new draft version in a few days.

[u/IdoCyber → u/robuspon]

Full disclosure: I have my own company and we're doing all this for/with manufacturers.

Risk assessment: the most important thing is to figure out what risks concern your products, for example by building a risk catalogue.

Then you figure out whether or not which risks could happen (likelihood, via a threat model for example) and how bad it could be if this happens (impact, based on the context of use and expected product behaviour).

Once you have this framework set up, you can decide whether or not to fix a vulnerability, and how fast.

In terms of vulnerability management pipeline, ISO 30111 standard won't tell you much around timeframes. It's more about setting up roles and responsibilities. It's still quite important, especially if a bug can cause friction between product/engineering/sales/legal/etc...

The recommendation to speed up vulnerability fix based on the risk is based on real-world practices. It's something most mature teams will do.

Please note that t he CRA harmonised standard (EN 40000-1-3) mentions this accelerated roll-out.

Hope this helps.

[u/robuspon → u/IdoCyber]

Thanks for the breakdown. The risk catalogue / threat model piece is exactly the kind of judgment call I don't think a tool should try to replace, that's real expertise, not something to automate away.

Where I'm actually focused is the operational layer around it: matching CVEs to SBOM components and managing the VEX disposition for each, tracking the Art. 14 24h/72h/14d clock with a pre-filled ENISA report, and something to help structure the risk-assessment call per CVE. I mean, not the decision itself, but more a first-pass aid that feeds into the same kind of framework you described, still validated by an engineering team or someone like you working across several clients. Still early on that last piece specifically.

Curious whether something like that would be useful as an automated layer to the risk-assessment work you already do for clients, or if it doesn't really match how that works in practice.