Addressing AUTOSAR-Driven Challenges in Automotive SBOMs

With the rise of electric and connected vehicles, automotive companies need to handle a complex and continually growing system of software components and dependencies. Without proper management, this complexity can lead to missing critical system vulnerabilities.

A significant part of the solution to this issue is creating a software bill of materials (SBOM). Having properly organized documentation of all software elements in one place not only makes your tech team’s life easier but also minimizes security risks for your business.

In this article, we discuss the importance of SBOMs for the automotive industry and closely look at key nuances and challenges of generating SBOMs for embedded devices and AUTOSAR-powered software. You’ll also find a few practical tips on overcoming some of these challenges. This article will be interesting for project leaders working on automotive solutions and looking for ways to improve their products’ cybersecurity.

Why SBOMs matter for automotive software projects

A software bill of materials (SBOM) is a detailed list of software components and dependencies. It usually includes a component’s name, supplier, and version; information about the licenses governing each software component; SBOM contributors/authors; timestamps; component vulnerability statuses; and more. Having all these details gathered in one document helps your team get a comprehensive view of the software’s makeup.

An SBOM also simplifies compliance with industry requirements and security risk management. For example, information about component versions allows software engineers to track existing vulnerabilities and apply patches to mitigate them.

SBOMs in the automotive industry might have different contents depending on the software type and purpose. An average SBOM for an automotive system typically includes elements like:

Why use an SBOM for automotive software?

A thoughtfully created and thoroughly maintained SBOM helps development teams ensure software management and mitigate vulnerability-related risks.

Manage software components. An automotive SBOM helps businesses within the industry instantly see where each component comes from, explore its essential details, track latest updates, and efficiently prioritize remediations of each component.

Mitigate cybersecurity risks. An SBOM makes it easier for businesses to centralize vulnerability management by accumulating all crucial information about software components and their dependencies, including structures created outside the company.

Manufacturers can also use an SBOM to identify common vulnerabilities and exposures (CVEs) and block affected components from reuse.

Are SBOMs obligatory for automotive software?

Even though not all organizations are required to create and maintain SBOMs for automotive solutions, businesses that care about software security and efficiency tend to follow this practice. However, we can already see a few mentions of SBOMs in legal documents.

In the United States, the White House published Executive Order 14028 in 2021, requiring all software vendors who work with the federal government to provide SBOMs. Also, the National Highway Traffic Safety Administration included SBOMs in their 2022 Cybersecurity Best Practices for the Safety of Modern Vehicles recommendations (4.2.6 Inventory and management of hardware and software).

If your solution targets EU countries, explore UNECE Regulation 156, which requires manufacturers to implement a software update management system. There is also a mention of requiring software vendors and producers to use and share SBOMs in the Cyber Resilience Act (CRA) from the European Commission. However, SBOM requirements will take effect three years after the CRA enters into force (which is expected to happen in the second half of 2024), so SBOM requirements will likely be enforced in 2027.

Many automotive systems rely heavily on various embedded systems. Building a quality SBOM that accounts for all components of such systems can be a challenge. Let’s take a detailed look at the key nuances of building an SBOM for embedded systems.

Nuances of creating SBOMs for embedded systems

When building an SBOM, the main goal is gathering component names and versions. Making sure your SBOM is complete and up to date can be tricky because:

1. There are many supply chain vendors, each handling their own software inventories and compliance procedures.
2. Technologies evolve rapidly, making it hard to keep up with them and predict which will prove inefficient and which will stay around.
3. Embedded systems are complex and often contain closed information, which makes it almost impossible to gain vital data for your SBOM.

Let’s tackle the third challenge, exploring the nuances of embedded systems in detail and discussing potential ways to handle them.

For open-source components, collecting data is straightforward, as all version information is usually available in text format. But real-world projects often combine open-source components with proprietary ones. Thus, it becomes harder to obtain version information for each executable binary or library file in the project. An exception to this issue is rich operating systems, since standard executables contain metadata which allows engineers to obtain the version information for building an SBOM.

Another challenging situation you can face is working with a monolithic binary built out of several static libraries, which makes it hard to extract data for your SBOM. The reason is that the only way to extract such data is by scanning a binary for signatures of known libraries.

And when dealing with embedded devices, the complexity of generating an SBOM for firmware rises dramatically. Reasons why it’s hard to extract component names and versions from firmware include the following:

• Vague file formatting. The firmware is usually represented as a file of a monolithic structure, built specifically for the target device. The problem is that some devices might have unique firmware file formats, making it challenging to extract metadata; and some devices may not have any metadata in the firmware at all. Thus, to create a complete SBOM, your team has to classify firmware parts to find which of them have code and to which CPU architecture they relate.

• File compression or encryption. Some firmware binaries can be encrypted or compressed by a proprietary algorithm. This makes even signature analysis impossible. Therefore, your team has to conduct firmware file decompression and/or decryption before even starting SBOM analysis.

• Closed firmware information. Information about firmware packages is often closed, making it impossible to obtain a list of existing firmware components in the first place and create signatures for them. In such a case, you might need to reverse engineer a closed file to obtain essential information required for your SBOM.

When it comes to building an SBOM for automotive firmware, the complexity level rises even more. Apart from nuances related to embedded systems, your team also has to deal with challenges related to automotive development platforms. Let’s take a closer look.

SBOM generation challenges for AUTOSAR-driven projects

