Open Source Risks in the Automotive Software Supply Chain

Most software components used in cars are not developed directly by the automakers themselves or even by top suppliers. Software comes from a wide range of suppliers and includes embedded GUI frameworks, middleware, operating systems, navigation and telecommunications software components, etc.

These source software components can be part of an in-dash infotainment system or an embedded system such as sensors used throughout the vehicle. This increasing complexity and interoperability has led to software collaboration between suppliers, resulting in a network of peer partners (e.g., Ford and Google, GM and Lyft).

Since automotive software components are created by many different vendors, a large portion of them contain open source. Like any software these days, open source is a fact of life. In fact, Android, a popular platform for automotive head units, is built on top of Linux. Other examples are Genivi Alliance and Automotive Grade Linux, open source platforms specifically for automotive applications.

Estimates put open source at around 50-70% of the automotive software stack in 2018. Another presentation in June 2021 put the figure at around 66%, regardless of whether open source was used directly or indirectly in other proprietary third-party components.

The productivity advantages of not "reinventing the wheel" are obvious. Free and open source software is often of good quality and provides significant benefits, especially when used for entire subsystems. However, security and quality vary depending on the source of the software. In most cases, you cannot be sure that the components you reuse are safe and of high quality, so steps must be taken to mitigate this risk.

Insecure versions of open source components are a common security vulnerability in automotive software. In some cases, the vulnerability has been identified and patched, but the components used in the vehicle have not yet been updated.

The lack of updates for open source components or those containing vulnerabilities is also a challenge for automakers. While patching software in cars can be difficult, ensuring the software supply chain also keeps up becomes a complex task. Sometimes updates don’t come because the author may not even be aware of the open source.

Hidden dependencies in open source components are another critical security concern. It is common for open source to rely on other dependencies to function. Dependencies increase the scope for security risks. Some of these dependencies are not documented or, if used in proprietary software, are completely hidden.

Finally, licensing is a potential minefield for automotive software. Open source is not necessarily free to use in commercial products, or if it is, redistribution in products may need to meet legal requirements. Devices that include third-party software are redistributing any source code or binaries used in them, which is a unique use case for open source. There are significant legal risks in not properly managing the licenses of all third-party source and binaries used.

Managing the risks of open source software

Just as a bill of materials (BOM) helps manage physical inventory in automotive production, managing the quality and security of purchased software starts with the software BOM – SBOM.

How does SBOM help manage risk?

Implementing a software supply chain risk management program and using an SBOM are critical to improving the safety posture of the end product. For automotive software development, this practice helps meet industry safety and compliance requirements.

SBOM management provides manufacturers with the following benefits:

Discovery: Identify open source components in third-party code and COTS/third-party software. Detect known (N-day) and unknown (zero-day) vulnerabilities in these components. This includes open source components hidden in binaries from tier-2 and tier-3 software providers.

Manage risk: Make smarter security decisions based on visibility into code/software. Adhere to security, licensing, and vendor risk compliance requirements.

Remediate: Protect against cybersecurity threats with actionable vulnerability intelligence. Simplify vulnerability remediation to reduce software risk.

The goal of automation software supply chain security is to gain deep visibility into the products purchased and deployed to support program objectives. SBOMs and detailed vulnerability information are needed to truly understand the security risks of existing software used in vehicles.

With new technology that can analyze binary applications without access to source code, product security teams can now generate their own detailed SBOMs along with high-level dashboards to help analyze and summarize findings. Additionally, software vulnerability reports are critical to cataloging known vulnerabilities in software components outlined in the SBOM.

Look for SBOM tools that can generate both human- and machine-readable outputs that can be exported and shared with other organizations and integrated with security and risk solutions. The human-readable format should provide easy navigation of components and reported vulnerabilities.

The automotive industry has always needed to remain vigilant regarding the quality, reliability, and safety of the physical components used in vehicles. As more and more software is integrated into their finished products, manufacturers can no longer “trust” that the embedded code in their products is free of security vulnerabilities and flaws. Software supply chain risk management must be a key pillar of vehicle quality control.