While the increasing dependency on software in modern vehicle design is a gateway to incredible innovation, it also brings risks, particularly as vehicles become more connected with traffic infrastructure and other systems. Therefore, more rigor is needed around creating secure and high-quality code, because most software vulnerabilities stem from the development stage, which an attacker could exploit at a future time.
For instance, a vulnerability could enable the attacker to control steering, disable brakes or access personal information on other connected devices through the vehicle’s operating systems. Examples of vulnerabilities include memory buffer problems, which can lead to the software being read from or written to locations outside the boundaries of the memory buffer, and code injections, which affect the interpreted environment and most typically impact infotainment and other in-vehicle systems.
In addition, there is an increased use of the Android Open Source Project (AOSP) for development, particularly for infotainment systems. This increased use has massive benefits, giving developers access to a rich set of resources, but can also introduce risks. The 25-30 million lines of code involved add complexity, especially across many communication interfaces, so the potential attack surface is vast. Furthermore, the open-source nature of AOSP means that vulnerabilities are public knowledge, and, as the code is contributed by different developers, not all of them will have considered security (as it has not been a major concern previously). Also, users need to be aware of and use the latest version of a piece of open-source software, which will include fixes of known vulnerabilities.
Other factors affecting security include the trend toward electronic control unit (ECU) consolidation, which, by reducing their number within a vehicle, makes it harder to isolate potential issues. Plus, there is the sheer pressure on software engineering teams to contribute to faster time-to-market, and hence the potential risk of cutting corners.
Taking action
Not that the industry is putting its head in the sand on security. As Perforce’s 2022 State of Automotive Software Development survey of over 600 automotive industry professionals worldwide found, security is one of their top three concerns (alongside safety and quality). Furthermore, the 2021 introduction of ISO 21434, intended to ensure consideration of cybersecurity throughout automotive product development, demonstrates the commitment to security risk mitigation.
Fortunately, well-trodden best practices, already well-established within the automotive sector or in other industries, can all help to mitigate these risks – in particular, the use of coding standards, which is on the rise within the automotive sector as it is a requirement for both ISO 26262 and ISO 21434 compliance.
Coding standards are sets of guidelines or rules to help software developers create safe and secure code. In the same survey, 86% of respondents used at least one coding standard in their software development. Organizations may use a combination of coding standards (including those built in-house) to cover different programming languages and compliance requirements. Widely used coding standards include MISRA C/C++, well-known by and created within the automotive industry, and CERT, developed by the Software Engineering Institute at Carnegie Mellon University.
Compliance with a coding standard requires both time and effort, so static analysis tools are increasingly applied as a way to automate the process of enforcement. These tools inspect all categories of code and binaries without the need to execute them. The aim is to detect vulnerabilities and coding standards violations as early as possible in the development lifecycle, to reduce costs and prevent additional workload downstream. Trends such as ‘Shift Left’ testing, whereby testing takes place earlier (and throughout) the software development lifecycle, is part of this general movement.
Security-first mindset
Consideration of security in all phases of the software development lifecycle represents a significant change in the traditional software development environment. A ‘security-first’ mindset is encouraged throughout the organization, whereby everyone has a better understanding not just of security risks but their role in managing them.
Part of the security process must be to continually consider known and new vulnerabilities which may affect the software. There is a wide array of publicly available resources providing updates, including Common Weakness Enumeration (CWE), maintained by Mitre, which covers vulnerabilities in both software (for various languages and systems) and hardware. Similarly, the Open Web Application Security Project (OWASP) lists the 10 most critical security concerns for web application security. Another helpful resource is the National Vulnerability Database (NVD) from NIST, which lists recently reported open-source software (OSS) vulnerabilities together with a severity and a cross reference to CWE vulnerability types.
For example, the well-publicized Heartbleed bug from 2014 was a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows an attacker to read the memory of the systems ‘protected’ by the vulnerable versions of the OpenSSL software, which is widely used for encrypted communication; including between connected embedded systems (found widely in modern and future-facing cars). The Heartbleed bug made it possible for attackers to compromise the secret codes used to identify the service providers, and to encrypt the information being passed. Consequently, attackers had access to the names and passwords of the users which enable them to eavesdrop on communications.
As a result, the Heartbleed bug was registered as CVE-2014-0160 by Mitre and associated with the ‘CWE-126: Buffer Over-read’ vulnerability type. Development of code that is resistant to — or checked for instances of potential buffer overreads — will obviously mitigate this type of risk.
So, while security remains a significant challenge for the automotive industry, there are multiple techniques, cultural steps and freely available resources on which to draw. And, while security is not just the responsibility of developers, doing as much as possible to improve software as it is being created is a sound starting point.
