The technology industry is in the midst of active discussions about the use of “software bill of materials” (SBOMs) to address supply chain security risks. In order to implement supply chain security practices, there must be better transparency on software dependencies. Previously, any piece of software shipped as black-box without providing any information related to software dependencies and third-party components. Firmware has largely been looked at the same way. In an earlier blog post, Binarly team discussed the multiple levels of complexity in the UEFI firmware ecosystem and supply chain taxonomy (The Firmware Supply-Chain Security Is Broken: Can We Fix It?).

At the beginning of December, Binarly was very active in spreading the word about the problems in the firmware supply chain ecosystem at multiple security conferences. Alex Matrosov, the Binarly CEO, gave a keynote entitled “The Evolution of Threat Actors: Firmware is the Next Frontier” at AVAR conference in which he focused on the evolving threats coming from historically overlooked places below the operating system.

Currently, integrity checking is the standard methodology for firmware security validation and threat detection. This article details the different scenarios where firmware integrity is necessary, but insufficient from the threat analysis and incident response perspective.