automotive software Archives

23 February, 2023 . 5 mins read

What Is ASPICE? What does It mean to the Automotive Software Supply Chain?

Software Process Improvement Capability Determination, or SPICE (ISO/IEC 15504, ISO/IEC 33000), is a widely used industry standard for assessing the processes of software development and management, with an emphasis on the capability for continuous improvement. Developed jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), the primary goal of the standard is to help software development task forces and organizations improve the process of their projects. Although SPICE is used for evaluating software development processes in general, several adjusted and extended versions of SPICE have been established to fit the needs of different industries. One of them is ASPICE (Automotive SPICE). As automobiles become increasingly software-oriented, ASPICE is quickly gaining attention in the automotive industry. Many automotive software providers are adopting ASPICE as an assessment standard to improve the quality and efficiency of their software development processes.

The Assessment Framework

Unlike many technical protocols, ASPICE does not define the software development process step by step, but instead lists what practices should be done and what goals should be achieved. This makes the standard applicable to a wide range of software suppliers and development processes, allowing them to carve out a process that best fits their environment.

After undergoing ASPICE assessments, the tested projects are given a rating based on their capability level (CL). A total of six capability levels are included in the assessment framework:

Level 0: Incomplete Process – missing components in the software development process
Level 1: Performed Process – all components are performed, and results are achieved
Level 2: Managed Process – all components are planned, performed, and managed
Level 3: Established Process – process is implemented based on well-established standards across the organization
Level 4: Predictable Process – process is implemented consistently, and results are predictable
Level 5: Optimizing Process – process is consistent, predictable, and continuously improved

Throughout the six levels, organizations that achieve capability levels 2 and 3 are generally considered to have good software development practices, while those achieving levels 4 and 5 are seen as having exceptional capabilities. Not only does this rating system provide helpful insights during self-evaluation, but organizations can also acquire ASPICE certifications by having ASPICE-certified independent parties conduct audits of their software development processes.

For instance, AUTOCRYPT’s new in-vehicle systems security solution, AutoCrypt IVS-TEE, received ASPICE CL 2 certification prior to its initial launch in January 2023. IVS-TEE secures embedded automotive systems by constructing trusted execution environments (TEE), making it one of the first TEE-based security platforms in the automotive industry.

The Assessment Criteria

What are the evaluation criteria that determine the capability levels of an assessment target? To evaluate a process, ASPICE uses the following nine process attributes:

1.1 Process performance
2.1 Performance management
2.2 Work product management
3.1 Process definition
3.2 Process deployment
4.1 Process measurement
4.2 Process control
5.1 Process innovation
5.2 Process optimization

Each of the above attributes is evaluated using a four-point scale, commonly known as the N-P-L-F scale:

N (not achieved): 0-15%
P (partially achieved): 15-50%
L (largely achieved): 50-85%
F (fully achieved): 85-100%

More detailed guidelines are provided in ASPICE on how to evaluate each attribute, making the assessment results both objective and accurate.

The Importance of ASPICE for the Automotive Software Supply Chain

Unlike legally binding regulations such as WP.29 (UN R155/156), ASPICE serves less as a regulation and more as a toolkit that helps all parties in the automotive software supply chain. Suppliers can use ASPICE to gain a clear understanding of their software development processes and improve based on the results, whereas ASPICE certifications can help buyers make more informed purchase decisions for software products.

As the software-centric automotive supply chain starts to take shape, the quality and safety of a vehicle is now defined by its software features instead of hardware performance. As such, many industry players are now adopting ASPICE for an accurate self-assessment of their software development processes, ensuring that the best practices are used to control the quality of embedded automotive software, improve the efficiency of product development, and achieve continuous improvement and long-term success.

Automotive software providers that adopt ASPICE have a competitive advantage as they can maintain a well-defined, streamlined process for software development. This helps them achieve predictable and reliable results while minimizing human errors.

From ASPICE to Software Security

Although ASPICE isn’t a cybersecurity standard per se, it does provide a solid foundation for software security and can be used to complement both cybersecurity and functional safety processes, including ISO/SAE 21434: Road Vehicles – Cybersecurity Engineering and ISO 26262: Road Vehicles – Functional Safety. Since many cybersecurity failures and safety-related recalls can be traced back to improper practice at the development stage, having a well-established and predictable software development process minimizes software vulnerabilities and development flaws.

