Embedded Code Review

The rise of security regulations is compelling embedded software developers to carry out automated security tests on their products prior to shipping them. Consequently, various industries and ISO standards advise integrating automated fuzz testing into the development process, particularly in sectors that already have high standards of quality and security. ISO/SAE 21434 and UNECE WP.29 (UN R155 and UN R156), both of which focus on the security of automotive software, are good examples.

Fuzzing has great advantages. Fuzzing is a type of dynamic code analysis. Dynamic code analysis relies on studying how the code behaves during execution, in opposition to static code analysis where the study is done without executing any of the code. This means the code is being tested with random, invalid, and unexpected inputs. By generating numerous automated test cases every second and tracking the path taken by the inputs through the code, a fuzzing tool can obtain comprehensive information on the code coverage combined with the specific inputs used during the execution of the code. Fuzzing enables high code coverage, efficiently. Fuzzing does not have false positives and it provides inputs that can use to reproduce the identified bugs, which can be used not only to improve the code but also as a training opportunity for the developer and test teams.

Despite all the advantages, fuzzing also has its limitations. Fuzzing requires expertise at various levels – from the selection of the tool to its set-up and interpretation of test results. Not all fuzzing tools are the same; most fuzzing tools are not equipped to fuzz embedded code, as they do not take the hardware that the code runs on into account. This is a severe limitation, as the hardware can have a meaningful impact on the execution of the code; as a result, fuzzers not hardware aware may not detect certain bugs. Embedded code fuzzers are more challenging to configure and operate, due to the interface with the hardware layer. Expertise is also required to prioritize which parts of the code to fuzz, to monitor and adapt the tests based on the coverage progression, and to analyze the impact of the test results. Fuzzers report a high number of results; developer teams need market knowledge and experience to prioritize which bugs have a higher security impact and therefore, should be fixed with urgency.

Fault injection (FI) is a security testing technique, which involves intentionally introducing flaws or faults into a system to evaluate its response. This method helps testers identify issues that might not be detectable through conventional testing approaches and evaluate the system’s capacity to handle errors and recover without crashing.

Fault injection testing is widely used in high-profile sectors such as payment and content protection, where strict security requirements are in place. In a typical fault injection attack, a device is manipulated to bypass its security mechanism, also known as ‘introducing a glitch.’ Fault injection is a hardware attack that exploits unsecure practices in software. Developers can employ Fault Injection testing to understand how their code will respond when confronted with a glitch, ideally allowing them to make design modifications before deploying their application into production.

Fault injection results are unpredictable and detecting them later in the design phase and or for certification or market acceptance (like type approval in automotive, or while the vehicle is already in the field) can be expensive, and impact the time-to-market. By simulating a code base for fault injection vulnerabilities, developers have the opportunity to identify them in an early stage and mitigate them.