SBOMs for Evil: Turning Un-Remediated Software Supply Chain Documentation into an Attack Path

The talk opens with what a software bill of materials (SBOM) is: an inventory of the components, versions and dependencies inside a firmware image or application. The speaker explains how SBOMs are produced through source code analysis or binary analysis, compares the CycloneDX and SPDX formats, and shows how CPE matching links listed components to known CVEs. He also covers the regulatory pressure pushing vendors to supply SBOMs, including FDA submission requirements, US federal procurement rules and the EU Cyber Resilience Act.

The middle of the talk is a case study on OpenWrt, an open source Linux firmware widely used as the base of consumer IoT products. A binary analysis of an OpenWrt image produced more than 1,500 findings, with 10 critical and 38 high. One flagged component, the LuCI web interface, carried a 2019 CVE. Commercial threat intelligence feeds had no exploit data for it, so the speaker found a public proof of concept through community contacts and reviewed it. Shodan results suggested tens of thousands of internet-facing hosts with the same interface. OpenWrt's git-based version strings also failed to match the CPEs in the NVD. A live demo against an old OpenWrt virtual machine showed command execution and file creation, while the final shell step was not completed on stage.

The closing argument is that the same enriched inventory helps defenders decide which devices to patch, how to segment networks and what to monitor. VEX statements can document components whose vulnerable code is never reached. The speaker also warns that shared SBOMs tend to spread publicly, so organizations should assume adversaries can use them.