"Never trust inputs" - Building more secure automotive software

Automotive IQ interviewed Adrian Fluckiger, Major Account Executive also at Rogue Wave Software, about today’s challenges and pitfalls for software developers in the automotive industry. What can be done to deliver more secure, compliant and defect-free software?

Developers in the automotive software supply chain are spending more time and effort -- and consequently money - on the latter stages of development to get the product ready. These developers need to deliver code with less defects, applications secure from hacking vulnerabilities, and products that conform to critical safety and security standards. Navigating the day-to-day issues of automotive software development can be overwhelming, but with little effort it can be easily managed.

Where you see Rogue Wave positioned in the market, and what are your ties to the automotive industry?

We have a long history of supporting embedded software development, with tools and libraries that help to eliminate defects, reduce security risks, and cut software development cycle times. We also help our users to ensure compliance with a number of automotive standards, including MISRA and ISO26262.

How would you describe your own software supply chain model?

If you look specifically at the automotive space, we work closely with a lot of the OEMs and Tier 1 software development managers to ensure the security of the applications that they’re building and the reliability of those applications. We help them with open source software Management within those applications.

We have Tier 1 manufacturers who have seen a 25% reduction in the amount of time that their software development teams are spending on identifying security and reliability defects and addressing those issues. Our solutions enable the developers to find and fix those issues themselves, prior to checking their code. That same supplier also had a situation where they weren’t aware of what open source software they were using throughout all of the components that they were building. We’ve now enabled them to build up a catalogue of all the open source software that they’re using, they have an understanding of what open source software licences they’re using. They’ve been able to set up internal policies to guide software developers on what packages they can use. Moving forward, this enables the team to have a better idea of what their software is, if it is secure, if they are in compliance with the licensing, and if the software is reliable.

Learn more about this topic and join the free Webinar:

"Forging a more secure software automotive supply chain".

Let’s talk portfolio. What kind of solutions are you offering?

When it comes to today’s discussion, the products that are having the biggest impacts on our customers are Klocwork, which is our static code analysis tool, and OpenLogic, which is our open source management solution. These tools have helped many of our customers find security risks, reduce defects and achieve standards compliance before their products are released in the field. By analysing the code as early as possible in the life cycle, the developers have the time and knowledge they need to get issues addressed and fixed faster. We’ve all seen the curve that shows that something found in the field is going to cost hundreds or thousands of times more than would to find it and fix it while writing the code, and that’s what we’re looking into – move to where you’re finding and addressing these issues as early as possible in the development cycle.

When you talk to customers, what are usually the most important demands and requirements?

We are seeing that a lot of the OEMs are demanding that the code they receive from Tier 1 and Tier 2 manufacturers is reliable and secure. Many of those OEMs are also looking for the Tier 1 and Tier 2 vendors to ensure that they’re following specific standards like MISRA when developing their software. We also see a lot of open source software used, and all the manufacturers are looking for a way to easily understand what open source software they’re using. That means complying with the licensing associated with that open source, whether the open source they’re using has any security flaws, and whether it’s reliable as well. Those are all major challenges that we see with the market right now.

What are your experiences with industry safety standards such as MISRA or ISO2626?

There are a lot of organisations that use a specific solution that’s just going to provide them with a checkmark for a specific compliance, such as MISRA. What we’re able to do with our tools, is provide that checkbox, but also look at building the security and reliability testing into the process as well. So, you can ensure that you’re compliant with the standards that you’re coding towards, and you’re also building the security and reliability into the solution. Again, because you are providing all of that information to the developers, when you look at it from a project standpoint, you’ve got great visibility through reports on the security and reliability of the solutions that you’re building. You can see if you are compliant with those standards that you’re following, but you’re also enabling the developers to now have access to that same information so that they can take action against it at the earliest point in the development lifecycle. That’s where we see ourselves in that compliance role.

The demand for connected devices and the growth of the "Internet of Things" often outpaces the ability of manufactures to deliver safe and secure code. How do you approach this development, do you follow a certain philosophy?

Our philosophy is really this: You want to enable your development teams to use solutions that are going to help to build security, reliability, and compliance into the software that you’re developing, from the ground up. When those issues are addressed later in the software development cycle, it is too difficult to ensure that you have solid security and reliability coverage, and it’s time consuming and very costly as well. When you look specifically at the Internet of Things, the biggest challenge that we see there is that the complexity and size of the systems that are being built are far outpacing the ability of development teams to test them effectively. That’s why bringing automated tools to the developers to help them fit into agile processes is critical to ensuring that safe, reliable products are getting into field on time without affecting the release schedules.

What is most critical in the development of software systems from a manufacturer’s perspective?

Alot of that automotive development is done with root privileges. So, one of the first steps that all manufacturers can take is building security and reliability into their development process, so they can enable developers to find and fix those critical security issues at the developers’ desktop as they’re writing the code. Development teams can also take advantage of lessons learned in many other industries, specifically if you look at industry security standards like the CWE, and OWAST. Most importantly, you really want to make sure that you’re educating developers on good security practices. A mantra like "never trust inputs" is a great philosophy to take when it comes to building in security from the ground up.

Given the fact that the tiniest software flaw may lead to dramatic consequences, potentially with lives on the line, where do you see the biggest software development challenges for OEMs and suppliers?

One of the main challenges for us as an organisation is getting the message out to as many organisations as possible so that they can fully understand the risks involved with software flaws. It’s not that the people who are living this every day don’t know that. If you’re looking at where you can have the biggest impact on software security and reliability, with the lowest cost, then Rogue Wave should definitely be part of the discussion.

Where do you see the top 3 priorities for a more secure and reliable software?

Number one is definitely security and reliability of software throughout the automotive supply chain. Number two would be the standards coverage, to meet OEM, and eventually we are going to see more regulatory requirements, I’m sure, in this space. And 3 would be the open source software solutions. These help organisations understand what open source software is being used today, whether or not it’s secure, details on the licensing around the governance of that open source software use, and the ability to build internal policies around the use of open source software for the organisation.

Thank you, Adrian.

This Interview is based on a Podast with Adrian Fluckiger. Listen to the full conversation here!