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 are often 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, such as Ford and Google and General Motors 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 has become a fact of life. Android, a popular platform for automotive head units, has been 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%.
The productivity benefits of not “reinventing the wheel” are clear. Free and open-source software usually offers good quality and significant benefits, especially when used for entire subsystems. However, security and quality vary, depending on the source of the software. In most cases, security pros aren’t certain if reused components are secure and high quality and thus, they must take steps 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 used in a vehicle hasn’t been updated.
Lack of updates for open-source components or the components that contain a vulnerability has also become a challenge for automakers. While patching software in automobiles presents a challenge, ensuring the software supply chain follows suit has become a complex task. Sometimes updates aren’t forthcoming since the open-source components are not 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 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 presents 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 the security team needs 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’s significant legal risk in not properly managing licenses of all 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.
Implementing a software supply chain risk management program and using SBOMs can improve the security posture of end products. For automotive software development this practice helps meets industry security and compliance requirements. SBOM management offers 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.
By automating software supply chain security, the organization gets deep visibility into the products purchased and deployed to support project goals. The team will need the SBOM plus detailed vulnerability information 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, it’s critical to have a software vulnerability report to catalog the known vulnerabilities in the software components outlined in the SBOM.
Look for SBOM tools that generate both human and machine-readable output that the team can export and share with other organizations and integrate with security and risk solutions. Human readable formats should offer easy navigation of the components and the vulnerabilities reported.
The automotive sector has always needed to stay 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 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. Companies must make software supply chain risk management a key pillar in vehicle quality control.
Walter Capitani, director of technical product management, GrammaTech
