Open Source Risk in the Automotive Software Supply Chain
October 05, 2022
Most software components used in automobiles are not developed directly by car manufacturers themselves or even their top-tier suppliers. Software comes from a wide range of vendors, including embedded GUI frameworks, middleware, operating systems, navigation, and telecom software components, among many others.
These sourced software components can be part of the dashboard infotainment system or embedded systems such as sensors used throughout the vehicle. This rising complexity and interoperability have led to software collaboration among suppliers resulting in a peer network of partnerships (e.g., Ford and Google, GM and Lyft).
Because automotive software components are created by so many different vendors, a large portion of them contain open-source. Just as with 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 the Genivi Alliance and Automotive Grade Linux, open source platforms dedicated to automotive applications.
Estimates in 2018 placed the proportion of open source in the automotive software stack at about 50-70%. Another presentation, in February 2021, placed this amount at about 66%, whether open source was used directly or indirectly within other, proprietary, third-party components.
The productivity benefits of not “reinventing the wheel” are clear. Free and open source software is usually of good quality and provides significant benefits especially when used for entire subsystems. However, security and quality is variable depending on the source of the software. In most cases, you aren’t certain if reused components are secure and high quality and thus steps must be taken to alleviate this risk.
Insecure versions of open source components are a common security weakness in automotive software. In some cases, the vulnerability has been identified and patched, but the component being used in a vehicle hasn’t been updated.
Lack of updates for open source components or the components that contain a vulnerability is also a challenge for automakers. As difficult as it may be to patch software in automobiles, ensuring the software supply chain is following suit is a complex task. Sometimes updates aren’t forthcoming since the open source may not even be known to the author.
Hidden dependencies within open source components are another key security concern. It’s common for open source to rely on other dependencies in order to function. Dependencies increase the scope of security risk. Some of these dependencies are not documented or if used within proprietary software, completely hidden.
Finally, licensing is a potential minefield for automotive software. Open source isn’t necessarily free to use in commercial products or if it is, redistribution in a product may have legal requirements you need to satisfy. Devices that contain third party software are redistributing any source or binaries used within them which is a unique use case of open source. There is significant legal risk in not properly managing licenses of all of the third-party source and binaries used.
Managing the Risk of Open Source Software
Just as a bill of materials (BOM) helps manage physical inventory in the production of automobiles, managing the quality and security of procured software needs to start with a software BOM – the SBOM.
How Do SBOMs Help Manage Risk?
Implementing a software supply chain risk management program and using SBOMs is critical to improving the security posture of end products. For automotive software development this practice helps meets industry security and compliance requirements
SBOM management provides the following benefits for manufacturers:
- Discovery: Identifies open source components in third-party code and COTS/third-party software. Detect known (N-day) and unknown (Zero-day) vulnerabilities in those components. This includes open source components hidden within binaries from second and third tier software providers.
- Manage Risk: Make more intelligent 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. Streamline vulnerability remediation to mitigate software risk.
The goal of automating software supply chain security is to get deep visibility into the products purchased and deployed to support project goals. The SBOM plus detailed vulnerability information is needed to truly understand the security risk of existing software used in a vehicle.
With new technology that analyzes binary applications without the need to access source code, product security teams can now produce their own detailed SBOMs along with high level dashboards to help analyze and summarize the findings. In addition, a software vulnerability report is critical in cataloging the known vulnerabilities in the software components outlined in the SBOM.
Look for SBOM tools that generate both human and machine readable output that can be exported and shared with other organizations and integrated with security and risk solutions. Human readable formats should provide easy navigation of the components and the vulnerabilities reported.
The automotive sector has always needed to be hyper vigilant when it comes to the quality, reliability, and safety of the physical components used in vehicles. With the growing percentage of software now being integrated into their finished products, it’s no longer feasible for manufacturers to “trust” that embedded code in their products is free of security vulnerabilities and defects. Software supply chain risk management must be a key pillar in vehicle quality control.
Walter Capitani is Director of Technical Product Management for GrammaTech and a recognized expert in embedded and enterprise software security. He has led global product development teams focused on safety-critical and secure software, SaaS application performance, file distribution applications for broadcast television and cinema, and 3D video compression and transmission technology.