Search Results

With the rapid development of connected and autonomous vehicles, more sophisticated automotive systems running large portions of software and implementing a variety of communication interfaces are being developed. The ever-expanding codebase increases the risk for software vulnerabilities, while at the same time the large number of communication interfaces make the systems more susceptible to be targeted by attackers. As such, it is of utmost importance for automotive organizations to identify potential vulnerabilities early and continuously in the development lifecycle in an automated manner. In this paper, we suggest a practical approach for integrating fuzz testing into a Continuous Integration (CI) pipeline for automotive systems. As a first step, we have performed a Threat Analysis and Risk Assessment (TARA) of a general E/E architecture to identify high-risk interfaces and functions.

Automotive systems have become increasingly more complex, interconnected and prone to cyberattacks in recent years. With larger software bases and multiple external communication interfaces, the risks for new vulnerabilities and attack vectors on vehicles also increase. Therefore, modern cybersecurity validation is highly stressed for finding security vulnerabilities and robustness issues early and systematically at every stage of the product development process. The integration of a sophisticated fuzz testing program within the overall cybersecurity validation strategy allows for accommodating towards these challenging demands. In this paper, we review a general automotive cybersecurity engineering process containing functional testing, vulnerability scanning and penetration testing, and highlight shortcomings that can be complemented by fuzz testing.

In recent years, fuzz testing has established itself as a reliable and indispensable testing method for finding previously unknown and product specific vulnerabilities within the code base of automotive systems. As such, we see increased requirements for automotive products that call for fuzz testing per default. Based on the semidecidable characteristic for finding fuzz testing results, i.e., virtually an infinite test space, it is a non-trivial task to generate plausible evidence that sufficient fuzz testing has been applied to the target system. In this paper, starting from fuzz test result generation, we specify the individual steps necessary for preparing a sound evidence report. We describe how evidence is created in this context and which information is relevant. The traceability of fuzz testing product requirements is a driving factor thereby.