AUTOCRYPT’s in-vehicle systems security solution, AutoCrypt IVS, also emphasizes the importance of analyzing flaws and vulnerabilities at the software development stage. In 2022, two new tools were introduced to aid this process: AutoCrypt Security Analyzer and S ecurity F uzzer. One of which uses SBOM-based software composition analysis to eliminate software vulnerabilities at the development stage, while the other uses smart fuzzing to generate semi-random test cases to search for development flaws.

Of course, ASPICE and vulnerability testing do not guarantee security throughout all stages of the vehicle lifecycle. This is why AUTOCRYPT also provides intrusion detection and protection (IDP), as well as a vehicle security operation center (vSOC) for continuous fleet monitoring.

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

16 November, 2022 . 6 mins read

Cooperation in the New Automotive Software Supply Chain: An Emphasis on Cybersecurity

While there have been many changes within the automotive industry, since Toyota invented Just-in-Time (JIT) manufacturing in the 1960s, the automotive supply chain hasn’t seen much change within the past 60 years. The supply chain has been a solid vertical structure: Tier 2 suppliers provide subcomponents and materials to Tier 1 suppliers, who then supply OEMs with ready-to-install parts for assembly. This supply chain structure has been universally adopted because it is highly streamlined and efficient, both important attributes of vehicle production. Under this structure, automotive OEMs do not need to communicate directly with lower-tier suppliers, while every supplier focuses solely on fulfilling the orders of the upper-tier supplier. This all worked out great – until automotive software takes over the vehicle.

This vertical structure made perfect sense in the past when the automotive E/E architecture consisted of independent parts and domains. However, we are now approaching a different era of in the automotive supply chain where, fueled by the growing need for connectivity and automation, in-vehicle systems are becoming more and more sophisticated and interconnected, with software now acting as a core component of the vehicle.

OEMs today are beginning to realize that the conventional manufacturing model no longer serves its purpose in the new era of software-defined vehicles. And with more and more EV startups entering the manufacturing game, conventional OEMs may need to redefine their supply chain to incorporate software development and cross-domain cooperation.

Growing Complexity of the Automotive Software Supply Chain

Name any car feature – more likely than not it is enabled by software. The modern vehicle runs on electronic systems and software that are stitched together to communicate with each other via the in-vehicle network. A typical vehicle today consists of up to 150 electronic control units (ECU), which are essentially minicomputers equipped with processors. System software needs to be embedded in each of these ECUs to control a particular domain of functions, such as powertrain, sensor, and infotainment.

As such, it would be an understatement to refer to the software-defined vehicle as “a computer on wheels.” A more accurate description would be “a computer network on wheels.” That’s because today’s vehicles run an average of 100 million lines of code. That is two to three times that of a PC operating system. And in fact, the level of complexity will only increase as more and more automated features and security systems are incorporated.

Under the current software supply chain structure, software vendors supply software development kits (SDK) and modules to chipmakers, which supply the chips (e.g., ECUs) to OEMs or Tier 1 suppliers, who then stitch all these chipsets onto the parts and components, putting them in place within the in-vehicle network. However, most OEMs have very little experience in software integration. Although vehicular software has been around for decades, nothing was at the magnitude and complexity of the software structure today.

Moreover, OEMs and Tier 1 suppliers are accustomed to the vertical supply chain structure. Many are overwhelmed by this growing need for direct external communications and cooperation.

Therefore, just like what many with a strategic mind would do, OEMs are outsourcing the work.

The Emergence of Software Providers and the Need for Cybersecurity

Due to the sheer volume and quick influx of software components, many OEMs choose to outsource software integration to a comprehensive software provider, acting as a “Tier 1 software supplier.” Many existing Tier 1 suppliers have seen this as an opportunity to expand their software division, and because of this many OEMs have chosen to establish or acquire their own dedicated software provider. Some take it a step further by making plans to establish a proprietary operating system and platform where all applications can be developed on. CARIAD from the Volkswagen Group is one such example. As the dedicated software provider for the Volkswagen Group, the company has announced plans to release the Volkswagen Operating System.

It might be tempting for OEMs to maintain their old way of doing things by having software providers take charge of all software integration, while focusing solely on inventory management, assembly, and quality control. However, the new supply chain landscape isn’t as straightforward, with quality control being the key difference.

