From SBOM to CRA Realities: Turning Component Inventories into “Critical + Actively Exploited”

This talk shows a realistic, engineering-first path from “we have an SBOM” to meeting the operational intent of CRA Articles 13 and 14: (1) continuously understanding cybersecurity risk in the product’s actual software composition, and (2) reliably spotting and escalating actively exploited issues for fast reporting and response. We’ll start with the hard part most teams hit immediately: component identification. Using the identifiers already common in SBOM ecosystems (e.g., package URLs, CPEs where applicable, hashes, supplier/namespace metadata), we’ll cover how matching works in the real world, and how to improve match confidence without pretending perfect data exists.

From there, we’ll move “through the prism of aggregation”: enriching SBOM components with vulnerability and exploit intelligence from multiple sources (public vulnerability databases, open-source vulnerability feeds, vendor advisories/CSAF, VEX assertions, and actively-exploited signals). The key outcome is a repeatable method to classify what is critical for you (reachable/impactful in your context, not just high CVSS), and what is actively exploited now(actionable, time-bound, report-worthy).

This session is part of SBOM Focus