We have frequently covered the topic of supply chain problems related to reference code when silicon vendors ship vulnerable code to the entire ecosystem. These vulnerabilities typically require a significant amount of time and effort to get fixed since they impact all the vendors that incorporate the vulnerable code into the firmware on their devices.

The Binarly security research team conducts a comprehensive analysis of the recent Intel and MSI source code leaks to model the potential impact.

Over the past two years, attacks on multiple targets in the semiconductor industry have consistently led to leaks of firmware source code. A compromised developer device could potentially give an attacker access to the source code repository, adding a major gap in the security of the software supply chain.

The Binarly security research team continues to find evidence of repeatable failures in the firmware development ecosystem, exposing critical vulnerabilities related to the ecosystem that impact the entire industry rather than just a single vendor.

The Binarly team is constantly researching ways to automate our proprietary deep code inspection technology to improve the discovery of different classes of bugs within system firmware. The Binarly efiXplorer team has decades of experience in program analysis and automation, enabling us to develop unique binary analysis techniques and technologies internally.

The increasingly large number of firmware vulnerabilities gives attackers a lot of options for persistence and the means to bypass traditional endpoint solutions. At least two recently discovered firmware implants -- MoonBounce and CosmicStrand -- have persisted for more than seven years by using basic firmware bootkit techniques. In general, the UEFI system firmware grows in complexity every year and constantly introduces new attack surfaces.

Speculative execution mitigations have been discussed for some time, but most of the focus has been at the operating system level in order to adopt them in software stacks. What is happening at the firmware level? When it comes to applying these mitigations, how does the industry take advantage of them, and who coordinates their adoption specifically into the firmware? These are all good questions, but unfortunately no positive news can be shared.