While hardware components are very easy to standardize and inspect, rules are different in the software game. Since there exists a cybersecurity risk in every connected computer – in the age of connected vehicles, software and cybersecurity must come hand in hand. This means that a large part of software quality control is making sure that it is free of vulnerabilities and flaws that may hinder its functionality and pose a cybersecurity risk. To do so, every piece of software needs to be rigorously tested prior to the release of a vehicle batch.

Additionally, similar to how OEMs are responsible for issuing hardware recalls, regulations are now holding OEMs accountable for software cybersecurity mismanagement and loopholes. The UN R155/R156 regulations set out by UNECE WP.29 mandate that all OEMs maintain an automotive cybersecurity management system (CSMS) and a software update management system (SUMS) for their vehicle fleets. This means that even after a vehicle is passed onto the consumer, software performance must be continuously managed, monitored, and updated and patched in real-time.

The bottom line: whether it is the OEM or the software provider in charge, the OEM will ultimately be responsible for cybersecurity management.

The Importance of Cooperation for Secure Software Implementation

At the end of the day, the jobs of both the OEM and software provider are to ensure that cybersecurity risk within the automotive ecosystem is well managed and minimized. However, this should not be taken lightly because cybersecurity management isn’t simply about buying security software from vendors and installing it into the systems.

In the sophisticated automotive software ecosystem, security measures must be incorporated and custom-built in the manufacturing process to ensure both secure implementation and cross-region interoperability.

Therefore, both OEMs and software providers must take an active role in cybersecurity and cooperate with firms specializing in automotive cybersecurity to facilitate secure software integration and implementation across all domains, from the embedded systems within a vehicle to the vehicle-to-everything (V2X) connections for autonomous driving and vehicle-to-grid (V2G) applications for EV charging.

The takeaway is this: the automotive industry has entered a new era – an era where value is no longer added step by step through vertical supply chains but generated from horizontal cooperation, and an era where the automobile is no longer a product, but a combination of services stacked on wheels.

To succeed in the new era of smart mobility, cooperation is the key.

To learn about how AUTOCRYPT’s in-vehicle systems (IVS) security solutions can help OEMs secure software integration and connectivity, contact global@autocrypt.io.

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

10 November, 2022 . 6 mins read

Vehicle Cybersecurity by Design: A Look at NHTSA’s 2022 Cybersecurity Best Practices

As more and more software components and connected technologies make their way into vehicles, cybersecurity has rapidly become a crucial aspect of vehicle design, manufacturing, and maintenance. However, in the century-old automotive industry, cybersecurity can be an unfamiliar field of expertise. Many automotive OEMs have found it challenging to implement security by design and integrate vehicle cybersecurity into functional safety.

To promote standardized practices in vehicle cybersecurity, the National Highway Traffic Safety Administration (NHTSA) – the United States’ federal agency dedicated to transport safety – drafted a guideline in 2016 on Cybersecurity Best Practices for the Safety of Modern Vehicles. The guideline helps automotive OEMs and suppliers establish a set of procedures to minimize cybersecurity risks and effectively manage threats throughout the vehicle lifecycle.

NHTSA’s guideline is centered around the voluntary standard of ISO/SAE 21434: “Road Vehicles – Cybersecurity Engineering”, a vehicle cybersecurity standard co-published by the International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE). Although compliance with the standard isn’t enforced by law like the United Nation’s R155 and R156 set out by UNECE WP.29, most automotive OEMs across the globe refer to ISO/SAE 21434 as a guide to establishing a secure procedure for vehicle manufacturing and post-production management.

In September 2022, NHTSA published the finalized version of the Cybersecurity Best Practices guideline, five years after the initial draft was released in 2016. The updated guideline contains more detailed descriptions of implementing appropriate cybersecurity procedures with respect to an OEM’s corporate process, as well as modifications based on the feedback and comments provided by industry experts.

Most importantly, the finalized Cybersecurity Best Practices contains updates to reflect the finalized version of ISO/SAE 21434, which was still under development when the 2016 draft was released.

A Summary of Key Practices Outlined by NHTSA

NHTSA’s Cybersecurity Best Practices contains a comprehensive corporate guide from as broad as leadership priorities and employee education to as specific as technical manuals on cryptographic techniques and credentials. In this blog, we extract some of the key practices relating to the establishment of vehicle cybersecurity by design, along with some of AUTOCRYPT’s tips that can help save corporate resources during the implementation process.

The Importance of Security by Design

