Source Code Analysis: A False Sense of Firmware Security

The Truth About Source Code Analyzers 

Welcome to a World of False Positives

Source code analysis produces a large amount of “false positive” results, which is one of the biggest complaints we hear against source code analyzers. Development teams spend significant amounts of time filtering out what’s real and what’s not real. This is colossal waste of time for the development team. And it can eat away at team morale.

Time Matters with Firmware Security Vulnerabilities

As IoT devices become favorite targets for exploitation by hackers and nation-state actors, time is of the essence when it comes to firmware security analysis. Source code analysis tools reveal vulnerabilities only when you re-scan the source code. 

Supply Chain Risk? Not My Problem

Supply chain vendors may supply you with object code, compiled binaries, or even kernel modules to include in your final build process. In these cases, they are not supplying you the actual source code. Therefore, your source code analysis tools are useless in determining what accidental vulnerabilities were introduced into your final product by your supply chain.

So What’s the Answer?

By all means, continue to leverage your source code analyzers. They most certainly have their place within the development process. But be aware of the limitations you and your team will face when processing the results. And also realize that you are not receiving full protection against supply chain risk with source code analyzers.

You need to augment your development process with binary emulation.

Binary Emulation Weeds Out False Positives

You can significantly reduce the number of false positives by leveraging binary emulation. The result is more development time and less false positive triage time by the development team. Here’s how the process works: 

1. Perform a traditional static binary analysis
2. Filter those results by function calls where the external inputs can be modified by outside sources (users, network traffic, etc.)
3. Track those external inputs in an emulated environment and log their effect within the binary
4. Report only those findings where the external inputs have a detrimental impact on the binary

If the external inputs can be modified by outside sources and those modified values have a detrimental impact on the binary, then you need to fix those issues immediately. This pattern is indicative of a potential zero-day vulnerability waiting to be discovered.

Binary emulation of compiled firmware addresses the false positive issue by reporting only actionable issues that pose serious security threats. The development team can quickly solve these issues when compared to source code analyzer issues. This saves enormous amounts of time.

Even if your supply chain vendors fail to provide you their source code for analysis, binary emulation will reveal supply chain risks before they become your problem.

Size Matters

In most cases, automated reverse engineering of a traditional firmware image takes a few minutes. But it depends on the size of the firmware image, of course. A typical 100MB–200MB compiled firmware image might take about 30-minutes or so. The larger the image, the longer it takes.

Real-Time Continuous Monitoring

Imagine a world where you don’t need to update databases or re-scan source code to find new vulnerabilities after a release cycle, yet you still receive near real-time threat intelligence about new vulnerabilities.

Continuous monitoring examines your compiled firmware image you maintain in your account. As new vulnerabilities are discovered and reported, all the firmware images in your account are automatically re-scanned to determine if any of the images in your account are vulnerable. If there’s a hit, you’re notified immediately so you can formulate a response plan with your development team. Can your source code analyzer do that?

In Conclusion…

Just remember, you should augment your source code analysis with binary emulation to achieve a more complete security analysis of your firmware before it goes into production. Then follow-up that security snapshot with some real-time continuous monitoring so you’re never caught off guard again.