In brief: The CRA’s mandatory SBOM requirement is producing a barely manageable flood of CVE reports, which practical studies show can be reduced by up to 90 percent through VEX-supported reachability analyses.
The EU Cyber Resilience Act obliges manufacturers of digital products to create a software bill of materials (SBOM), which in practice leads to a volume of automated vulnerability reports that can hardly be managed manually anymore. The Vulnerability Exploitability eXchange (VEX) is intended to help filter out the actually relevant risks from this flood.
The Cyber Resilience Act (CRA) requires manufacturers of digital products to maintain a Software Bill of Materials (SBOM) as part of the technical documentation. At minimum, the top-level dependencies of a product must be listed; a complete enumeration of all transitive dependencies in full depth is not strictly mandated, though many companies still aim for it. A similar, considerably narrower regulation already exists in the US: Executive Order 14028 requires an SBOM from software vendors selling to US federal agencies – a pure procurement rule in the context of public acquisition, not a market-wide obligation like the CRA. In both cases, the SBOM is documented in machine-readable formats such as CycloneDX or SPDX and lists third-party components as well as open-source libraries.
Once SBOMs are created across the board, the original transparency problem turns into an overload problem: automated matching against vulnerability databases such as the National Vulnerability Database or the GitHub Advisory Database generates hundreds to thousands of alerts with every build, as soon as a scanner finds a package with an associated CVE entry – regardless of whether the vulnerability is actually relevant to the specific product. Classic scanners merely check whether a flawed component is present on disk, but not whether the vulnerable code is actually loaded, executed, or reachable over the network during operation.
For CISOs, this creates a concrete prioritization problem: manually reviewing every single CVE report ties up personnel capacity that most security teams simply do not have. Case studies on reachability-based analyses, for instance in projects such as Prometheus, show reduction rates of 90 percent or more when pure version matches are replaced by genuine reachability analysis. This suggests that a large proportion of the vulnerabilities reported in an SBOM cannot actually be exploited in the specific deployment context at all.
As a countermeasure to the sheer flood of CVEs, the Vulnerability Exploitability eXchange (VEX) serves as a format with which manufacturers document the exploitability status of a vulnerability for a specific product – for example, whether a reported flaw is actually affected, not affected, or already mitigated through compensating measures. For security leaders, the practical benefit lies in enriching scan results with VEX data, thereby significantly reducing the number of reports that actually need to be worked on, instead of processing every CVE in isolation and without context.
Source: www.it-daily.net · Published August 3, 2026
Lumi AI News — AI-assisted curation in accordance with Art. 50 EU AI Act. Paraphrasing and classification by Lumi News Pipeline v1.8.3.