Search for "CRA compliance software" and you'll find capable products from well-funded companies, a free open-source stack that does more than you'd expect, and consultancies offering to handle the whole thing. It's genuinely hard to compare them, because they aren't all doing the same job. So rather than rank them, this page maps them — and is honest about where our own tool fits, which is not everywhere.
How the market splits
The CRA is not one task. It's an inventory task, a vulnerability-assessment task, a reporting task, and a conformity task, strung across a product's whole life. Tools cluster around the parts they're good at, and the fastest way to make sense of the market is to ask, of any tool: where does it stop? The stopping point is where you'll need something else.
The four categories
The open-source floor
Generates SBOMs, scans for known vulnerabilities, and monitors continuously — for free. It genuinely satisfies the CRA's machine-readable-inventory requirement. Most teams start here, and they're right to.
Where it stops: at the inventory and a raw CVE list. No exploitation evidence, no reporting orchestration, no retained conformity evidence.
SBOM & SCA suites
Commercial platforms that do SBOM generation, correlation, licensing and policy at portfolio scale, with the portal and support an auditor-facing team wants. Some add static reachability. Strong, mature products.
Where it stops: they let a human annotate VEX; they don't prove exploitability. The applicability decision is still an assertion.
Consultancies & notified bodies
People, not software. They deliver CRA readiness as a service and, for higher-risk products, perform the conformity assessment the law requires. Essential for critical-class products.
Where it stops: they're a service engagement, not a continuous, evidence-producing system. Partners and referral channels — not really competitors.
The exploitation-evidence layer
Sits above the SBOM. Takes the inventory you already have, works out which component CVEs are genuinely reachable and exploitable in your product, and attaches the evidence — then feeds reporting and a retained evidence trail.
What it doesn't do: compete on SBOM generation. It consumes the SBOMs the tools above produce.
Capability matrix
Read this by row, not by column. Most rows are covered by more than one category — the one that isn't is the point.
| Capability | OSS floor | SBOM & SCA suites | ProvenVEX |
|---|---|---|---|
| SBOM generation | ● | ● | ● |
| Vulnerability correlation | ● | ● | ● |
| VEX annotation (record a status) | ◐ | ● | ● |
| Static reachability | ○ | ◐ | ● |
| Exploitation proof (evidence-backed VEX) | ○ | ○ | ● |
| 24 / 72 / 14 reporting orchestration | ○ | ◐ | ● |
| Immutable evidence trail & retention | ○ | ◐ | ● |
| Conformity & CE-marking support | ○ | ◐ | ● |
Category-level assessment, not a per-vendor scorecard — individual products vary, and the suites in particular are adding CRA features quickly. The one row that holds across the whole market is exploitation proof.
The dividing line: assertion vs. evidence
Strip away the feature lists and one distinction organises the entire market. Every tool that touches VEX lets you record a status — not_affected, affected, and so on. What almost none of them do is stand behind it. The status is a human's judgement, written into a file the tool exports.
Everyone can annotate a VEX file. The market divides on whether anything is behind the annotation.
That's not a knock on the suites — annotation is genuinely useful, and recording decisions cleanly is real work. But under the CRA, an asserted not_affected is exactly what a market-surveillance authority can question, and "our engineer judged it" is a weak answer. Backing the status with reachability and exploitation proof is the layer that turns a claim into a determination. It's the whole subject of evidence-backed VEX.
How to choose
Buy for your bottleneck, not for the longest feature list:
- You need a machine-readable inventory and nothing more yet. The open-source floor is enough and free. Don't pay for an SBOM.
- You manage many products and want portfolio SBOM, licensing and a polished portal. An SBOM/SCA suite earns its price. This is what they're built for.
- Your bottleneck is deciding — and proving — which CVEs actually matter for CRA reporting. That's the exploitation-evidence layer, and it's the part none of the above solve. It runs on top of whatever inventory tooling you already have.
- You have a critical-class product needing formal assessment. You'll need a notified body regardless; evidence tooling prepares the package they'll want.
As an alternative to…
The honest answer to "is ProvenVEX an alternative to X?" is usually "no — it's the layer above X." A few specifics:
- Dependency-Track / Syft / Grype. Keep them. They generate and monitor your SBOM for free; ProvenVEX consumes that output and adds exploitation evidence and reporting on top.
- FOSSA / Anchore. Strong at application-level SBOM and VEX annotation. ProvenVEX doesn't replace that inventory layer; it proves the exploitability that their VEX annotations assert.
- Snyk / Mend. Their static reachability flags whether a vulnerable library is called. ProvenVEX goes a level deeper — attempting exploitation to show whether it can actually be triggered in your product.
If you're specifically shopping for the tool that proves exploitability rather than asserting it, that's the category we're defining — and the one the matrix above says is otherwise empty.
Frequently asked
What is the best CRA compliance tool?
There isn't a single best tool, because the CRA spans several jobs. The OSS floor covers the inventory for free; the SBOM/SCA suites are strong at portfolio management and licensing; the part none solve is proving which CVEs are exploitable in your product, which decides your reporting load. Choose by which job is your bottleneck.
Is an SBOM tool enough for CRA compliance?
No. An SBOM meets the machine-readable-inventory requirement — table stakes, available free. The harder obligations (deciding which vulnerabilities affect you, reporting actively exploited ones, retaining defensible evidence) sit on top of the SBOM.
Do I need to replace my existing SBOM/SCA tool?
No. ProvenVEX consumes the SBOMs you already generate — with Syft, Trivy, cdxgen, FOSSA, Anchore or similar — and adds the exploitation-evidence, reporting and evidence-trail layer above them.
What's the difference between reachability and exploitation proof?
Static reachability flags whether a vulnerable library is called in your code. Exploitation proof goes deeper: it attempts to trigger the vulnerability in your product's context and captures the result, so a not_affected is backed by a demonstrated attempt rather than an inference.