CRA Evidence Desk

Match your SBOM against an advisory export, see exactly which components are named, and download a dated record plus an Article 14 review draft. Nothing leaves your device — your SBOM is never uploaded.

Article 14's reporting duty starts 11 September 2026 — for products already on the EU market, not only new releases. This page does not tell you whether it applies to you; it helps you find the matches and draft the notification quickly once you decide it does.

What this does not check

• Version ranges. An advisory saying "below 1.4.2" is reported as not evaluated, never resolved.
• Reachability and exploitability. A matched component may not be reachable in your build at all.
• Aliases and renames. A package published under two names matches only under the one your SBOM states.
• Advisories you did not export. Coverage is exactly the file you supplied, on the day you ran it.
• Whether an obligation applies. Severity, actively-exploited status and reporting deadlines are yours to determine.

Review every finding against the authoritative advisory with a qualified professional before you rely on it.

Questions

When do CRA Article 14 reporting obligations start?

11 September 2026, under Article 14(1) and (3): a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident in a product with digital elements already on the EU market must notify ENISA — an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days (actively exploited vulnerability) or one month (severe incident) after the 72-hour notification. It applies to products already on the market, not only new releases. This tool does not determine whether an obligation applies to your situation; it helps you find the matching components and draft the notification once you or a qualified professional decide it does.

What SBOM formats does this accept?

CycloneDX JSON (what npm sbom, syft, cdxgen and trivy emit), SPDX JSON, and a plain component list of the form {"components": [{"ecosystem", "name", "version"}]}. Package URLs are read where present, so an npm scope, a Maven group and a Go module path all resolve to the coordinates an advisory names them by. Nested CycloneDX sub-components are walked too.

Why does it only match exact versions?

Because resolving a version range is a judgement about your product, not a lookup. An advisory saying "all versions below 1.4.2" requires deciding how your ecosystem orders versions, whether a backport applies, and whether the vulnerable path is reachable in your build. This tool refuses to make that call on your behalf and instead names every range-only advisory in the report so you review it yourself. That refusal is the point: an exact match is evidence, an inferred one is an opinion.

Does a match mean I have to file a CRA notification?

No. A match means one component in your SBOM has the same name, ecosystem and version as an entry in the advisory export you supplied. Whether it is exploitable in your product, whether it is an actively exploited vulnerability or a severe incident under Article 14, and whether a reporting deadline applies are all determinations for you and a qualified professional. The tool produces a draft to review, never a filing.

Is my SBOM uploaded anywhere?

No. The files are read by your own browser and nothing is transmitted. There is no server, no account, and no upload step — you can disconnect from the network and the tool still works. This matters more than usual here: an SBOM is a complete map of your product's dependencies, and an advisory match list is a map of its exposure.

What does a clean report actually prove?

Only that no component in the SBOM you supplied exactly matched an entry in the advisory export you supplied, on the day you ran it. It is not a vulnerability scan, not conformity assessment, and not coverage of advisories you did not export. If part of your export stated versions as ranges, the report says so explicitly, because a clean result read without that caveat would look like far more assurance than it is.

My SBOM and my advisory export spell packages differently. Now what?

That is the normal case, not a broken export — the two formats name the same registry two ways, and this tool folds them onto one spelling before matching. Why don't my SBOM and advisory package names match? walks through where the mismatches come from and which ones can be resolved without guessing.

How is this different from OWASP Dependency-Track?

Dependency-Track is a continuous, self-hosted SBOM-analysis server; this is a free, one-shot page with nothing to deploy. See CRA Evidence Desk vs. OWASP Dependency-Track for the full comparison.

Can't I just match my SBOM to the advisory list by eye?

For a handful of components, yes. It stops being reliable once ecosystem names are spelled two different ways across the two files, a component is nested rather than top-level, or an advisory names a version range instead of a list. See CRA Evidence Desk vs. matching an SBOM to advisories by hand for where a manual read breaks down.