← All posts
Compliance

The Reporting Platform Is Live. Do You Know What You're Reporting On?

Today, ENISA turned on the Single Reporting Platform (SRP), the actual online tool manufacturers now use to file Cyber Resilience Act vulnerability reports. This isn't a rule taking effect somewhere in the background. It's a live web application, and as of today, you're expected to know how to use it.

The mechanics are genuinely simpler than they could have been. You file once. The CSIRT (Computer Security Incident Response Team) where your company is based receives it, forwards it automatically to every other CSIRT in a country where your product is sold, and ENISA gets a copy at the same time. One submission, not twenty-seven.

The deadlines are the ones you'd expect by now: 24 hours for an early warning, 72 hours for a fuller notification, 14 days after a fix ships for the final report on an actively exploited vulnerability.

Here's what the platform doesn't solve. Filing is easy now. Knowing you need to file isn't. The SRP has no idea what's actually inside your product. It can't tell you whether this morning's CISA KEV (Known Exploited Vulnerabilities) entry names a library buried three directories deep in your vendored source. That question was always yours to answer. Today it matters more than any day before it, because now there's a live form asking for an answer you might not have.

If your team can't say, in minutes, whether an affected library shipped in a product from 2023, a simpler filing process doesn't help you much. The bottleneck was never the paperwork. It's visibility into what you actually ship.

That's the part bomwerk scan addresses: an accurate inventory of every C/C++ and multi-language dependency in your codebase, including the vendored copies and static archives a lockfile-only scanner won't see. It won't file your SRP report for you. It will tell you, quickly, whether you need to.


The platform went live today. Whether you can actually answer its first question, "are we affected," is still entirely up to you. Run a free scan of your repo and find out before a KEV entry forces the question.

Not sure what your current SBOM is missing? We'll assess one repository across its supported ecosystems, explain the evidence gaps, and go deeper on C/C++ where the build context allows.

Get a free scan of one repo