Is open source software a cyber security risk in connected vehicles?

Open source software features in connected vehicles bring added responsibilities for manufacturers.

In the same way that original equipment manufacturers (OEMs) are responsible for issuing a recall for a malfunctioning piece of hardware they, along with their suppliers, will be responsible for software vulnerabilities in connected cars over the course of a vehicle’s lifetime.

  

Automotive manufacturers across the globe have been developing ways to address cybersecurity when building their connected cars. In the UK, government officials have released key principles that manufacturers must follow if they have any influence on the manufacturing supply chain.

But, auto manufacturers rely on hundreds of independent vendors to supply them with hardware and software components. Software from each vendor is likely to be a mix of custom code written by the vendor, along with proprietary code and open source software code. With tens of millions of lines of code networked throughout the car, OEMs are finding it increasingly difficult to track and manage the source for each piece of software in use.

With cybersecurity incidents continuing to rise, vehicle manufacturers need to adopt a cybersecurity approach that addresses not only obvious exposures in their car’s software but also the hidden vulnerabilities that could be introduced by open source software components.

Open source software core

The use of open source software for application development continues to grow every year. According to a Forrester report, open source is used in all industries by organisations of all sizes. The reasons are straightforward – open source lowers development costs, speeds time-to-market, and accelerates innovation.

Specific to the automotive industry, Black Duck’s COSRI Centre for Open Source Research and Innovation Group found open-source components in over 20% of automotive applications scanned for its 2017 Open Source Security and Risk Analysis report.

Open source enters in-vehicle applications through a variety of paths.

Automobile manufacturers rely on a wide range of component and application suppliers who build solutions with open source components and extend open source platforms. Open source is neither more, nor less, secure than custom code. However, there are certain characteristics of open source that make vulnerabilities in popular components very attractive targets for hackers.

Open source is widely used in virtually all forms of commercial and internal applications. For hackers, the return on investment for open source vulnerability is high. A single exploit can be used to compromise hundreds of thousands of applications and websites.

Open source software safety & security issues

While connected cars offer abundant opportunities for the automobile industry, automakers and their suppliers need to consider what the connected car means for consumer privacy and security.

For example:

  • When security researchers demonstrated 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
  • For nearly half a decade, millions of GM cars and trucks were vulnerable to a remote exploit that was capable of everything from tracking vehicles to engaging their brakes at high speed to disabling brakes altogether
  • The Tesla Model S’s infotainment system contained a four-year-old vulnerability that could potentially let an attacker conduct a fully remote hack to start the car or cut the motor.

Many automakers and their software suppliers deploy testing tools, such as static and dynamic application security testing (SAST and DAST) tools, to identify coding errors that may result in security issues. While both SAST and DAST are effective in spotting bugs in code written by internal developers, they are not effective in identifying open source vulnerabilities in third-party code, leaving major components of today’s applications exposed.

Since 2004, more than 74,000 vulnerabilities have been disclosed by the National Vulnerability Database (NVD), but only 13 of those were found by SAST and DAST tools.

When a supplier or auto OEM is not aware of all the open source software in use in its products, it can’t defend against attacks targeting vulnerabilities in those open source components. If your organisation plans to leverage connected car technology, you need to examine the software eco-system you’re using to deliver those features, and account for open source identification and management in your security programme.

Long-term maintenance challenges

On average, a cell phone or personal computer has a life of three to five years before replacement, with software updates pushed out to users on a regular basis. Vehicles are designed to be on the road for a much longer period, as much as 10 to 15 years. The need to support software for that amount of time presents a unique challenge for software security.

When presented with a piece of software that includes open source components, OEMs need to ask the following questions of internal teams or external vendors:

  • Will the open source components you’re using 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?

Open source licenses & compliance risks

Open source software security risk is top of the mind for many organisations because of highly-publicised exploits such as the Apache Struts 2 vulnerability which brought thousands of attacks against organisations worldwide, including the infamous Equifax breach.

However, it is also important to recognise the importance of license compliance as part of open source risk.

Most open source components are governed by one of about 2,500 known open source licenses, many with obligations and varying levels of restriction. These license requirements can only be managed and complied with if the open source components governed by those licenses are identified. Failure to comply with open source licenses can put businesses at risk of litigation and compromise of IP.

Even so-called ‘permissive”’ open source licenses typically require acknowledgement of use and other obligations such as redistribution and documentation requirements. And open source components with no identifiable license terms can be also problematic. Software that does not have a license generally means no one has permission from the creator(s) of the software to use, modify, or share the software.

Lack of clear statements of rights and obligations leaves organisations using that open source at greater risk of violation of ‘hidden’ terms. Best practices in the use of open source software require developers to understand which components and associated licenses are in their code and what obligations may result from their use of open source.

However, managing open source use manually can be a Sisyphean task, as Black Duck’s 2017 Centre for Open Source Research and Innovation (COSR) report demonstrated. Audited applications contained 147 open source components on average — a daunting number of license obligations to keep track of — and 85% of audited applications contained components with license conflicts.

The most common challenges were GPL license violations, with 75% of applications containing components under the GPL family of licenses, but only 45% of those applications were in compliance with GPL obligations.

Managing open source risks across the supply chain

As auto OEMs work with software providers, a growing set of open source components is making its way into automobile systems. The open source code is being channelled through countless supply chains in almost every part of the automotive ecosystem.

To make progress in defending against open source software security threats and compliance risks, both auto OEMs and their suppliers must adopt open source management practices that:

  • Fully inventory open source software: A full and accurate inventory (bill of materials) of the open source used in their applications is essential
  • Map open source to known security vulnerabilities: OEMs need to reference public sources to identify which of the open source components they use are vulnerable
  • Identify license and quality risks: Failure to comply with open source licenses can put organisations at significant risk of litigation and compromise of IP
  • Enforce open source risk policies As software development becomes more automated, so too must management of open source policies
  • Alert on new security threats: With more than 3,600 new open source vulnerabilities discovered every year, organisations need to continuously monitor for new threats as long as their applications remain in service.

By integrating risk management processes and automated solutions into their software supply chain, automakers, suppliers, and technology companies servicing the automotive industry can maximise the benefits of open source use while effectively managing its risks.

Written by Patrick Carey, vice president of product strategy, Black Duck Software


Courtesy of Software Testing News

Leave a Reply