Speaking of cybersecurity, most people tend to think about cybersecurity systems and tools like firewalls and threat detection software. However, the scope of cybersecurity in the IoT age stretches beyond these traditional definitions. For the automotive industry in particular, cybersecurity isn’t simply about threat detection and response, but covers an end-to-end process that begins from a vehicle’s development stage all the way to its everyday usage in the consumer’s hand. Therefore, a vehicle must be designed and developed with security in mind, and an OEM must continuously monitor and manage threats throughout the entire lifecycle of the vehicle.

Below is a summary of NHTSA’s suggested practices for achieving cybersecurity by design.

1. Risk Assessment and Removal

To incorporate vehicle cybersecurity by design, risk assessment must be performed at an early stage of a vehicle’s development process. This is done by evaluating a vehicle’s potential entry points from a threat actor’s perspective, predicting their motives and intrusion methods, then listing out the risks the vehicle faces. Of course, it can be difficult to pinpoint all prospective risks at an early stage. Hence this assessment should primarily focus on identifying risks that could potentially threaten the safety of passengers and other road users.

Our Tip: Cybersecurity risk assessment should be conducted by a team of security experts that specialize in automotive systems and architecture. To fill this gap, AUTOCRYPT provides Threat Assessment and Remediation Analysis (TARA) to automotive OEMs, generating an accurate assessment of the potential risks of a vehicle model. A professionally conducted TARA enables an OEM to make early adjustments to its system design and architecture to remove safety-critical risks, creating a solid foundation to build upon.

2. Security Testing and Vulnerability Identification

At the next stage, NHTSA recommends a full evaluation of both commercial off-the-shelf (COTS) and open-source software components used in embedded vehicle systems such as ECUs. This allows the OEM to identify all known vulnerabilities in their software. After known vulnerabilities are removed and patched, fuzzing and penetration testing should be conducted to further eliminate any zero-day vulnerabilities and software development flaws. To enable security by design, automotive OEMs need to ensure that their vehicles are vulnerability-free before moving into mass production.

Our Tip: AUTOCRYPT offers a range of advanced cybersecurity testing tools and solutions for manufacturers to identify flaws and vulnerabilities within their systems. Starting from AutoCrypt^® Security Analyzer, which utilizes an SBOM (Software Bill of Materials) approach to scan the source code and break down the components of open-source software by different units of analysis, enabling accurate patching with minimal modifications required. This is followed by AutoCrypt® Security Fuzzer, which feeds the tested system with randomly generated, invalid, and unexpected inputs in an attempt to trigger errors and expose its vulnerabilities. Lastly, AUTOCRYPT’s security validation experts conduct penetration testing on the targeted program to eliminate any remaining flaws and vulnerabilities.

3. Monitoring, Containment, Remediation

After all the preventative measures are implemented, an OEM needs to integrate a set of security monitoring and management systems into the vehicle architecture. The NHTSA emphasizes that automotive OEMs must maintain their capability to monitor, contain, and respond to any attacks against their vehicle fleet after they are sold to consumers, with rapid incident detection and remediation capabilities being of paramount importance. This means that when a cyberattack occurs, the OEM must be able to detect it in real-time and prevent it from causing any safety-related impacts to its vehicle fleet.

Our Tip: An effective intrusion detection and prevention system (IDPS) should be equipped on every vehicle to defend it from all types of intrusions and internal threats. AutoCrypt® IVS is an advanced firewall for in-vehicle systems, capable of detecting any signs of intrusion and contain them from spreading inside the vehicle. To make things more visible for the OEM, all this fleet information can be visually monitored and managed on AUTOCRYPT’s Vehicle Security Operations Center (vSOC).

The Growing Importance of Vehicle Cybersecurity

Legally speaking, even though NHTSA’s Cybersecurity Best Practices and the ISO/SAE 21434 standard are not enforced as of today, they are extremely helpful to OEMs that want to succeed in the market of software-defined vehicles. Putting legalities aside, since many embedded systems inside a vehicle are directly related to its physical functionality, vehicle cybersecurity and functional safety are no longer separable, with cybersecurity becoming a crucial evaluation criterion for quality. Therefore, whether it is for regulatory compliance or quality assurance, OEMs and software providers must work together with cybersecurity providers to implement security by design and pave a safe future for every road user.

To learn more about AUTOCRYPT’s in-vehicle systems (IVS) security solutions and offerings, contact global@autocrypt.io.

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

16 May, 2022 . 6 mins read

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.