Key Takeaways

• Connected and autonomous vehicles have made embedded systems a front-line cybersecurity concern.

• Automotive compliance now requires deeper software supply chain visibility, including SBOMs, provenance data, and lifecycle monitoring.
• SBOMs help identify what’s in vehicle software, but teams also need to understand which vulnerabilities are actually exploitable.
• Memory-based vulnerabilities remain a major risk across ECUs, ADAS, infotainment, and connectivity systems.
• RunSafe helps automotive teams reduce exploitability with SBOM generation, vulnerability analysis, binary hardening, and continuous monitoring.

 

If you’ve made a recent trip to San Francisco, it can feel like you’ve stepped into the future when you spot an autonomous vehicle navigating the streets, picking up passengers, and cruising the city’s famous hills. But as autonomous vehicles move from concept to reality and vehicle connectivity becomes the norm, embedded systems, the technology that makes it all possible, are an often overlooked but critical piece of automotive software security.

That risk is no longer theoretical. In March 2025, the U.S. Department of Commerce’s Bureau of Industry and Security finalized the Connected Vehicle Rule under 15 CFR Part 791, reflecting growing national security concerns around the software and hardware used in connected vehicles. The rule focuses on vehicle connectivity systems and automated driving systems, restricting certain transactions involving covered software and VCS hardware when those components are designed, developed, manufactured, or supplied by entities tied to designated foreign adversaries, including China and Russia. 

This shift is happening alongside broader automotive compliance expectations, including ISO/SAE 21434, ISO 26262, and UNECE R155/R156. Together, these frameworks raise the bar for how manufacturers manage cybersecurity risk, protect critical vehicle functions, maintain software supply chain transparency, and support secure vehicles throughout their lifecycle.

The result is a new reality for connected and autonomous vehicles: OEMs and suppliers need more than point-in-time vulnerability scans or supplier assurances. They need continuous visibility into embedded software, accurate SBOMs, provenance data, and practical ways to reduce exploitability across long vehicle lifecycles.

Why Embedded Systems Matter for Automotive Security

Embedded systems are integral to modern vehicles, processing sensor data and controlling everything from engine performance to collision avoidance. However, as vehicles become more connected and automated, embedded systems face mounting security challenges and are vulnerable to a range of threats, including unauthorized access, data breaches, and potential manipulation of vehicle controls. 

 “I think it’s important to understand there’s sort of a core tension between modern vehicles that no longer are just cars with computers,” explained Joe Saunders, Founder and CEO of RunSafe Security. “Rather, they are software platforms with tires. And these systems or these platforms, if you will, have anywhere from 40 to 100 plus software components [in one] vehicle. And this includes a very large footprint of open source software.”

One of the biggest threats to embedded systems is memory-based vulnerabilities. Memory safety is a foundational aspect of software development, ensuring that programs operate reliably and securely without accessing or manipulating memory incorrectly. 

Vehicle software is vulnerable to memory safety threats in four key systems:

• Electronic Control Units (ECUs) in Autonomous Vehicles: Responsible for critical driving functions (e.g., braking, acceleration, steering). A buffer overflow attack could lead to unauthorized access and control and erratic vehicle behavior.
• In-Vehicle Infotainment Systems (IVI): Infotainment systems need to be safeguarded from heap-based overflow vulnerabilities, which could be exploited to execute arbitrary code and gain access to other vehicle systems.
• Advanced Driver Assistance Systems (ADAS): ADAS software needs to be protected from stack-based buffer overflows that could alter sensor data or decision-making algorithms, endangering the vehicle’s safety.
• Connectivity Systems: Connectivity through 4G/5G cellular, Bluetooth, wireless CarPlay/Android Auto open the door for memory corruption attacks that can lead to remote access to vehicles.

How to Secure Automotive Embedded Systems and the Software Supply Chain

As vehicles become increasingly software-defined, automotive software security must be treated as both an engineering priority and a compliance requirement. Modern vehicles rely on hundreds of ECUs, ADAS components, infotainment systems, telematics, connectivity modules, over-the-air update mechanisms, and supplier-provided software. Each layer expands the attack surface and increases the importance of software supply chain visibility.

At the same time, standards and regulations such as ISO 26262, ISO/SAE 21434, UNECE R155, and UNECE R156 are pushing OEMs and suppliers to show more than process documentation. Automotive compliance now increasingly depends on demonstrable, lifecycle cybersecurity assurance: knowing what software is in the vehicle, where it came from, which vulnerabilities matter, how risks are mitigated, and how security is monitored after deployment.

Here’s where to start.

1. Prioritize Software Bill of Materials (SBOMs) to Evaluate the Software Supply Chain

Software Bill of Materials (SBOMs) are essential tools for demonstrating regulatory compliance, tracking all components, libraries, and modules used in software applications, and enabling quick responses to security concerns. With the proposed bans from the Biden Administration on the horizon, SBOMs will be invaluable for vehicle manufacturers needing to evaluate their software supply chain to ensure they are not incorporating prohibited software. SBOMs provide detailed inventories of software components within a software binary, enabling quick compliance assessments.

2. Secure Embedded Systems from the Ground Up

Secure by Design principles are no longer optional in automotive software development. As vehicles become more complex and interconnected, retrofitting security measures after development is both costly and ineffective. Following Secure by Design principles will include threat modeling during design phases, implementing secure coding practices, conducting regular security testing, and building in mechanisms for secure updates throughout the software lifecycle.

3. Adopt Automated Vulnerability Identification and Advanced Code-Hardening Techniques 

Fortifying critical systems against cyberattacks, like braking and steering in an autonomous vehicle, means protecting the millions of lines of code that allow them to function. Automated vulnerability identification and code-hardening protects software against attacks that could compromise vehicle operations and safety while reducing the attack surface.

Specifically, memory relocation techniques prevent memory-based vulnerabilities from being exploited in embedded systems. Known as Load-time Function Randomization, the technique ensures that each instance of the software has a unique memory layout, making it extremely difficult for attackers to predict the location of specific functions, proactively neutralizing common exploit techniques like Return-Oriented Programming (ROP) and buffer overflow attacks.

The Road Ahead: Building Secure and Resilient Vehicles

The increased focus on embedded systems and the automotive software supply chain is a positive one. Ultimately, adopting stronger cybersecurity practices now is an enabler of new vehicle technology, greenlighting innovation and allowing vehicle manufacturers and suppliers to protect their products and customers from the growing landscape of cyber threats.

Learn more about techniques for using SBOM data to track and mitigate security risks in our guide to creating and utilizing SBOMs.