Managing Automotive Software Security With the Software Bill of Materials (SBOM)

The automotive industry is evolving at an incredible pace, characterized by changes in vehicle architecture, automotive software, and user experience. No longer are automobiles a mere transportation tool, but consumers are now expecting their car to function as their smart mobile device on the road, capable of not just (autonomous) driving, but also personal computing tasks from music and video streaming to in-car payment and cloud-based functionalities. Today, drivers and passengers want their interactions with the car to be personalized, synchronized, and most importantly, effortless.

A smart mobile device relies heavily on software applications. Just like smartphones and tablets, the modern vehicle operates on hundreds of software applications with millions of lines of source code, powered by up to a hundred application processors in the forms of MCUs (microcontrollers) and ECUs (electronic control units)—and in some cases, a couple of centralized CPUs. Whereas conventional vehicles are largely evaluated by their hardware, software is playing an increasingly important role in defining today’s vehicles. We are in an age where two vehicles with the exact same engine and technical specs can drive and feel entirely different depending on the underlying software.

The Role of Automotive Software

In a modern vehicle, a surprising number of features that consumers take for granted are enabled by software. To consumers, the most familiar type of automotive software is the user applications installed in the head unit (i.e., dashboard and infotainment system), which make up the human-machine interface (HMI). Yet, beneath the surface, there are hundreds of software applications embedded throughout the in-vehicle system, underpinning the smart features that are seamlessly integrated into the driving experience. For instance, software is embedded in every camera to process the captured imagery and transmit the visual information to the computing unit, enabling advanced driver-assistance systems (ADAS).

Looking deeper within the vehicle, all ECUs contain pieces of embedded software that act as communication modules, allowing them to communicate with one another throughout the CAN buses, the head unit, the telematics control unit (TCU), and externally to the telecommunications network and the clouds. These communication interfaces lay the groundwork for V2X (vehicle-to-everything) communications and vehicle-infrastructure cooperated autonomous driving (VICAD). Lastly, information collected from the in-vehicle system is likely recorded and transmitted to the OEM cloud, allowing for the vehicle security operations center (vSOC) to detect anomalies and respond to any potential cybersecurity threats. All these software-enabled features run seamlessly without the need for any manual intervention.

Who Develops Automotive Software?

Unlike hardware parts, most of the software components used in automobiles are not directly developed by OEMs or Tier 1 suppliers. Instead, they come from a diverse range of software vendors and providers, including HMI providers, middleware providers, operation systems providers, telematics providers, ADAS software providers, telecommunications providers, cloud providers, security providers, and many more. Some of these software components are installed directly on top of the infotainment system, while others are embedded within the wide array of in-vehicle systems prior to the assembly phase. Oftentimes, software vendors need to work with hardware suppliers and chipmakers during the production process to ensure cross-industry interoperability. As software becomes an integral part of production, the automotive supply chain is looking less like a vertical deliver-and-assemble process but more like a horizontal network of partnerships and co-developments.

The Components of Automotive Software

A vehicle’s software environment is much more complex than that of other computing devices like smartphones and PCs. Smartphones and PCs operate on a single OS, where all software applications are developed for the specific platform. In the vehicular software environment, however, vehicles do not run on a single OS nor a proprietary platform (even though OEMs are moving in that direction—topic for another time). This means that every software component is essentially independent, only to be stitched together by the rules set out by standardized communication protocols and interfaces.

Since automotive software components are developed by individual parties, a large portion of them contain open-source code and licenses. This isn’t surprising given that more than 70% of all the world’s software source code is open source—the most popular mobile OS Android was built on the grounds of the open-source Linux kernel, while over two-thirds of all web servers in the world run on the open-source Unix OS and its variants. Of course, these popular open-source distributions are often developed and managed by large corporations, ensuring that vulnerabilities are monitored, detected, and patched immediately. But this isn’t the case for automotive software, which comes from hundreds of vendors and developers across the world. Since open-source code is widely copied and modified during the development of applications, even developers can lose track of which components or licenses were used, or whether one component could form codependency with another. This makes it much more challenging to manage software updates and ensure that patches get to the right vehicles on time.

Fortunately, there is a promising solution that makes it easy for automotive OEMs to continuously manage their in-vehicle software throughout all stages of the software development lifecycle (SDLC)—the software bill of materials.


Securely Manage Automotive Software With the Software Bill of Materials (SBOM)

To counter the security risks that arise alongside the growing popularity of open-source software (OSS), the software bill of materials (SBOM) has become a popular tool to manage OSS vulnerabilities across many industries. An SBOM, as its name suggests, is a machine-derived list that contains a detailed breakdown of all open-source ingredients—including code and licenses—found within a piece of software. In 2021, a US Executive Order on enhancing OSS security made SBOM mandatory for certain sensitive industries. A detailed guideline was later published by the National Telecommunications and Information Administration (NTIA) of the US Department of Commerce.

Like many other industries, the SBOM is the most effective way for OEMs to manage automotive software. Not only does it help establish a vulnerability-free software environment in the first place, but it also allows OEMs to keep track of vulnerabilities in their OSS and licenses during the aftermarket stage and have them patched via OTA (over-the-air) updates to all impacted vehicles.

AUTOCRYPT’s newly launched AutoCrypt® Security Analyzer (SA) is an SBOM-based software analysis and management tool that accurately detects and categorizes software components, enabling OEMs to continuously manage their automotive software during all stages of the vehicle’s lifecycle.

To learn more about AutoCrypt® Security Analyzer and AUTOCRYPT’s mobility service solutions, contact global@autocrypt.io.

To stay informed and updated on the latest news about AUTOCRYPT and mobility tech, subscribe to AUTOCRYPT’s quarterly newsletter.

Related Articles