The automotive industry is in the midst of a two-plus decade run of transformative technological innovation. A sector that for years built vehicles with gas- and diesel-powered engines adopted hybrid electric in 1999, plug-in hybrid electrics in 2010, and electric in 2011. More recently, it’s made significant tech-powered advancements in areas like safety, vehicle connectedness, semi-autonomous driving, and much more.
And, this period of innovation is far from over. Per McKinsey: “In the next decade, the automotive industry will face a magnitude of change that has not been seen in a century.”
This change will largely be fueled by the continued adoption of software components that form the foundation for in-vehicle applications in infotainment, passenger comfort, telematics, fully self-driving capabilities, powertrain, communication, safety, and much more. In fact, it’s estimated that the global market for automotive software will reach a staggering $41.9 billion by 2026, with a double-digit compound annual growth rate (CAGR).
Of course, this type of innovation and advancement will also shine a brighter light on cybersecurity, especially in the software supply chain domain. The combination of an increased volume of software components and suppliers coupled with increasingly aggressive cybercriminals means automotive organizations will need to take particular care to develop applications with trusted components.
In this blog, we’ll explore some of the supply chain security risks expected to emerge with continued technological innovation — along with how software composition analysis (SCA) can help automotive companies address these concerns.
Evolution of the Automotive Software Supply Chain
Just like hardware is sourced from supply chains spanning continents and companies, complex electronic software pieces are also sourced from third parties all over the world.
Given the sheer volume of software components that will be needed to power the next decade of automotive innovation — sensors, infotainment, security, connectedness, integration/validation/verification services, and more — it’s inevitable that auto manufacturers will be forced to rethink traditional software supply chains.
As McKinsey puts it:
Over the last several years, modern cars have become data centers on wheels. Comparing the lines of code in modern connected cars with aircrafts and PCs provides a glimpse into the challenges of securing these vehicles. Today’s cars have up to 150 ECUs and about 100 million lines of code; by 2030, many observers expect them to have roughly 300 million lines of software code. To put this into perspective, a passenger aircraft has an estimated 15 million lines of code, a modern fighter jet about 25 million, and a mass-market PC operating system close to 40 million.
The Future of Connected Cars Driven by Hardware and Software
The sheer magnitude of software components in the vehicles of today and tomorrow does, in theory, create a wider attack surface for bad actors to exploit. As we look to a future of fully self-driving vehicles and even more software-fueled innovation, it’s not hard to imagine the worst-case scenario where a malicious actor gains access to key systems and causes injury to passengers.
Clearly, it’s important for organizations across industries, including automotive companies, to be mindful of software supply chain security. Attackers know it’s practical to infect upstream projects so they can exploit the large number of downstream users. And when software we use is embedded deep within our systems, and we give it complete control of our secrets and sensitive information, compromises can have devastating consequences.
WP.29, ISO/SAE 21434, and Automotive Cybersecurity Regulations
Increased security risks and the growing use of software in the automotive industry have prompted regulatory action. Two standards of particular importance are the WP.29 Cybersecurity Vehicle Regulation and ISO/SAE 21434. Here’s a look at each:
WP.29 Cybersecurity Vehicle Regulation
In the 1950s, the United Nations Economic Commission for Europe (UNECE) formed the WP.29 with the mission of ensuring automotive manufacturers met standards relating to vehicle safety, quality, and environmental impact. In early 2021, WP.29 published UN Regulation No. 155 - Cybersecurity and Cybersecurity Management System.
Per the UNECE website, key parts of the regulation are as follows:
- Collect and verify the information required under this regulation through the supply chain so as to demonstrate that supplier-related risks are identified and are managed
- Document risks assessment (conducted during development phase or retrospectively), test results, and mitigations applied to the vehicle type, including design information supporting the risk assessment
- Implement appropriate cybersecurity measures in the design of the vehicle type;
- Detect and respond to possible cybersecurity attacks
- Log data to support the detection of cyberattacks and provide data forensic capability to enable analysis of attempted or successful cyberattacks
ISO/SAE 21434: Road Vehicles Cybersecurity Engineering
ISO (International Standards Organization) and SAE (Society of Automotive Engineering) are currently developing a framework for cybersecurity risk management in the automotive industry. Per the SAE website, the scope of the standard will be as follows:
This document specifies requirements for cybersecurity risk management regarding engineering for concept, development, production, operation, maintenance, and decommissioning for road vehicle electrical and electronic (E/E) systems, including their components and interfaces.
It’s also worth noting that additional compliance standards and regulations that impact software supply chains are likely to be published in the coming years. (A recent executive order that addressed sourcing “information and communications technology and services” components from foreign adversaries is one example of this.) We expect these to be top of mind for not only auto manufacturers, but OEMs that are increasingly involved in software.
How Software Composition Analysis Helps Secure the Automotive Software Supply Chain
Given the complexity of automotive software supply chains, with numerous vendors and a mix of proprietary and open source components, there’s no single magic bullet that can ensure 100% protection from supply chain threats. But software composition analysis (SCA) can help.
Software composition analysis tools scan your code and look for all the third-party dependencies included within the project. They provide:
- An inventory of all your software dependencies including licenses and vulnerabilities
- Guidance for prioritizing and remediating those issues quickly and efficiently
- A software bill of materials that can help manufacturers keep track of components and versions that go into the software of their car.
This third point is particularly important given the large number of software components auto manufacturers assemble from different sources. Requiring bills of materials from vendors (even if they don’t provide access to source code) is a helpful best practice to decrease the chances a vulnerability eludes your safeguards. These capabilities (which stem from SCA’s comprehensive inventory of OSS components) can also help auto manufacturers when it comes to meeting requirements around open source license attribution notices.
Securing the Automotive Software Supply Chain: The Bottom Line
Innovations in the automotive industry have led to an increasing reliance on electronic and software components. In light of the growing complexities around supply chains — and new compliance requirements — cybersecurity is in the spotlight like never before for the auto industry.
Along with re-evaluating existing software development and quality-assurance processes to meet growing security challenges, auto manufacturers may consider new tools that provide an added layer of protection. For example, FOSSA can play an important role in helping auto manufacturers secure their vehicles and ecosystems by identifying the vulnerabilities and risk in their third-party dependencies.