Vehicle Manufacturers Need to Know What’s Inside Their Supplier’s Code

This is the second post in a series on vehicle vulnerability management. Read the first post outlining vulnerability-related challenges facing the automotive supply chain.

OEMs’ lack of visibility into the software running on dozens of components developed by multiple suppliers makes it extremely difficult to ensure that their vehicle software does not contain high or critical severity-level vulnerabilities. To do so, they need better control over what they’re getting from their suppliers.  

UNR 155 requires vehicle manufacturers (OEMs) to monitor, protect and respond to vulnerabilities, as well as mitigating vulnerabilities “within a reasonable timeframe.” This is a major hurdle for the automotive industry, given the numerous challenges it faces related to vulnerability management. 

What You Don’t Know Can Hurt You 

When we buy groceries at the supermarket, most of us check the ingredients and expiration dates of packaged goods. We wouldn’t dare cook a meal for our family without being sure the ingredients are safe. 

The same should be true for the automotive supply chain. Often, OEMs don’t have access to the information required to check for vulnerabilities (e.g., Software Bill of Materials, also known as SBOM), and suppliers aren’t necessarily obliged to deliver vulnerability-free software. However, manufacturers are obliged to manage supply chain risks according to UNR 155. 

Achieving full visibility is a long and complex process. Vehicle manufacturers need a way to assess the number and severity of vulnerabilities lurking in their suppliers’ software. 

The potential costs and safety risks of not checking supplier software for vulnerabilities are enormous. Software vulnerabilities are liable to affect critical vehicle functionality and functional safety (e.g., air bags, braking system), possibly endangering lives and resulting in expensive recalls. Following the infamous Jeep Cherokee hack, for example, Fiat Chrysler issued a safety recall to update the software in 1.4 million affected vehicles .

Moreover, the shift of development and production to global suppliers makes it more complicated for manufacturers to control process quality. Suppliers’ ever-growing share of the value chain has now reached approximately 75 percent. 

To address these challenges, OEMs require automated, hassle-free tools that allow them to inspect the supplier software and get the insights needed to determine whether to accept or reject it – before incorporating it into the vehicle components. This visibility enables OEMs to manage the risks, regardless of the complex supply chain,  and ensure that they maintain the highest level of security.

What Needs to Be Checked

Based on our experience in assisting OEMs through this process, the decision to accept or reject supplier code should be based on an analysis of many types of information, including the following examples:

• Relevant public and private vulnerabilities – This includes published software vulnerabilities (not just automotive) from well-known sources such as NVD and JVN, as well as private vulnerabilities, such as AUTO ISAC’s Amber & Red severity level vulnerabilities. Each new vulnerability needs to be mapped to the vehicle software (see below).
• Vulnerability impact – The most basic way to assess impact is via the Common Vulnerability Scoring System (CVSS). Since the CVSS is not automotive-oriented, it’s important to consider not just the base score (1-10), but also the sub-metrics and  specific attack vector (as some may not be relevant to automotive.) For example, a vulnerability that can only be exploited from the network that affects an asset (e.g., ECU) without any network connection. In such a case, it’s possible that a high severity vulnerability affecting an ECU with no network connection can be accepted and doesn’t have to be patched immediately.
• Affected asset information – Understanding the context related to assets affected by a vulnerability, their configuration, metadata and other attributes is crucial. The safety criticality of each component must also be checked before making a decision.
• Security configuration – Beyond vulnerabilities, the component’s security configuration is a critical factor in risk evaluation. Are there any open Ethernet ports? Is there any memory or stack randomization mechanism (e.g., ASLR)? Using ASLR, for example, would make exploiting a buffer/stack overflow more complicated by randomizing the location of where data and code sections are loaded into memory.
• Compilation flags – The compiled run code should be checked for symbols, debug flags, etc. This information is useful for debugging, but it should NOT be part of the final ECU image that runs in the car as it could assist a hacker in compromising the code.

The items to be analyzed will vary according to each OEM’s specific needs.

Getting the Relevant Information from Your Supplier

The accuracy of such an automated inspection process would increase proportionately with the amount of information (SBOM, binary image, etc.) OEMs get from their suppliers. As the volume of vehicle software continues to increase, OEMs should consider making this part of the contract with their suppliers.

All relevant information about assets (e.g., ECU), such as safety criticality level and other important security information, should be maintained by the OEM in an asset management system for easy reference.

The SBOM is a list of all software libraries installed on a hardware component. This information, which can be provided by the supplier, is critical for mapping software vulnerabilities. If the component is delivered without an SBOM (often the case), the next best option is to auto-extract the SBOM from the binary code, which requires using an advanced tool. In any event, the SBOM doesn’t tell the entire story. The only way to learn the security configuration, for example, is from the binary image. 

Knowing the relevant protocols used by each ECU is another useful option for vulnerability assessment. This includes both in-vehicle (CAN, Ethernet, etc.) and v2x (Vehicle to Everything) communication protocols (Internet-based, cellular, etc.). This is useful because some vulnerabilities are based on a particular protocol, irrespective of the software library that implements it. 

The last resort – if you don’t have any of the above – is to extract as much information as you can from the physical ECU device (i.e., black box testing). This requires substantial time and manual efforts, but it’s possible for teams with the right tools and security expertise.

Determining the Right Accept/Reject Threshold

The last step in automating the inspection process is to determine the optimal pass/fail threshold. Since no two OEMs are the same, determining the threshold is an individual, case-by-case process that depends on many objective and subjective factors, including the vehicle model, OS exploitability (Linux, Classic AutoSAR, etc.), TARA, risk tolerance, risk diversity level, etc.

Argus helps OEM and Tier 1 customers work through these issues to define their own criteria for calculating the threshold. Our Vehicle Vulnerability Management system supports a fully automated inspection process, based on the manufacturer’s criteria, and automatically generates an accept/reject recommendation for supplier software upon delivery.

Looking ahead, Argus is exploring ways to promote the development of industry-wide benchmarks for accepting/rejecting supplier software based on security criteria. Given the complexity of the automotive supply chain and the open-ended nature of current regulations, we believe that such an initiative could be helpful for the entire industry.