Zahra Khani, Principal Product Manager, Keysight Technologies
Most manufacturers preparing for the Cyber Resilience Act generate SBOMs from source repositories or build pipelines, and then assume that document describes the product they placed on the market. In embedded and firmware-heavy products, it frequently doesn’t: statically linked libraries, vendored code, third-party binary blobs, bootloaders, and toolchain-injected components never appear in a manifest-based SBOM, while listed components sometimes never make it into the shipped image at all.
This talk examines why that gap matters legally, not just technically. The CRA’s Annex I SBOM requirement is the easy part; Article 14’s vulnerability-handling obligations are where build-time SBOMs break down, because those obligations attach to every firmware version still running on in-support devices, not just your latest release. Drawing on real analyses of shipped firmware (including cases where independent binary analysis surfaced components, and in a few cases malware, that the official SBOM missed entirely), we’ll walk through: how to verify an SBOM against the actual binary artefact; how to structure per-version SBOM and VEX lifecycles so your monitoring obligation survives your release cadence; and how reachability-informed VEX keeps your ENISA reporting and customer communications honest without drowning your PSIRT in false positives.
Attendees leave with a practical checklist for auditing their own SBOM pipeline against what they actually ship.
Conference partners
Organiser
