“Security has to be mandatory for automotive software development”: Page 2 of 4

October 23, 2018 //By Christoph Hammerschmidt
“Security has to be mandatory for automotive software development”
In automotive electronics, there is no safety without security. But how can security be ensured with today's development methods - keywords are agile development, DevOps and massive use of Open Source software? Andreas Kuehlmann, Senior Vice President and General Manager of the Software Integrity Group at development tool provider Synopsys, has the answers to these questions.

Kuehlmann: Security is actually one of the big issues in Open Source. Today, you have about 100 million to 150 million lines of code in a car, many of them are based on Linux or its derivatives. So, the amount of Open Source is anywhere between 60% and north of 90%. A lot of this is taken from either the general distribution or from specialized distributions. Therefore, actually, Open Source is a key element to get a car software developed today. But then, at the same time, there are Open Source’s vulnerabilities. There are two types of vulnerabilities in the car. There are the ones what are called known vulnerabilities, and they typically come from Open Source. And then you have the unknowns. The unknowns are Zero-Day (exploits). Zero-Days is, for example, what Charlie Miller and Chris Valasek exploited that in their Jeep hack. The known vulnerabilities are really the ones that researchers look at in Open Source components, they find the vulnerability, publish them in a responsive disclosure process to the NVD (National Vulnerability Database), and essentially, they let everybody know that there is a vulnerability that needs to be fixed. So if you have Open Source components in your car, somebody finds a vulnerability, the hackers see the same announcement. They can essentially start exploiting, in fact, they very often exploit such a vulnerability, they search and find this on the Internet. This is a huge issue for automotive software development.

Smart2zero: But in a car, you have safety-relevant software and you have to follow the procedures prescribed by ISO 26262 and other Standards.

Kuehlmann: Right.

Smart2zero: And you have to have dozens institutionalized assessment processes. Wouldn’t you necessarily uncover any security threats before the software becomes integrated into the car?

Kuehlmann: This is ultimately the goal. There’s a whole number of standards for software that are addressing the safety issue. For example, ISO 26262. You probably are aware of the MISRA coding standard with its derivatives. These Standards, particularly MISRA, are mostly focused on code cleanliness, I wouldn’t even say heavily on quality, but think about having a well-structured code that is easily readable, and they are still important in automotive. But to you the new security standards. With ISO 26262, this discussion is extending into security. If you look at what we do at Synopsys - we are in the business of providing tools, services, and methodology for addressing quality as well as security in the development process. Meaning, you know, fix it while you are coding it, so that it doesn’t get released into the car. This is ultimately where the goals will go, because you have to address it at the root, and if not, then you have to fix it later and update it.


Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.