Security is becoming a more important topic for developers of embedded systems – especially connected embedded systems and IoT (Internet of Things) devices – and nowhere is this more apparent than in industries like automotive software, where connected cars, telematic systems, IVI (In Vehicle Infotainment) systems and connectivity in general are all growing at an amazing pace.
For the automotive industry, the ISO/SAE 21434 standard is intended to address the growing concerns around security – of which there are many – for these new on-board connected devices.
Functional security and ISO 21434
ISO/SAE 21434: Road vehicles – Cybersecurity engineering, is, as the title suggests, intended to help address the challenges of cybersecurity for automotive vehicles, in much the same way as ISO 26262 has for functional safety.
Published in 2021, at a similar time to other standards – like IEC 81001-5-1 and IEC 62443 – for other embedded industries where security of connected systems is a growing concern, ISO 21434 recommends the use of secure coding guidelines to help developers produce more robust, more secure code from the ground up.
The growth of Java in automotive systems
As automotive IVI and central dashboard systems strive to reproduce the kinds of user interface and connectivity experiences that consumers are used to with their mobile phones and home entertainment systems, the need for operating systems like Android have grown rapidly. Today, almost all high-end IVI systems are based on the Android AOSP (Android Open Source Platform).
In its latest incarnations, the Android platform is made up of over 15 million lines of C and C++ code, but nearly 30 million lines of Java code, and growing. And, in order to develop customisations and extensions to the platform, it is necessary to add and modify code within both the C++ and Java code, modifications and additions, which need to be checked for security implications.
CERT Java
While ISO 21434, and standards like it, recommend the use of CERT C or MISRA C:2012 for the secure development of C code, there are no such recommendations for what to use for the Java programming language. So what should one choose?
CERT C and CERT C++ – curated and maintained by Carnegie Mellon University – are very much targeted to secure coding for the C and C++ languages, respectively, and so inevitably CERT Java seems like an obvious choice for the Java programming language.
The OWASP (Open Web Application Security Project) Top 10 coding standard, which is programming language agnostic, but generally does apply to web and mobile technology languages, like Java, is another option. However, as OWASP is more focused on the web and mobile application space, it perhaps adds less value to a more embedded software context that on-board automotive systems represent, and CERT Java provides for.
What does CERT Java require?
The CERT Java coding standard contains 19 top-level Rules – really Rule categories – which represent the main classes of security vulnerabilities, and each of which contain several specific sub-rules.
The top-level Rules categories are:
- 1. Rule 00. Input Validation and Data Sanitisation (IDS)
- 2. Rule 01. Declarations and Initialisation (DCL)
- 3. Rule 02. Expressions (EXP)
- 4. Rule 03. Numeric Types and Operations (NUM)
- 5. Rule 04. Characters and Strings (STR)
- 6. Rule 05. Object Orientation (OBJ)
- 7. Rule 06. Methods (MET)
- 8. Rule 07. Exceptional Behavior (ERR)
- 9. Rule 08. Visibility and Atomicity (VNA)
- 10. Rule 09. Locking (LCK)
- 11. Rule 10. Thread APIs (THI)
- 12. Rule 11. Thread Pools (TPS)
- 13. Rule 12. Thread-Safety Miscellaneous (TSM)
- 14. Rule 13. Input Output (FIO)
- 15. Rule 14. Serialisation (SER)
- 16. Rule 15. Platform Security (SEC)
- 17. Rule 16. Runtime Environment (ENV)
- 18. Rule 17. Java Native Interface (JNI)
- 19. Rule 49. Miscellaneous (MSC)
There are a total of 183 sub-rules across these 19 Rule categories.
Enforcing CERT Java coding rules
The easiest and most cost-efficient way to enforce any coding standard is via the use of static code analysis tools – or SAST (Static Application Security Test) tools as they are referred to in a security context – as they can automate the process of checking the source code against many hundreds of rules in a minimal amount of time.
There are currently very few tools on the market that are capable of enforcing the CERT Java coding standard.
One tool that is capable is the Understand by SciTools Codecheck tool, which currently provides coverage of all 19 CERT Java Rule categories, and over 60% coverage of the individual sub-rules.
Measure your CERT Java compliance with Understand by SciTools
Please contact us if you would like to have a free trial of Understand by SciTools to check your compliance level to CERT Java today!