automotive software Archives

29 April, 2025 . 5 mins read

Cyber Resilience Act Explained: What It Means for the Automotive Industry

With the rapid rise of products utilizing AI, IoT, and connected technology, there has been growing concern across all industries of the cybersecurity risks associated with embedded technology. In response, in December 2024, the European Union put into force the Cyber Resilience Act (CRA), aiming to raise the baseline for security for all digital products and solutions sold in the EU.

Though the regulation originated in Europe, its impact will be global, as today’s interconnected market and supply chain crosses borders. Here’s a closer look at the CRA, why it matters, and its implications on the world’s automotive sector.

What is the Cyber Resilience Act?

The CRA is a legal framework that outlines cybersecurity requirements for products (both hardware and software) with digital elements sold within the European Union. The CRA casts a much wider net than requiring cybersecurity for traditional IT systems, covering everything from smart watches, refrigerators, to agricultural vehicles. In fact, the regulation not only applies to the products themselves, but the full lifecycle of IoT and digital products.

The objective of the CRA is to improve consumer safety, build trust in the digital marketplace, and ensure that manufacturers are held accountable for the security of their products. With this overarching regulation, the hope is that the CRA will foster more transparency for the digital ecosystem, ultimately encouraging innovation while still protecting both businesses and consumers from emerging cyber threats.

The CRA mandates a “security-by-design” approach, which means that companies must integrate cybersecurity from design through the end-of-life (EOL). It also requires vulnerability management and updates, along with compliance and documentation.

Key Implications for Industries Utilizing Connectivity

More and more industries are implementing connected technologies into their supply chain, which means the CRA targets a wide range of industries, including defense, IT infrastructure, and robotics/smart factory, to name a few.

Healthcare & Medical Devices: Many healthcare products now boast connectivity and dedicated user support. Products like remote monitoring tools, smart implants, and other medical devices must secure processed data and ensure device integrity.

Smart Manufacturing: Factories often use IoT and smart automation to optimize their factory lines. Networks and real-time operations must protect against cyberattacks that could disrupt industrial processes.

Space & Defense Systems: Satellites and mission-critical technologies must use robust protection to safeguard against cyber threats and protect sensitive operations for national security.

Agricultural Machinery: Like connected vehicles, agricultural transport is becoming much more connected and software-driven, meaning vehicles like autonomous tractors and sensor-based farming equipment must comply with the CRA as well.

CRA: More than the Law

The CRA represents more than just regulation within the EU. It signals a global shift towards mandatory cybersecurity standards for connected solutions, including all types of vehicles. Early preparation will be key, as manufacturers must utilize security-by-design principles from the development stage of all products.

The CRA introduces a risk-based product classification system, allowing a transition period until December 2027 for full compliance.

A lack of cybersecurity resilience increases likelihood of a cyber attack, which can not only lead to operational disruption and financial loss within a company’s supply chain and sales funnel, but can also result in legal ramifications. Non-compliance will result in fines of up to €15 million or 2.5% of global turnover and potential EU market bans, which could also result in a lack of brand awareness or worse, negative brand image.

Why the Automotive Industry Should Care

While most automotive vehicles are excluded from the CRA due to the overlapping nature of the CRA regulations with existing regulations (like the WP.29 R155 and EU General Safety Regulation, GSR), certain automotive components like digital components, aftermarket software, and connected services, as well as vehicles not covered under R155 (like construction or agricultural vehicles) are still subject to the CRA.

Vehicles are complex digital ecosystems, and with more and more technology being embedded into the architecture, compliance will also become more complex. While the details of the CRA are still being worked out, the automotive industry will have to move quickly, as the impacts of the regulation will be wide-ranging. Manufacturers and suppliers can begin by aligning with existing guidelines for cybersecurity resilience in vehicles:

• Standard and Regulation Compliance: Automotive manufacturers will have to ensure that they comply with the existing regulations like UNR-155 and GSR, and are recommended to follow standards like ISO/SAE 21434 when it comes to vehicle architecture and connected platforms.

• Secure OTA Updates: Manufacturers can ensure that their Over-the-Air (OTA) capabilities are secure and efficient, and ensure that vulnerabilities are patched in real-time.

• Regular testing: Testing current architecture for vulnerabilities can be a great starting point to analyze where mitigation is needed.

• V2X security and Security Credential Management Systems: While a Security Credential Management System (SCMS) isn’t explicitly required by the CRA, it can support compliance by demonstrating security best practices.

AUTOCRYPT has been closely involved in cybersecurity regulatory compliance from the early stages, focusing on practical, optimized solutions for manufacturers and suppliers. Our expertise in automotive and IT cybersecurity empowers our partners to seamlessly meet regulatory requirements while strengthening their product reliability, market competitiveness, and maintain a positive brand image.

To learn more about the CRA, click here. To contact our team about how your company can get started with CRA compliance, contact global@autocrypt.io.

15 April, 2025 . 6 mins read

Post-Quantum Cryptography, and the Future of Automotive Cybersecurity

As of late, there’s been a lot of worried and concerned discussion regarding quantum computing. There are concerns that once quantum computers become available, all IT systems will collapse and be hacked; some blockchain enthusiasts worry that cryptocurrencies will become obsolete; governments worry that national security systems may be compromised. Are these valid concerns? In today’s blog, we’ll explore what quantum computers are and what we can do to manage concerns about the future.

What is Quantum Computing?

