A revolution is underway in the automotive industry. The car is no longer simply a means of getting from here to there. Today’s car reaches out for music streamed from the cloud, allows hands-free phone calls, and provides real-time traffic information and personalised roadside assistance.
Almost every modern automobile feature — speed monitoring, fuel efficiency tracking, anti-lock braking, traction and skid-control — is now digitised to provide drivers with easier, safer operation and better information.
>See also: The scariest vulnerabilities in driverless cars
Recent innovations enable automobiles to monitor and adjust their position on the highway, alerting drivers if they are drifting out of their lane, even automatically slowing down when they get too close to another car. And whether we’re ready or not, we’ll soon be sharing the roads with autonomous vehicles.
Built on a core of open source
Driving the technology revolution in the automotive industry is software, and that software is built on a core of open source. Open source use is pervasive across every industry vertical, including the automotive industry.
When it comes to software, every auto manufacturer wants to spend less time on what are becoming commodities—such as the core operating system and components connecting the various pieces together—and focus on features that will differentiate their brand. The open source model supports that objective by expediting every aspect of agile product development.
But just as lean manufacturing and ISO-9000 practices brought greater agility and quality to the automotive industry, visibility and control over open source will be essential to maintaining the security, license compliance, and code quality of automotive software applications and platforms.
The automotive supply chain makes tracking code difficult
When someone thinks of building software, we think of it being created by an internal development teams. But auto manufacturers rely on hundreds of independent vendors supplying hardware and software components to Tier 1 and 2 vendors as well as directly to OEMs.
>See also: The future of driverless cars and data security
The software from each of those vendors is likely a mix of custom code written by the vendor and third-party code (both proprietary and open source). With tens of millions of lines of code executing on as many as 100 microprocessor-based electronic control units (ECUs) networked throughout the car, understanding exactly which open source components are part of the mix can be extremely difficult for the OEMs. When you add in the fact that over 3,000 open source vulnerabilities are reported every year, the security implications are clear.
Fixing a vulnerability doesn’t always result in fixing the car
Let’s assume a Tier 2 vendor is using an open source component, and a vulnerability is disclosed.
• First the vendor needs to know they are using that specific open source component.
• Next they need to be monitoring sources in order to know about the newly reported vulnerability.
• Then they need to re-factor and test their code to remediate the issue.
When all this is done, the software update needs to go to the OEM or Tier 1 vendor, be incorporated into an update of that entity’s component and, ultimately, be updated in each consumer’s vehicle.
Updating presents its own challenges. When security researchers demonstrated in 2015 that they could hack a Jeep over the Internet to hijack its brakes and transmission, it posed a security risk serious enough that Chrysler “recalled” 1.4 million vehicles to fix the bug that enabled the attack. “Recall” is in quotes because Chrysler didn’t actually require owners to bring their vehicles to a dealer. Instead, they were sent a USB drive with a software update they could self-install. But how many owners are comfortable updating the software in their cars?
>See also: How cyber attackers will shift gear once connected cars hit the road
Vehicles can be updated during routine service, of course, but probably only if the service is provided by an authorised dealer, a prospect that decreases as a vehicle ages. Over-the-air updates of software are still the exception rather than the rule, and may require that the vehicle be stopped for safety reasons. After all, we probably don’t want a software reboot when a vehicle is moving at highway speed.
Product lifecycles present long-term maintenance challenges
Your cell phone may have a practical life of 2-3 years, but receives regular operating systems updates and perhaps hundreds of app updates each year. The laptop I’m using to write this likewise receives regular updates and patches, and will likely be replaced after 3-5 years. This is the typical lifecycle software vendors are used to addressing.
A modern car, however, is in design for years prior to production, and the average vehicle may be on the road for 10-15 years. Supporting software over that period of time requires a different thought process. Vendors (and open source communities) need to be considered in light of the operational risk they present. Questions vendors need to ask include:
How sure are you that the components you are using will be supported by the open source community in the future? Are you prepared to provide ongoing support for projects if the community (or vendor) abandons them? What does the release cycle look like? How many vulnerabilities has the component had over the last few years compared to the size of the code base? Is the community security-aware?
>See also: Everything you need to know about car hacking
When safety is a function of software, security becomes paramount
When a supplier or auto OEM is not aware all the open source in use in its products’ software, it can’t defend against attacks targeting vulnerabilities in those open source components. Any organisation leveraging connected car technology will need to examine the software eco-system it’s using to deliver those features, and account for open source identification and management in its security program.
Both auto OEMS and their suppliers should adopt management practices that inventories open source software; that maps software against known vulnerabilities as well as alerting to new security threats; that identifies potential licensing and code quality risks; and that can maximise the benefits of open source while effectively managing risks.
Sourced by Mike Pittenger, VP, Security Strategy, Black Duck Software
The UK’s largest conference for tech leadership, TechLeaders Summit, returns on 14 September with 40+ top execs signed up to speak about the challenges and opportunities surrounding the most disruptive innovations facing the enterprise today. Secure your place at this prestigious summit byregistering here
