Practical solutions for a secure automotive software development process following ISO/SAE 21434

The final draft international standard (FDIS) of ISO/SAE 21434 “Road vehicles – cybersecurity engineering” was released in May of this year, with the final version expected to be released a few months later. This standard specifies various engineering requirements and recommendations for cyber security risk management in the concept, product development, production, operation, maintenance, and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces. It’s worth noting that while ISO/SAE FDIS 21434 provides a more holistic view of cyber security, including descriptions of multiple cyber security requirements, activities, and work products on both organizational and project levels, this article focuses on practical cyber security solutions for a secure software development process. More specifically, the focus is on application security (AppSec) testing solutions to address the factors that lead to weaknesses and vulnerabilities in automotive system software. According to an automotive security survey, these factors include coding mistakes, lack of testing, and use of vulnerable open source software (OSS) components.

Figure 1: Solutions aligned to the V-model and relevant clauses in ISO/SAE FDIS 21434

Integration and verification activities

Regarding coding, requirement [RQ-10-09] in ISO/SAE FDIS 21434 states that integration and verification activities shall verify that the implementation and integration of components fulfill the defined cyber security specifications. Requirement [RQ-10-10] specifies that static analysis can be used as a verification activity for requirement [RQ-10-09]. Moreover, requirement [RQ-10-05] states that coding guidelines shall be used when cyber security is not sufficiently addressed by the programming language itself. Automated static analysis tools, such as Coverity®, can analyze source code without executing the software, which means that manual activities to define any test cases can be avoided. These tools can help find buffer overflows, resource leaks, memory corruption, and other defects in the code. In addition, static analysis tools can check the software against relevant coding guidelines, e.g., MISRA C/C++, AUTOSAR C++, and CERT C/C++.

Component testing

Regarding testing, recommendation [RC-10-12] states that component testing should be performed to confirm that unidentified weaknesses and vulnerabilities remaining in the component are minimized. Moreover, requirement [RQ-11-01] states that penetration testing can be used as a validation activity to demonstrate the appropriateness and achievement of cyber security goals. There are several test methods that can be applied to perform this type of testing, including vulnerability scanning, fuzz testing, and penetration testing.

Vulnerability scanning uses knowledge of known vulnerabilities or attack patterns to identify vulnerabilities in the target system. For example, software composition analysis tools, such as Black Duck®, can detect known vulnerabilities in OSS components in the target system. This automated scanning of source code or binaries identifies the open source components, their respective versions, and associated known vulnerabilities.

While vulnerability scanning tools typically use a database of known vulnerabilities or attack patterns, fuzz testing goes further to identify unknown vulnerabilities by generating malformed input that is then provided to the target system. Fuzz testing tools, such as Defensics®, can identify unknown vulnerabilities in various protocol implementations including CAN, CAN-FD, Automotive Ethernet, Wi-Fi, and Bluetooth, as well as in upper-layer protocols such as ISO-TP, UDS, DoIP, gPTP, IP, TCP, HFP, A2DP, and more.

Vulnerability scanning and fuzz testing can be performed using automated tools. Conversely, penetration testing typically involves manual activities to try to break certain security goals of the target system.

Organizations also need to continuously monitor for new threats and vulnerabilities both during development and after the product has been released. Requirement [RQ-08-01] states that internal and external sources can be monitored to collect cyber security information. Software composition analysis tools like Black Duck can provide alerts on newly identified vulnerabilities in OSS components as part of ongoing cyber security activities.

Make the most of your tools using automation

It’s imperative to recognize that these tools by themselves are not as useful as automating them as part of the continuous integration (CI) pipeline in the software development process. Automotive organizations need to establish appropriate processes for static analysis, vulnerability scanning, fuzz testing, and cyber security monitoring, and consider approaches for deploying automated AppSec tools. This includes determining which tools to use, what to test, what test environments are required, and how often testing should occur. Further, to ensure the efficiency and effectiveness of the tools, automotive organizations should consider integrating application security testing tools into the CI pipeline with other tools, including source code management systems, automation servers, build systems, and bug tracking systems.

Automotive organizations can also consider automation platforms, such as Code Dx, to execute application security tools, correlate results, and help prioritize vulnerabilities, as well as provide centralized risk visibility into what was tested, when was it tested, what was found, and what was fixed.