Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles

Autonomous vehicles are not merely cars with advanced engines; they are computers on wheels, where the safety of passengers and pedestrians depends entirely on lines of code. These machines rely on a complex software supply chain, a vast network of digital ingredients that developers stitch together to make the car see, think, and move. This chain includes the original code written by the car's manufacturer, but it also heavily depends on open-source software—freely available building blocks created by communities of programmers around the world. While this shared approach accelerates innovation and allows for rapid testing of new ideas, it introduces a unique danger: if a single piece of this shared software contains a hidden flaw, that weakness can spread through the entire system, potentially causing the vehicle to misinterpret its surroundings or fail to stop. As these vehicles move from research labs to public roads, ensuring the integrity of every digital component becomes a matter of life and death.

Researchers at the University of Alabama set out to examine the health of this digital foundation by looking directly at the code of three of the most prominent open-source autonomous vehicle platforms: Autoware, Apollo, and openpilot. These projects represent the cutting edge of self-driving technology, with Autoware and Apollo aiming for high levels of automation where the car drives itself, and openpilot focusing on driver assistance systems that help humans stay in control. The team treated these software repositories like a mechanic inspecting a complex engine, but instead of checking for rusted bolts, they used specialized scanning tools to hunt for digital cracks. They focused on two main areas: the code written by the project teams themselves, and the third-party libraries—pre-written code snippets borrowed from other sources—that these projects rely on to function.

The investigation revealed that while these platforms are powerful, they are not immune to the common errors that plague software everywhere. The researchers found that the code contained recurring patterns of weakness known as common weakness enumerations. In the code written in C and C++, languages often used for the heavy lifting of driving tasks, the scans identified issues related to memory management, such as buffer overflows, where data spills over its intended storage space and can corrupt the system. In the Python code, often used for higher-level planning and tools, the scans uncovered problems with how the software handles unexpected situations and inputs. One of the most frequent issues found across all three projects was improper handling of exceptional conditions, meaning the software sometimes failed to react correctly when things went wrong. Another major finding was the presence of command injection flaws, where a malicious actor could potentially trick the system into executing unauthorized commands.

The study also looked deep into the supply chain, examining the thousands of external packages these vehicles depend on. The results here were starkly different depending on the project. The Apollo platform, which is designed for large-scale production, was found to have a vast number of dependencies, and the scan identified 91 of these external components as having known security vulnerabilities. Among these were critical flaws in packages used for file handling and web rendering, some of which could allow an attacker to take control of the system or access sensitive data. In contrast, the openpilot project, which has a narrower scope, showed far fewer issues with its external dependencies, with only one vulnerable component detected. The Autoware project showed the least amount of trouble in this area, with the scans finding no known vulnerabilities in its third-party libraries at the time of the study.

Despite the differences in the number of flaws found, the core message from the research is clear: the software that powers these vehicles is currently exposed to significant risks. The researchers noted that nearly half of all cyberattacks in the automotive sector already exploit weaknesses in software systems, and their analysis confirms that these vulnerabilities exist in the very code that is meant to keep people safe. The study did not find that the systems are broken beyond repair, but rather that they are built on a foundation that requires constant vigilance. The authors suggest that security cannot be an afterthought; it must be woven into the development process from the very beginning. By using automated tools to continuously check for these flaws and by carefully managing the software components that are brought into the system, developers can reduce the risk of catastrophic failures. The work serves as a reminder that in an increasingly automated world, the safety of the machine depends on the security of its code.