The modern-day computer uses “bits” as the basic unit, while quantum computers use “qubits.” The key difference is the way that qubits exist. For example, a bit can be a 0 or a 1, but a qubit can be a 0, 1, or both at the same time. Imagine a spinning coin. While spinning, a coin can be both heads and tails. In quantum mechanics, this is called the principle of superposition, and this superposition allows for quantum computers to process many possibilities simultaneously.

Another interesting property of qubits is entanglement. When qubits are “entangled,” the state of one qubit is directly related to the state of another. This means that if a qubit changes its state, it will instantly affect the other. This phenomenon of qubits enables quantum computers to perform complex calculations far more quickly than a computer using bits, which processes information in a linear, sequential manner.

Quantum computers are still in the early stages of development, and larger tech companies have already begun to create and use quantum computers for research and experimentation. Many experts will say that the quantum computers available today have a relatively small number of qubits and are susceptible to errors. However, some are optimistic that the technology will achieve more accuracy and broader use very soon.

What is Post-Quantum Cryptography (PQC)?

While quantum computing holds great promise for solving more complex problems, it also presents a great risk. If misused, quantum computers could, in theory, break encryption methods that secure sensitive data like personal communications, banking transactions, and even confidential government data.

This is why the development of Post-Quantum Cryptography is crucial to safeguard against this potential threat.

Post-quantum cryptography (PQC), in simple terms, refers to cryptographic algorithms that are secure even in quantum computing environments. Unlike the traditional cryptographic systems we use today, such as RSA or ECDSA, PQC algorithms rely on mathematical structures that quantum computers are less likely to break, such as lattice-based, hash-based, code-based, or multivariate polynomial-based.

Developing PQC for different use cases is essential because if we wait until quantum computing reaches supremacy, it could quickly render current cryptographic systems obsolete, leaving data vulnerable. The transition to PQC should begin now, as preparing for a quantum future will require proactive effort to ensure cybersecurity frameworks remain intact and resilient.

PQC Standardization and Regulatory Development

In 2016, the National Institute of Standards and Technology (NIST) launched a competition to standardize PQC. Researchers from all over the world submitted algorithms and through several rounds, 82 proposals were reviewed and in 2022 four algorithms were chosen: SPHINCS+, CRYSTALS-DILITHIUM, CRYSTALS-KYBER, and FALCON. They are incorporating these standards into the Federal Information Processing Standards (FIPS) document, and additional rounds will likely select new algorithms for digital signatures or other uses.

In April 2024, the European Commission published a recommendation for member states to develop a strategy for implementing PQC, which would define clear goals and timelines for the implementation. This has led several workstreams and think tanks to actively participate in developing and implementing PQC into the European digital infrastructure.

In 2022, the U.S. passed the “Quantum Computing Cybersecurity Preparedness Act,” which included a federal mandate for federal agencies to transition to PQC. The NSA announced that by 2035, all national security systems should implement PQC.

In South Korea, the transition to PQC is being actively addressed by the National Intelligence Service and the Ministry of Science and ICT. They released their roadmap for transitioning to quantum-resistant cryptographic systems in 2020, and the roadmap was designed to span over a 15-year period, setting the goal of fully integrating PQC by 2035.

PQC in Automotive Cybersecurity

The global implementation of PQC roadmaps is ongoing, and use cases can vary across governments and organizations, but one of the most important areas is the automotive industry. As modern vehicles are increasingly becoming software-centric, vehicle architecture is becoming increasingly sophisticated, integrating advanced connectivity features like OTA updates and V2X communications. These advancements enable smarter and more convenient mobility but also create a myriad of cybersecurity challenges if the vehicle architecture is breached, as many of the cryptographic methods were designed for more traditional computing environments.

However, though regulations and standards do not yet mandate its implementation, manufacturers, suppliers, and solution providers in the industry have already begun to explore and evaluate PQC implementation:

NXP Semiconductors is developing quantum-resistant firmware updates for vehicle applications

Vodafone is testing PQC-secured VPNs, which is focused more on network security, but the company states it could be extended to connected vehicle applications

LG U+ showcased its PQC-based applications like secure digital keys and infotainment systems at CES 2023, and continues to develop quantum-resistant technology for network and cellular applications

As with traditional IT systems, once quantum computing reaches supremacy, vehicle systems could be vulnerable to attacks. Transition to PQC before quantum computing reaches practical implementation is crucial, as many worry that bad actors could already be stockpiling encrypted automotive data, waiting for quantum computing to enable them to decrypt, a long-term attack strategy known as “Harvest Now, Decrypt Later” (HNDL).

Preparing for the Post-Quantum Future

While there’s no way to know when quantum computers will reach practical supremacy, one thing is clear: the transition to PQC is no longer a theoretical need but an urgent necessity, especially in–vehicle applications.

However, transitioning to PQC–based solutions comes with its own set of challenges. PQC algorithms require a greater amount of computational power, which can be a concern for existing automotive hardware. This is why early testing, standardization, and collaboration will prove to be invaluable for realistic integration.

The dilemma is not whether we should implement PQC but how quickly we can make it a reality. The automotive sector has a lot of work to do, and security solutions providers like AUTOCRYPT are on track to ensure that the transition happens efficiently and securely.

To stay informed about the latest news on mobility tech and software-defined vehicles, read our blog for more technology insights or subscribe to AUTOCRYPT’s monthly newsletter.

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.