ISO/SAE 21434 is formally released – what automotive designers need to know

In the same way that ISO 26262 focuses on safety, ISO/SAE 21434 focuses on security. However, unlike ISO 26262 – which, although recommended is not mandatory – ISO/SAE 21434 will eventually become mandatory for all new vehicles in the future. This will provide product developers, OEMs, and their suppliers with greater peace of mind around security.

These days, even the most basic new car is likely to have multiple onboard software-dependent systems and vehicle connectivity, including Wi-Fi and Bluetooth. Wherever there is connectivity, there is a risk of security vulnerability. As many software vulnerabilities are introduced during the development stage, ensuring that software security is robust has never been so important. Current safety-critical standards are insufficient to cover these security risks, so new guidelines and standards are needed: hence the need for ISO/SAE 21434.

This new automotive software security standard covers every stage of a vehicle’s lifecycle, from design to decommissioning, by applying cybersecurity engineering to all electronic systems, components, software, and any external connectivity. Furthermore, ISO/SAE 21434 spans the entire supply chain, which is particularly important considering the growing volume of contributors in any automotive design project. 

ISO/SAE 21434 requires that due diligence cybersecurity engineering has been conducted and that cybersecurity management is applied throughout the supply chain. In addition, ISO/SAE 21434 intends that organisations encourage a cybersecurity-centric culture, placing security in mind from the very start of every project. This matters because, in the past, security has often been an afterthought in software development.

ISO/SAE 21434 in action

On a practical level, ISO/SAE 21434 requires analysis to check for inherent weaknesses and the overall consistency, correctness, and completeness of software development concerning cybersecurity. This applies to all design decisions, including the choice of programming language, with criteria including built-in secure design and coding techniques, unambiguous syntax, and semantic definitions. If the selected programming language does not meet these criteria, then those can be addressed in ways that deal with language deficiencies, including the use of language subsets, enforcement of strong typing, and defensive implementation techniques.

For example, programming languages such as C and C++ contain features that can lead to critical or unspecified behaviour, thus compromising security. Therefore, prohibiting such language constructs by using a language subset can overcome these deficiencies. This can be achieved by using a coding standard – MISRA C:2021 Revision 1 and CERT C Guidelines are provided as examples for secure coding in the C language for ISO/SAE 21434 environments as a language subset is the core of these guidelines. Similarly, MISRA C++, CERT C++, and Autosar C++14 provide a language subset for the C++ programming language.

For instance, MISRA C:2012 Revision 1 Rule 21.5 prevents the use of functions in <signal.h>, and Rule 21.21 the use of the function ‘system’. Similarly, CERT C Rule 11 Signals (SIG) prevents specific signal handlers, and ‘ENV33-C doesn’t call system’.

Strong typing ensures that there is an understanding of the language data types and so stops certain types of programming errors from occurring. The C language permits implicit type conversions which can be implementation defined. This can lead to loss of value, loss of precision, or loss of sign. For example, weak typing may cause an unsigned integer to be treated as signed which can lead to signed integer overflow – an undefined behaviour. MISRA C:2012 Revision 1 specifically enforces strong typing with its essential types, while CERT C implicitly addresses the topic via individual rules, such as INT32-C, which specifically guards against signed integer overflow.

Finally, defensive implementation techniques allow the software to continue functioning even under unforeseen circumstances because it requires thought about ‘what might happen’. One example could be preemptive consideration of the creation and impact of tainted data.

All cybersecurity defensive implementation techniques start with the use of recognized coding guidelines. Both MISRA C:2012 Revision 1 and CERT C achieve this by identifying critical and unspecified language behaviour, which makes the resulting code more reliable, less prone to errors, and easier to maintain.

Software security best practices

While security and coding standards go a long way toward preventing problems, some techniques and tools can further help automotive developers and others in the supply chain. At the very start, ensuring that all stakeholders and users are involved in selecting coding standards and tools will help improve ‘buy-in’. Likewise, ensuring that everyone is aware of the risks around insecure code and their roles in its mitigation help to engender a more ‘security-first’ mindset.

Code reviews are a popular collaborative process that is long-established in the software world and encourages higher quality and more consistent coding practices. In a small team, that might simply involve asking a colleague to inspect some code a developer has written. However, it is probably more practical in larger organisations to use automated code reviews, which can identify bottlenecks while avoiding the risk of subjective views.

A further technique that is already widely used in automotive software design is automated static code analysis, which inspects code for thousands of defects, errors, and vulnerabilities quickly and efficiently. In turn, this means that developers are not wasting valuable time ensuring adherence. Instead, they are confident that the code they are writing is compliant with both coding and industry standards, such as ISO/SAE 21434.

Furthermore, static code analysis tools can look at code across its lifecycle, from creation (pre-commit) onwards while being a part of Continuous Integration (CI) processes and the DevOps software production methodology. 

With the volume of code involved in vehicle design, the formal introduction of ISO/SAE 21434 has come at a critical time in the automotive industry’s evolution. Security will remain a substantial challenge, but together with the right techniques, tools, and coding standards, ISO/SAE 21434 can help to minimise the risks in a structured way. For any organisation involved in automotive software development, now is the time to learn more about and embrace ISO/SAE 21434.