There are several platforms and standards that can be used for automotive software development, including Robot Operating System (ROS). However, the Automotive Open System Architecture (AUTOSAR) remains a leader in automotive software development due to its standardization and support for safety protocols. Therefore, in this article we’ll focus on AUTOSAR platforms because they are used in the majority of automotive systems.

AUTOSAR standards (also called platforms) allow your team to integrate car hardware built by various manufacturers. AUTOSAR provides developers with standardized APIs and sets of modules they can use to develop firmware for different car components.

What challenges can you expect when creating an SBOM for an AUTOSAR-driven project?

1. Navigating a module-based approach. AUTOSAR platforms have all basic car components already defined. Thus, developers only need to select the set of modules necessary for a car component they work on and then tweak the modules’ behavior to match the requirements. AUTOSAR implements the software-defined car component approach. Developers only need to configure a set of AUTOSAR modules in a configuration tool and then generate the source code, which can be immediately built and flashed to the target device.

Such configuration of AUTOSAR modules not only means that some settings are adjustable but also that parts of the modules can be completely removed from the generated source code. This means that only a single function out of the entire module’s source code makes it to the final firmware binary. And due to the high level of configurability, it can even be only a part of the function. All this leads to the fact that all AUTOSAR-based firmware contains a set of standard AUTOSAR modules which are configured in a unique way along with some amount of third-party code introduced by a developer.

How does all this affect SBOM generation? With general software development for personal computers, for example, the final binary file contains almost all library code. This makes it relatively easy to build an SBOM, as engineers can use signatures across various files to detect whether a certain library is used. However, when creating software for the automotive domain, developers have little knowledge of some components, as AUTOSAR only shows small pieces of information about modules. Therefore, engineers don’t have access to enough code, making it almost impossible to identify used components to deliver a complete SBOM.

2. Managing vulnerabilities. Vulnerability management on the AUTOSAR side is quite tricky too. Since it is impossible to analyze all outcomes of the configuration tool, AUTOSAR vendors release security bulletins in the form of settings, which may lead to generation of vulnerable source code instead of specifying which module is vulnerable.

How does all this affect SBOM generation? When managing vulnerabilities for most software projects, developers have information about which libraries are vulnerable and can simply choose the most secure ones. With AUTOSAR-based development, engineers must carefully explore vulnerability tickets written not for certain modules but for specific configuration combinations. Not only is such a task time-consuming and effort-consuming; it also affects the completeness of information in an SBOM under generation, since it’s challenging to clearly specify the vulnerabilities in question.

So, building an SBOM for AUTOSAR firmware is not an easy task. Since there’s no guarantee that firmware will contain a piece of code or data for which the signature is made, it’s hard to identify modules by only relying on binary signatures.

Let’s explore a few tricks that can help your team overcome some of the challenges related to SBOM generation.

Best practices for generating SBOMs for AUTOSAR-powered systems

For starters, it’s essential to establish a workflow that defines rules of how to create an SBOM for your projects and check whether your business is obliged to follow certain standards. Since there are still no specific SBOM recommendations for automotive systems, consider exploring frameworks and guidelines for creating vehicle software and general recommendations for SBOMs that focus on cybersecurity, such as:

• ISO/SAE 21434 for cybersecurity engineering for road vehicles
• UNECE WP.29 R155 for cybersecurity management systems
• Secure Software Development Framework by NIST
• Recommendations for Software Bill of Materials (SBOM) Management [PDF] from the U.S. National Security Agency for SBOMs as part of a Cybersecurity Supply Chain Risk Management (C-SCRM) strategy
• Recommendations for software development organizations that prepare to meet Cyber Resilience Act rules
• Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM) by the SBOM Tooling and Implementation Working Group, the Cybersecurity and Infrastructure Security Agency (CISA), and a diverse set of experts from across the software ecosystem

Such recommendations can help your team build a workflow for fast and efficient SBOM generation. However, they are not enough to assist you with challenges like the ones we discussed in the previous section.

How can you handle module identification challenges?

To identify AUTOSAR modules in firmware, Apriorit specialists recommend combining multiple approaches. Besides classic binary signatures, we can outline two SBOM best practices that your team can use separately or together to identify code structures and patterns specific to standard AUTOSAR modules:

1. Heuristic methods. Since AUTOSAR modules depend on other modules, developers can use these dependencies to extend the list of modules found by the heuristic approach. Then, developers can create the baseline for validation if dependent modules are also present in the firmware.

Example: The EthSM module can’t exist without EthIf. So, if your team discovers that the firmware uses EthSM, it must also include EthIf, and vice versa.

2. Code pattern recognition techniques. Your team can use the code simulation approach to validate if found code acts as some known function from the AUTOSAR module.

Example: You can collect behavioral patterns from a module’s source code and then use them as signatures to identify the presence of AUTOSAR modules in the firmware.

Conclusion

Creating and maintaining SBOMs for automotive projects is a promising way to discover flaws and vulnerabilities in software components. Thus, businesses can quickly identify vulnerable components, temporarily block them, and carefully fix issues.

However, to create an SBOM that improves your development flow and increases overall system visibility, your team has to be aware of potential challenges and nuances to expect, as well as explore specifics of different platforms for automotive software development. They also should keep an eye on helpful cybersecurity practices and upcoming regulations to make sure your project leverages the newest protection methods and remains compliant.

At Apriorit, we have professional software engineers, embedded system developers, and skilled reverse engineering specialists who are ready to help you create new automotive solutions and generate SBOMs for existing ones.