Made where? Imposing limits on automotive software based on national origin
The U.S. Commerce Department is about to lay down the law on connected vehicle software, especially targeting imports from China and other perceived adversaries. But here's the kicker: the software supply chain is so complex that even proprietary software pulls code from countless sources, including open-source libraries and various forums.
This tangled web makes tracing the true origins of software nearly impossible, particularly in the automotive industry. In this post, we’ll expose how these complexities leave room for vulnerabilities and potential backdoors, regardless of where the software claims to come from.
Get ready to dive into the murky waters of automotive software supply chains and the risks they hide.
The Automotive Software Development Landscape
Modern automotive software development relies heavily on reusable components to streamline the development process. Major automotive companies integrate third-party libraries, frameworks, and open-source code to add functionalities without reinventing the wheel.
This approach enables rapid prototyping and reduces time to market, but it creates a layered architecture where the origin of each component and its dependencies can become obscure. Some of this reused software comes from other projects, and much of it is open source.
Open Source in Automotive Software
Many of the world's leading automotive manufacturers and suppliers leverage open-source software to build their systems. For instance, Tesla uses open-source components extensively, with 56 distinct repositories of projects.
Tesla’s operating system and applications are built with open-source software, including the Linux kernel, device drivers, file systems, camera libraries, fleet telemetry, cryptography, messaging, and graphics libraries.
Similarly, Automotive Grade Linux (AGL) is an open-source adaptation of Linux and its supporting packages that is optimized for automotive use and is used by manufacturers such as Toyota and SAIC Motor, a major Chinese automaker and a silver member of AGL.
Open Source Knows No Boundaries
A 2021 report noted that Huawei, a Chinese company linked to allegations of spying on behalf of the government, was a top contributor to the Linux kernel as measured by lines of code, surpassing Intel. Although the company has dropped from that position in 2024, they are still among the top ten corporate contributors to the Linux kernel.
Google, one of the top contributors, has offices in China and 59 other countries, so it’s possible that some of Google’s contributions are coming from China as well.
A Global Effort
Altogether, around 15,000 people around the world have contributed to building just the Linux operating system kernel and millions more to many other open-source projects. GitHub, the most popular repository for open-source software, reported over 100 million developers and more than 420 million projects, including at least 28 million public ones.
At the end of 2023, the highest number of developer accounts on GitHub came from the U.S., India, China, Brazil, the United Kingdom, and Russia. At least two of those countries won’t make the Commerce Department happy. It’s a dynamic and widely distributed ecosystem. Developers come and go. The fastest growth in new accounts now comes from Bangladesh (with approximately a million accounts), followed by Nigeria, Pakistan, and Singapore.
Who maintains open source?
Open source is maintained by legions of volunteers. The Linux kernel has over 2,500 maintainers, each responsible for a specific component of the operating system. They take code from contributors, do their best to check it for errors and regressions and patch it into the existing code. They also handle arguments among developers and interactions with vendors. It’s a truly thankless task. The Commerce Department might note that almost 60 of those maintainers are from China or Russia.
Projects from GitHub may range from individual or small group efforts with no code inspection or vulnerability assessments to large, well-structured, highly maintained efforts. Even though the code is accessible, it can be challenging to inspect their code rigorously. Bugs and vulnerabilities can be elusive and are a fact of life in software engineering. It can be impossible to tell whether a vulnerability has been added accidentally or maliciously.
Changes Can Be Subtle but Impactful
One argument for restricting the importation of software from potentially hostile countries is the risk of hidden malicious functionality. That remains a good argument for blocking these imports. But what about software with source code that can be freely inspected? While open-source software might seem less risky, the concern remains valid. An adversary doesn't need to include overtly malicious functions in the deployed software. Instead, they can introduce a subtle vulnerability that goes unnoticed, which could later be exploited to enable harmful capabilities.
Origins of Proprietary Software Aren’t so Straightforward Either
Tracking the origins of in-house and proprietary software is opaque and equally challenging. Even proprietary software often uses open-source libraries. Systems are incredibly complex, and rewriting fundamental components like video encoders and decoders, compilers, or machine learning frameworks from scratch is not practical.
Major OEMs and software producers have software engineering operations in many countries, including China. Some examples include:
GM China Advanced Technical Center
Ford’s Nanjing Research and Engineering Center
BMW’s Shanghai R&D Center
Mercedes-Benz Tech Center China in Beijing
VW’s production and innovation center in Hefei
Bosch’s R&D facility in Suzhou
Top software producers also have substantial development operations in China. The Center for Security and Emerging Technology at Georgetown University reports that 10% of the research labs of Facebook, Google, IBM, and Microsoft were in China. Microsoft’s largest R&D center outside the United States is in China and Apple has facilities around Shenzhen. Google notably shut down its AI research center in China after accusations that its research was benefiting the Chinese military.
Not Just China
All OEMs also rely on Tier 1 suppliers for aspects of their software, who in turn, may source from a multitude of other software providers and contract developers from around the world. And all of them rely on open-source software in some way.
For example, Bright Box and KPIT Technologies are two companies that provide proprietary automotive software and joined AGL in 2019. Like the ones listed above, they use open-source software and rely on a distributed workforce that includes countries that the U.S. may sanction.
Bright Box LLC, which develops software for connected cars and is deployed by brands such as Infiniti, KIA, Toyota, Hyundai, and Nissan, is headquartered in Switzerland but states that its developers work primarily in Eastern Europe. It has offices in Switzerland, Russia, Hungary, and the UAE. Russia would most certainly make the Commerce Department's list of “countries that are considered adversaries.”
KPIT Technologies, another AGL member, develops software for ADAS, powertrains, and connected vehicles. It works with leading OEMs, Tier 1s, and semiconductor companies and has offices in China, Japan, Korea, Thailand, the U.S., India, Singapore, Sweden, Germany, and England.
Borrowing Code Snippets
The software supply chain is made even more complex because programmers may search for and copy snippets, sometimes large chunks of code, from various projects posted on source code repositories such as GitHub or from question-and-answer sites such as Stack Overflow. This is often done without fully inspecting or perhaps even understanding the code just to get the job done. This practice can introduce additional layers of complexity, dependencies, and potential vulnerabilities that are difficult to track and manage. It also makes the supply chain even more opaque.
Challenges, Interdependencies and How to Effectively Manage
Tracking the origin of software can be virtually impossible, especially when it is constantly evolving with contributions from volunteers around the world. Interdependencies also lead to complications that aren’t always fully known.
Tracking origins is complex for the following reasons:
Diverse Sources: Software components come from various sources, including open-source repositories, commercial vendors, and in-house development. Each source has different levels of documentation, support, and reliability. Tracking the exact origin of a component can be challenging, especially if it has been modified or forked from its original version.
Evolving Versions: Software components evolve over time, with new versions addressing bugs, adding features, or improving performance. Keeping track of which version is used in a project and ensuring compatibility with other components is a complex task. Without proper version control, a project might end up using outdated or vulnerable versions of components.
Licensing Issues: Different components come with various licensing agreements, which can affect the legal and financial aspects of a project. Tracking the origin helps ensure that all licenses are complied with, but this is often complicated by the multiple layers of dependencies, each potentially having its own license requirements.
Interdependencies present unique challenges due to:
Nested Dependencies: A single software component can depend on multiple other components, each of which may have its own set of dependencies. This creates a dependency tree that can become deeply nested and difficult to manage. Changes in one component can have cascading effects on others, leading to unexpected behavior or failures.
Compatibility Issues: Ensuring compatibility between different components is a major challenge. Dependencies might require specific versions of other components, and mismatched versions can lead to conflicts and malfunctions. Continuous integration and automated testing are essential to detect and resolve such issues early.
Security Vulnerabilities: Dependencies can introduce security vulnerabilities into a project. A vulnerability in a widely-used library can affect countless projects that depend on it. Tracking the origin and keeping dependencies updated is crucial for maintaining security, but this requires constant vigilance and a robust update mechanism.
Documentation and Transparency: Not all components come with comprehensive documentation. Lack of transparency in how a component works or how it interacts with other parts of the system can make it difficult to troubleshoot issues or understand the impact of changes. Clear and thorough documentation is vital but often lacking.
Managing through these challenges and independencies is critical and there are several ways to break this down:
Dependency Management Tools: Tools like Maven, Gradle, npm, and Yarn help manage dependencies in software projects. These tools automate the process of tracking and updating dependencies, ensuring that the correct versions are used and reducing the risk of conflicts.
Software Composition Analysis (SCA): SCA tools scan codebases to identify all components and their dependencies, providing visibility into the software’s composition. These tools can detect outdated or vulnerable components and help ensure compliance with licensing requirements.
Automated Testing and Continuous Integration: Implementing automated tests and continuous integration pipelines helps catch compatibility issues and vulnerabilities early in the development process. These practices ensure that changes are tested against all dependencies, reducing the risk of introducing bugs or security issues.
Clear Documentation and Policies: Establishing clear documentation practices and policies for using third-party components can mitigate some of the risks. Maintaining an updated inventory of all components, their origins, versions, and licenses helps in tracking and managing dependencies effectively.
Conclusion
Tracking the origin and interdependencies of software components is a formidable challenge in modern automotive software development.
The complexity arises from the diverse sources of components, their nested dependencies, compatibility issues, security vulnerabilities, and the practice of copying code snippets from various online sources. Given the intricate and opaque nature of the software supply chain, it can be virtually impossible to know the exact country of origin for every piece of source code.
Despite the best efforts and tools available, the risk remains that some components may originate from, or be modified by, countries considered adversaries. As the software landscape continues to evolve, the automotive industry must stay vigilant and adopt best practices in dependency management, while acknowledging the inherent limitations in achieving full transparency.
Given the intricate supply chain that spans open and closed source software with countless, often anonymous, contributors around the world, placing and enforcing restrictions based on national origin becomes incredibly challenging.
About Sanboca Insights
At Sanboca Insights, we specialize in tackling challenges unique to the automotive industry, enhancing the journey from concept to deployment. We partner with leading automakers across the Americas, Europe, and Asia, where we deliver strategic guidance to refine technology roadmaps, accelerate development, forge partnerships, and unveil new opportunities.
Are you ready to lead the charge in redefining the automotive user experience? Contact us today to start your journey toward a more integrated and data-driven future.