1
Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems Dimitri Simon∗ , Badis Hammi∗ , Joaquin Garcia-Alfaro∗ , Hervé Debar∗ ∗ SAMOVAR, Télécom SudParis, Institut Polytechnique de Paris, 91120 Palaiseau, France
arXiv:2607.07226v1 [cs.CR] 8 Jul 2026
[email protected]; [email protected] joaquin.garcia [email protected]; [email protected]
Abstract—Software-defined vehicles (SDVs) are revolutionizing transportation by integrating complex, interconnected hardware, and software systems. This evolution introduces significant security challenges. We present a comprehensive security analysis for SDVs, focusing on software vulnerabilities. We note that existing vulnerability assessment tools fall short in addressing operating systems vulnerabilities, particularly when it comes to efficiently analyzing diverse software stacks in realistic environments. We present and release a vulnerability assessment solution that efficiently addresses these limitations. Our approach combines systematic vulnerability discovery, leveraging public Common Vulnerabilities and Exposures (CVE) databases, within a dockerized development environment that evaluates exploitability risks. The results reveal both breadth of potential threats and the practical constraints we faced during exploitation. We discuss the implications for industry and research, and propose directions for building more resilient SDVs.1 Index Terms—Software-Defined Vehicle (SDV), Vulnerability Scanner, Cybersecurity, Pentesting, Common Vulnerabilities and Exposures (CVE).
I. I NTRODUCTION The automotive industry is undergoing a radical transformation across both hardware and software domains. Architecturally, manufacturers are migrating from distributed legacy Electronic Control Units (ECU) toward zonal Electrical/Electronic (E/E) topologies and consolidated high-performance computers (HPCs) to accommodate the vastly increased data volumes generated by advanced sensors (e.g., cameras, radar, LiDAR, and so on) and domain controllers. Concurrently, the software landscape is shifting from proprietary, monolithic firmware toward the Software-Defined Vehicle (SDV)2 paradigm, where vehicles are increasingly built on open, Portable Operating System Interface (POSIX)-compatible platforms that support virtualization, containerization, and OverThe-Air (OTA) updates and software delivery, supplanting isolated vendor-specific stacks. This transition toward POSIXcompatible platforms has been driven by initiatives such as 1 The VERA source code, along with the associated proof-of-concepts (PoCs) and exploit implementations, is publicly available in a dedicated repository at: https://github.com/EternalDreamer01/vera 2 A Software-Defined Vehicle (SDV) is a vehicle in which the majority of functionality is implemented, managed, and continuously enhanced through software, allowing features to evolve independently of fixed hardware. In SDVs, software spans the entire vehicle ecosystem, from infotainment and connectivity to safety-critical and autonomous driving functions, enabling scalability, rapid feature deployment, and lifecycle updates.
Fig. 1: Hardware-software stack within next-generation SDVs
Automotive Grade Linux (AGL),3 Android Automotive OS (AAOS),4 and Red Hat In-Vehicle OS (RHIVOS).5 This convergence accelerates feature deployment and interoperability. more precisely, the adoption of POSIX-compliant architectures further enables portability across hardware platforms, simplifies integration of third-party software, facilitates reuse of open-source components, and streamlines development through standardised Application Programming Interfaces (APIs) and tooling. However, these advances also introduce new cybersecurity challenges, as increased connectivity, reliance on shared software layers, and broader ecosystem integration significantly expand the vehicle’s attack surface [1]. Notably, security vulnerabilities in next-generation vehicles,6 including SDVs and non-SDV platforms that adopt POSIX-compliant components (e.g., infotainment systems), can emerge at any layer of the vehicle’s stack, from application logic and middleware, through the operating system, hypervisor and drivers, down to firmware. Figure 1 depicts this hardware-software stack within next-generation vehicles. The combination of increased software complexity, heterogeneous integration of legacy and modern components, ubiquitous connectivity (cellular, V2X, Wi-Fi, Bluetooth), and reliance on OTA updates substantially enlarges the adversary surface and enables novel attack vectors.
3 https://www.automotivelinux.org/ 4 http://source.android.com/docs/automotive 5 https://www.redhat.com/en/blog 6 In the remainder of this paper, we use the term next-generation vehicle to refer to any vehicle that incorporates POSIX-compliant products or components.
2
A. Context and research questions POSIX-compatible operating systems and products have long accumulated large numbers of Common Vulnerabilities and Exposures (CVEs) in traditional computing and industrial contexts. The aforementioned adoption of POSIX architectures into SDVs will significantly expand traditional vehicle’s attack surface [1], mainly due to increased connectivity, reliance on shared software layers, and broader ecosystem integration. Motivated by such potential threat, we investigate the following research questions: (1) to what extent do disclosed CVEs for POSIX-compatible ecosystems, including the virtualization, OSes, middleware and applications, actually affect vehicle software stacks; (2) whether those CVEs remain exploitable in the constrained and Original Equipment Manufacturer (OEM)-hardened environments of modern vehicles; and (3) how successful exploitation would affect vehicle safety and security given the highly interconnected architecture of automotive platforms. Answering these research questions requires moving beyond catalogue-style vulnerability listings to measured, penetration-testing-driven validation across software layers. This paper is driven by that objective and aims to empirically assess the presence, exploitability, prerequisites, and impact of POSIX CVEs in next-generation vehicles contexts.
realistic testing in next-generation vehicles’ development lifecycles and practical frameworks to evaluate real exploitability rather than purely static enumeration [12]. C. Contributions of this work This study addresses the identified research gaps by: 1) Providing a comprehensive survey of automotive operating systems, middleware, and deployment architectures, with a systematic mapping of platforms to roles, common use cases, and assurance constructs. 2) Providing an empirical assessment of how POSIX/Linux CVEs propagate into vehicle stacks and their practical exploitability via controlled penetration tests. 3) Releasing a vulnerability scanning framework more specifically designed for automotive POSIX-based operating systems. 4) Integrating a static vulnerability discovery with controlled penetration-testing validation to evaluate the practical exploitability of CVEs across software layers. 5) Releasing experimental artifacts and results to foster reproducibility, transparency, and comparative analysis in future research. II. BACKGROUND AND SYSTEMATIZATION OF SDV
B. Research gaps and motivation Uncertainty about the relevance and exploitability of POSIX/Linux CVEs in vehicle contexts: the automotive industry is actively migrating toward POSIX-based platforms (e.g., AGL, Android Automotive variants, Red Hat In-Vehicle OS), which exposes vehicle software to a broader ecosystem of libraries and kernel surfaces. At the same time, POSIX/Linux ecosystems continue to generate large numbers of CVEs [2], with a recent surge in reported kernel CVEs,7 raising the question whether vulnerabilities discovered in traditional computing environments are present, exploitable, or impactful in next-generation vehicles’ configurations. The mapping from a disclosed CVE to a practical, vehicle-level exploit is nontrivial and under-explored [3]. Tooling limitations to inspect/parse reports: existing vulnerability scanners and frameworks were largely designed for scanning, without considering parsing (filter, sort, merge reports) and the relevance of a CVE (available exploits, execution conditions for each exploit, type e.g, RCE, LPE, etc.). Recent evaluations of container and image scanners [4] [5] demonstrate this inconsistent coverage. Shortage of penetration-testing–driven, cross-layer exploitability studies for next-generation vehicles: while the automotive security literature contains numerous componentfocused analyses (ECU, firmware auditing, telematics investigations) [6]–[8], comprehensive studies that combine systematic vulnerability discovery with end-to-end penetration testing across the full software stack of next-generation vehicles (applications → middleware → OS/hypervisor → firmware → boot) remain scarce [9]–[11]. Hence, there is a need for
COMPONENTS AND SECURITY
A. Standardized frameworks for vulnerability identification and risk assessment Disclosed vulnerabilities are catalogued in public repositories such as Common Vulnerabilities and Exposures (CVE), US National Vulnerability Database (NVD), and EU Vulnerability Database (EUVD).8 Vulnerability scanners report vulnerabilities with their status on the target system (e.g., fixed, not-fixed, and unknown). This feature is called tracking mechanism: the scanner links software artifacts (packages, libraries, commits, or build recipes) to known vulnerabilities over time, typically by maintaining mappings between component identifiers/versions and CVE entries, and updating these mappings as new vulnerabilities and patches are published. This information helps assess the effective exposure of the system and reduces false positives. However, there is no reliable mechanism to track installed patches or software updates, making it impossible to accurately determine the true remediation state of vulnerabilities on the target system. The severity of an identified vulnerability is typically expressed using the Common Vulnerability Scoring System (CVSS), which produces a standardized numeric score on a 0-10 scale: Low: 0 – 3.9; Medium: 4 – 6.9; High: 7 – 8.9; and Critical: 9 – 10. Different vendors or authorities may assign distinct CVSS vectors for the same vulnerability, which motivates the common practice of reporting the maximum observed score across trusted sources. 8 http://cve.org, http://nvd.nist.gov, http://euvd.enisa.europa.eu/ 15 Hazard Analysis and Risk Assessment 16 Verification and Validation 17 Failure Modes, Effects, and Diagnostic Analysis
7 https://tuxcare.com/blog/
18 Programmable Electronic
3
TABLE I: Standards commonly applied to operating systems and platforms in next-generation vehicles Standard
Scope / Target
ISO 26262
Road vehicles
ISO/PAS 8926
Road vehicles
ISO/SAE 21434
Road vehicles
IEC 61508
Generic E/E /PE12 systems across industries IT products and components
ISO/IEC 15408-5
Typical output / assessment ASIL assignment, safety concept, 9 FMEDA, HARA,10 11 V&V evidence Guidance for integrating legacy/third-party software into ISO 26262 workflows CAL, cybersecurity threats in vehicles across their lifecycle. SIL requirements, validation and verification evidence EAL, protection profiles, certification reports
Levels
Relevance to SDV
Primary focus
Regulatory status
ASIL A–D
High – safety-critical ECUs and system-level safety
Functional safety
Widely adopted industry standard; commonly referenced by OEMs and regulators (not a law)
N/A
High - reuse of libraries and legacy modules in SDV stacks High – Cybersecurity threats in vehicles
Software-integr. cybersecurity
Informative guidance; complements ISO 26262
Process-oriented cybersecurity
Standard widely adopted ; CAL certification less exploited
Medium – useful when porting industrial modules or using industrial components Medium – security assurance for OS components and modules
Functional Safety
International standard used across industries; often referenced in industrial contexts Recognized certification framework; adopted by national schemes for procurement and assurance
CAL 1–4
SIL 1–4
EAL 1–7
To assist prioritization, practitioners increasingly use the Exploit Prediction Scoring System (EPSS), which provides a probabilistic estimate (0–1) of the likelihood that a given vulnerability will be exploited in the wild within the next 30 days. EPSS complements CVSS by adding a data-driven notion of exploit likelihood to severity metrics. Vulnerability and product records are correlated using standardized naming such as the Common Platform Enumeration (CPE),13 which reduces ambiguity when mapping CVEs to specific products, versions, and packages. Prior empirical work has shown that severity scores alone are an imperfect proxy for real-world exploitability and risk. For example, studies comparing CVSS and observed exploitation find only limited predictive power, underscoring the need to combine severity, exploit-likelihood (EPSS), provenance, and contextual factors when prioritizing vulnerabilities [13]. In addition to CVSS and EPSS,14 practitioners often consider qualitative factors such as the presence of active real world exploitations. This can be known from (1) the Known Exploited Vulnerabilities Catalog (KEV Indicator/Catalog)15 and (2) the availability of exploit code, commonly tracked using threat intelligence feeds and databases (e.g., Exploit Database (ExploitDB)16 and GitHub repositories hosting proof-of-concept exploits). During our study, we particularly considered broad critical classes of vulnerabilities and attack vectors that represent major threats to next-generation vehicle systems regarding passengers’ safety and privacy, as listed below: Remote Code Execution (RCE): a vulnerability that allows an attacker to execute arbitrary code on a target system remotely, often without prior authentication, potentially leading to full system compromise. Local Privilege Escalation (LPE): sometimes referred as Elevation of Privilege (EoP), is a flaw that enables a local user or process to elevate privileges, bypassing restrictions on access to sensitive data or administrative actions. 13 https://nvd.nist.gov/products/cpe 14 https://www.first.org/epss 15 https://www.cisa.gov/known-exploited-vulnerabilities-catalog 16 https://www.exploit-db.com/
Security
Such vulnerabilities can turn limited compromises into complete system control. Sandbox or Virtual Machine Escape (SBX/VME): a vulnerability that permits code execution or data access on the host machine from within a sandboxed environment (e.g., browser sandboxes, Docker containers, or virtual machines), undermining isolation guarantees. B. Safety and security standards Evaluating operating system security in automotive and Advanced Driver-Assistance Systems (ADAS) platforms often involves compliance with international safety and security standards from ISO and IEC. These standards provide structured methodologies for assessing risk and ensuring that systems meet rigorous safety and assurance requirements. Table I provides a summary of the main standards. ISO 26262 [14] is a functional safety standard designed specifically for road vehicles. It introduces Automotive Safety Integrity Levels (ASIL) from level A to level D, where ASIL A represents minimal risk mitigation requirements and ASIL D denotes the highest safety rigor and most stringent engineering measures. ISO/PAS 8926 [15] extends ISO 26262 by offering guidance on integrating pre-existing software components or architectural elements not originally developed under ISO 26262. It addresses challenges of reusing legacy or third-party software within safety-critical automotive systems. ISO/SAE 21434 [16] is a process-oriented standard for automotive cybersecurity. It specifies the level of rigor required in cybersecurity activities throughout the vehicle’s lifecycle. It introduces Cybersecurity Assurance Level (CAL) from level 1 to level 4, where CAL 1 represents basic cybersecurity design and CAL 4 the highest level of cybersecurity measures. The CAL guides the cybersecurity activities from concept through development, production, operation, maintenance, and decommissioning. IEC 61508 [17] is a generic cross-industry functional standard for electrical, electronic, and programmable electronic safety systems. It defines Safety Integrity Levels (SIL 1-4), with SIL 1 indicating basic risk reduction measures and SIL 4 representing the highest level of risk mitigation.
4
ISO/IEC 15408-5 (Common Criteria) [18] specifies Evaluation Assurance Levels (EAL 1–7), which indicate the depth and rigor of security evaluation performed on IT products. Higher EALs require more extensive documentation and testing but do not inherently guarantee higher security, only greater assurance through structured evaluation. Table II summarizes prominent automotive virtualization platforms, operating systems and middleware together with their security/safety posture based on their formal certification levels. Notably, several widely adopted platforms like AGL, Eclipse S-CORE, and Zephyr, do not currently possess any recognized formal automotive certification. Hardware platforms can also be certified. For example, the Snapdragon 855 (SM8150) platform has been certified EAL 4+. TABLE II: Automotive OS, middleware and hypervisors: EAL (ISO/IEC 15408-5), ASIL (ISO 26262), SIL (IEC 61508) and CAL (ISO/SAE 21434) status. Hypervisor / OS / Middleware QNX Hypervisor QNX Neutrino VxWorks 7 Wind River Helix Wind River Linux INTEGRITY Multivisor INTEGRITY PikeOS Hypervisor PikeOS Native LynxSecure LynxOS Mentor Embedded Hypervisor Mentor Nucleus COQOS Hypervisor DRIVE OS 6 DRIVE OS 5 RHIVOS Eclipse S-CORE Zephyr Ubuntu 18.04
Vendor BlackBerry
Wind River Green Hills
SYSGO Lynx Software Technologies
Siemens OpenSynergy NVIDIA Red Hat Eclipse Foundation Zephyr Project Canonical
EAL None 4+ 6+ None None None 6+ 5+ 5+
ASIL D D D D None D D D D
SIL 3 3 3 3 None 3 3 3 3
CAL 2 2 None None None None 4 None None
None
D
3
None
None None None None None None None None None 2+
D D D D D B B None None None
3 3 3 3 None None None None None None
None None None None 2* 2* None None None None
TABLE III: Vehicle models, their IVI/telematics OS and SoC, and safety/ADAS OS by year of any change. Year 2014 2015 2016 2017 2019 2019 2020 2020
Brand SoC Tesla Honda Cadillac Tesla Hyundai Tesla General Motors A3960 Mitsubishi SM8150
IVI/Telem. OS Linux Android 4.0 AGL; AAOS Linux AGL Linux AGL; AAOS 29 AGL
S/A. OS DRIVE OS QNX DRIVE OS; QNX VxWorks; QNX DRIVE OS; VxWorks; QNX 2020 Polestar A3960 AAOS DRIVE OS; QNX 2020 XPeng Linux DRIVE OS; QNX 2020 Volvo A3960 AAOS DRIVE OS; QNX 2020 Volkswagen AGL; AAOS DRIVE OS; QNX 2023 Renault SM8150 AGL; AAOS 32 QNX 2021 Ford AGL; AAOS DRIVE OS; INTEGRITY; VxWorks; QNX 2021 Lucid Motors AAOS DRIVE OS; QNX 2021 Mercedes-Benz AGL DRIVE OS; QNX 2021 NIO AAOS DRIVE OS; QNX 2022 Mitsubishi SA8195P AGL; AAOS 32 DRIVE OS; INTEGRITY; VxWorks; QNX 2022 Nissan SA8155P AGL; AAOS 32 DRIVE OS; QNX 2022 Subaru SA8155P AGL; AAOS QNX 2024 BYD SA8155P AAOS 34 DRIVE OS; QNX 2022 XPeng Linux DRIVE OS; QNX 2022 Toyota SA8155P AGL DRIVE OS; INTEGRITY; VxWorks; QNX 2023 General Motors SA8155P RHIVOS; AGL; VxWorks; QNX AAOS 32 2023 Honda SA8155P AGL; AAOS 32 DRIVE OS; QNX 2023 Tesla Linux 2023 Polestar SA8155P AAOS 32 DRIVE OS; QNX 2023 Porsche AAOS DRIVE OS; QNX 2023 BMW SA8155P AGL; AAOS DRIVE OS; VxWorks; QNX 2022 Hyundai AAOS QNX 2023 Polestar SA8155P AAOS 33 DRIVE OS; QNX 2024 General Motors SA8195P RHIVOS; AGL; VxWorks; QNX AAOS 34 2024 Volvo SA8155P AGL; AAOS DRIVE OS; QNX 2025 NIO AAOS QNX 2025 Renault SM8150 RHIVOS; AGL; QNX AAOS 32 2026* Cadillac RHIVOS; AGL; QNX AAOS 2026* General Motors RHIVOS; AGL; DRIVE OS; VxWorks; AAOS QNX 2026* Tesla Linux Legend — SoC: Infotainment SoC (System-on-Chip). IVI/Telem. OS: Infotainment and Telematics OS. S/A. OS: Safety/ADAS OS. Linux: Linux-based.
*NVIDIA DRIVE OS is certified to ISO 21434 via QNX.
C. Automotive OS and middleware platforms It is important to clearly distinguish middleware solutions from operating systems, as these two software layers fulfill fundamentally different roles within the vehicle software stack. Middleware provides runtime services and communication abstractions between the OS and applications (e.g., message buses, Remote Procedure Calls (RPC), and lifecycle management), whereas the OS is responsible for hardware abstraction, resource management, process scheduling, and low-level services. Additionally, a virtualization layer may be deployed above the hardware to host and isolate multiple operating systems, thereby enhancing security and system robustness. Generally, virtualization platforms, operating systems and middleware are typically combined to leverage complementary strengths (e.g., real-time determinism, isolation, rich application ecosystems, or small-footprint operation) and to satisfy the varied requirements of infotainment, telematics, ADAS, and
safety-critical subsystems. Table IV summarizes the preferred use cases of the main platforms. In Table III, we present a list of vehicle models alongside the OSes and middleware they implement. Additional details regarding their specific use cases are provided in Table IV. Mapping these components to the architecture illustrated in Figure 1, we classify them as follows: Systems-on-Chip (SoCs) is the hardware layer. QNX Hypervisor, Wind River Helix, and PikeOS Hypervisor serve as virtualization platforms. • QNX Neutrino, INTEGRITY, and VxWorks are real-time operating systems (RTOS) that support virtualization and provide middleware integrations, effectively spanning the virtualization, OS, and middleware layers. • AAOS, AGL, DRIVE OS, and RHIVOS are operating systems that incorporate middleware capabilities, bridging the OS and middleware layers. • ROS2, AUTOSAR, and Eclipse S-CORE operate strictly at the middleware layer. • •
5
TABLE IV: Virtualization platforms, OS and middleware preferred use cases. Vendor
Virtualization Platform
Black Berry
QNX Hypervisor
Wind River
Wind River Helix
Apex.AI NVIDIA Green Hills SYSGO Siemens Lynx Software Technologies
INTEGRITY Multivisor PikeOS Hypervisor Mentor Embedded Hypervisor LynxSecure
OpenSynergy
OS QNX Neutrino VxWorks WindRiver Linux Apex.OS NVIDIA DRIVE OS INTEGRITY PikeOS Native Nucleus LynxOS
COQOS Hypervisor
Red Hat Google Linux Foundation Eclipse Foundation Zephyr Project
RHIVOS AAOS AGL
OS & Middleware Purposes Safety AI inf. ✓ ✓ ✓ ✓ Apex.Grace ✓ ✓ ✓ ✓ ✓ ✓ Blue SDK RapidLaunch SDK Radio Tuner SDK ✓
Middleware
Eclipse S-CORE Zephyr
AUTOSAR Foundation Open Robotics
AUTOSAR Classic AUTOSAR Adaptive ROS2
Info.
Telem. ✓ ✓
✓
V2X, Connect. ✓ ✓ ✓ ✓
✓ ✓ ✓ ✓
✓
✓
✓
✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓
✓ ✓ ✓ ✓
✓ ✓
✓ ✓ ✓ ✓
Legend — AI inf.: AI inference Info.: Infotainment Telem: Telematics V2X, Connect.: V2X Connectivity
To our knowledge, our work is the first to systematically present software-stack component certifications used within SDVs, and to determine and report vehicle models’ SoCs and operating systems based on company disclosures. Although it is not exhaustive, this table offers a snapshot of the diverse platforms currently used in the automotive sector. The challenge in compiling this information lies in the proprietary nature of automotive systems, as manufacturers often keep details about their OS and middleware configurations confidential. Furthermore, frequent updates to software stacks, customizations per model, and the lack of standardized reporting make it difficult to provide a comprehensive overview. We quickly present the benchmarked systems. Eclipse S-CORE17 is an open-source initiative that aims to provide a safe core stack (middleware) for software-defined vehicles and explicitly targets safety-critical in-vehicle domains such as ADAS. The project is actively developing safety artefacts and has been the subject of recent independent safety assessments, but there is no publicly documented ISO 26262 certification at this time. Zephyr18 is a real-time operating system originally designed for resource-constrained devices. Recently, it has attracted interest for use in next-generation vehicle subsystems (e.g., low-latency controllers and safety-adjacent components). While not yet broadly certified for automotive use, there are ongoing efforts in the community and industry to align Zephyr with automotive safety and dependability goals (including workstreams towards ISO 26262 and IEC 61508 conformance) [19]. Red Hat In-Vehicle OS (RHIVOS)19 is positioned as a mixed criticality platform for both safety-critical applications
like ADAS and non-safety critical like infotainment. In practice, early deployments and discussions emphasize its use in infotainment and application hosting, although RHIVOS is explicitly intended to support a wider set of vehicle functions through the AutoSD initiative.20 VxWorks21 is a real-time operating system (RTOS) designed for embedded and safety-critical systems. VxWorks modularizes core services into isolated components, enabling configurable footprints and easier updates. It supports multicore SMP, mixed-criticality applications, POSIX APIs, and advanced networking and security stacks. Deterministic scheduling, low-latency interrupt handling, and certified safety/security extensions make it common in aerospace, defense, industrial control, medical devices, and sometimes in vehicles. QNX Neutrino22 is a microkernel-based RTOS built for reliability and fault isolation in embedded systems. Its minimal microkernel provides IPC, scheduling, and interrupt management; drivers and services run in user space, reducing systemwide crashes. It offers POSIX compatibility, deterministic real-time performance, and strong filesystem/network stacks. Widely used in automotive infotainment, industrial automation, and safety-critical domains, QNX emphasizes modularity, fast boot, and system resiliency. TeslaOS23 – the publicly shared “TeslaOS” materials primarily refer to Tesla’s infotainment/system Linux stack (NVIDIA Tegra–based) used for media, navigation, UI, and vehicle-connected services. It includes kernel sources, drivers, and user-space components for the center display and media domain, with OTA updates and tight hardware integration. The proprietary vehicle-control and autonomy software remains 20 https://sigs.centos.org/automotive/about/
17 https://eclipse-score.github.io
21 https://www.windriver.com/products/embedded/vxworks
18 https://zephyrproject.org/safety-and-zephyr-rtos/
22 https://www.qnx.com/products/intl/neutrino rtos/
19 https://www.redhat.com/en/resources/in-vehicle-operating-system-detail
23 https://github.com/teslamotors/linux
6
separate and is not included in the public infotainment repository. Android Automotive OS (AAOS)24 is Google’s in-vehicle operating system version built from Android to run directly on car hardware. It provides native vehicle integration for instrument clusters, media, navigation, and voice assistant, plus access to the Android app ecosystem tailored for automotive use. Automotive Grade Linux (AGL)25 is an open-source Linux-based software stack for automotive applications, collaborative-developed by OEMs and suppliers. AGL provides reference implementations for infotainment, telematics, instrument clusters, and domain controllers using a common middleware layer, flexible app framework, and standardized APIs. Its open governance accelerates integration, portability across hardware, and ecosystem innovation, enabling manufacturers to build customizable, connected vehicle features while reducing duplicated engineering effort. ROS 226 is a modular, open-source robotics middleware framework designed for distributed, real-time-capable robotic systems. It provides publish/subscribe communication, lifecycle management, and QoS-configurable DDS-based transports for reliable inter-process messaging across heterogeneous hardware. ROS 2 emphasizes portability, security, and deterministic behavior for production use, with rich libraries for perception, planning, and control. It is widely adopted in research, industrial robots, and autonomous vehicles for integrating sensors, algorithms, and system orchestration. We can pragmatically distinguish platforms used for safety/ADAS from those primarily intended for infotainment: • Safety-critical platforms: QNX Neutrino, VxWorks, INTEGRITY, and Red Hat In-Vehicle OS (RHIVOS) are Real-Time Operating Systems (RTOS) or seperation kernels that are widely used for safety-critical functions. PikeOS Hypervisor & Native in particular is a hypervisor and RTOS designed to consolidate multiple subsystems with strong isolation guarantees. NVIDIA DRIVE OS is a vehicle compute platform used for AI inference workloads. It is also often positioned with safety considerations for those domains. • Non-safety-critical platforms: Automotive Grade Linux (AGL), TeslaOS, Android Automotive OS (AAOS) and other Android variants are commonly adopted for infotainment, telematics, and rich application hosting (user experience, media, app ecosystems). D. Automotive OS deployment Building upon the operating systems and middleware platforms introduced in Section II.C, this subsection details how these specific components are practically deployed and isolated across the lower layers of the architectural stack presented in Figure 1. Because modern automotive platforms rely on a complex mix of virtualization technologies, operating systems, and middleware, robust deployment architectures are 24 https://developer.android.com/training/cars/platforms/automotive-os 25 https://www.automotivelinux.org 26 https://www.ros.org
essential. In Figure 2, we illustrate three canonical deployment architectures for hosting infotainment and ADAS workloads.These architectures demonstrate how the foundational hardware and OS layers from Figure 1 are configured in nextgeneration vehicles to embed and isolate multiple operating systems securely. To demonstrate how these distinct architectural layers are implemented in practice, Table III details the hardware and operating system combinations utilized in real-world vehicles, while TableIV categorizes the preferred use cases across the virtualization, OS, and middleware platforms. High Performance Computer (HPC) is typically the Host OS, and the ADAS platform might be directly on the same Electronic Control Unit (ECU) as the HPC whereas Infotainment runs in a container. Next-generation vehicles typically combine hardened RTOSes or separation kernels for safety-critical subsystems with Linux/Android-based platforms for infotainment, connected via middleware standards to meet mixed-criticality, performance and ecosystem requirements. Physical isolation (cf. Figure 2.a): distinct ECUs or separate compute platforms host different domains (e.g., infotainment versus ADAS). Isolation is enforced by hardware separation and dedicated Input/Output, which simplifies safety and security arguments and reduces cross-domain attack surface at the cost of increased weight, cost and reduced resource sharing. • Physical isolation with containerization (cf. Figure 2.b): still distinct ECUs or separate compute platforms for different domains. However, the containerization adds a security layer. • Virtualized isolation (cf. Figure 2.c): multiple domains are consolidated onto a single hardware platform using hypervisors or container runtimes. Logical partitions (VMs or containers) present independent execution environments while sharing the same physical resources. This architecture improves resource use and maintainability but introduces evasion risks, misconfiguration, and interpartition side channels. •
Although consolidation reduces cost and improves agility, it also amplifies attack surface and cross-domain impact (e.g., sandbox or hypervisor escape, cross-partition escalation, and so on). Empirical automotive security research has repeatedly illustrated how shared or exposed subsystems can lead to system-wide compromise, motivating runtime monitoring and layered defenses in consolidated architectures [20] [21]. III. T HREAT MODEL In this section, we define the threat model for next generation vehicles, focusing on adversaries targeting the software stack, particularly the POSIX-based operating systems and their components. Our model is structured around adversary goals, capabilities, and the vehicle’s attack surface, following established cybersecurity frameworks [22] [23]. Focusing vulnerability analysis on the OS, middleware, virtualization, and application layers addresses the software stack where major threats emerge in next-generation vehicles—particularly given the integration of POSIX components
7
(a)
(b)
(c)
Fig. 2: Deployment architectures for infotainment and ADAS: (a) physical isolation (per-ECU), (b) physical isolation with containerization, (c) virtualized isolation using hypervisors/containers with software/hardware partitioning.
in infotainment systems [24] [25] and enables faster vulnerability discovery and remediation by leveraging established POSIX-compatible security tools. A. Adversary goals An adversary’s primary objectives can range from simple mischief to life-threatening attacks. We consider the following goals: Compromise vehicle safety: interfere with safety-critical functions such as braking, steering, or acceleration. This is the most severe threat [26]. • Data theft: steal sensitive personal or vehicle data, including location history, contact information, or telemetry data that could reveal driving habits [23]. • Unauthorized access and control: gain unauthorized control over vehicle functions, e.g., unlocking doors, starting the engine, or settings manipulation [27]. • Financial gain: deploy ransomware to disable the vehicle until a payment is made, steal subscription-based services [28] or, being the owner of the vehicle, bypass toll collection systems’ payment [29]. 27 • Large scale disruption: execute a fleet-wide attack, potentially causing widespread traffic disruption or reputational damage to the manufacturer [30]. •
The automotive industry’s most important problem is to ensure that fleet-wide attacks cannot take place, or at least with minimal consequences [31] [32]. Such a scenario could lead to a whole fleet of vehicles being taken over remotely and used as a terrorist weapon or, for a mass theft of vehicles and even the sale of stolen user data. B. Adversary capabilities and access We classify adversaries based on their skill level, resources, and the type of access they have to the vehicle [26]. Remote attacker: this adversary has no physical access to the vehicle and attempts to compromise it over a wireless interface (e.g., cellular, Wi-Fi, Bluetooth). We distinguish between: • Low sophistication: uses publicly known vulnerabilities and exploit scripts. Their goal is often data theft or minor control functions [27]. 27 A malware compromises large numbers of IoT devices or vehicles
High sophistication: possesses the resources to discover zero-day vulnerabilities, holding deep understanding of automotive systems. Their goals can include large-scale disruption or persistent espionage [23]. Physical attacker: this adversary has direct physical access to the vehicle’s internal systems. This category includes: • Malicious insider: a mechanic, technician, or employee with legitimate access who abuses their privileges [33]. • Technically skilled owner: an owner who attempts to modify their vehicle’s software, potentially introducing vulnerabilities unintentionally [26]. • Thief: an attacker who gains temporary physical access to an unattended vehicle to connect to physical ports like the OBD-II or USB [26]. In our work, we aim to address both physical attackers and remote attackers, as the shift to connected, POSIX-based systems makes this vector increasingly probable [27]. •
C. Attack surface The attack surface of a next-generation vehicle is extensive and spans hardware and software layers [34]. We identify the following key areas [23]: • Connectivity interfaces: any component that communicates with the outside world is a potential entry point. This includes cellular (4G/5G) modems, Wi-Fi and Bluetooth radios, and V2X communication units [26]. • Infotainment system (IVI): become complex systems, running third-party applications and web browsers, they represent a significant portion of the attack surface. A vulnerability in an application or the underlying OS (e.g., AGL or AAOS) can be an initial entry point [28]. • Over The Air (OTA) updates: the mechanism for delivering software updates is a high-value target. A compromised OTA update could lead to a fleet-wide attack [30]. • Physical ports: exposed interfaces like the OBD-II diagnostic port and USB ports provide a direct line of access to the vehicle’s internal networks [26]. • Supply chain: vulnerabilities introduced via compromised third-party software libraries or hardware components from suppliers. The use of open-source software in POSIX-based systems makes this a critical concern [33]. This threat model specifies the adversarial assumptions and attack surfaces considered, thereby guiding both the design
8
choices of VERA and the criteria used to evaluate its effectiveness. By systematically identifying CVEs in the vehicle’s software stack, our tool helps to mitigate these threats by enabling developers to find and patch vulnerabilities before they can be exploited [23].
Our Suite Exploits
MITRE DB Search
Parser
Search
IV. T HE VERA SUITE A. Architecture We present in this section our Vulnerability Exposure and Reporting Analysis (VERA) suite, a lightweight, offlinecapable, and scalable scanner designed to detect CVEs across container images, Android devices/emulators and product/package inventories. VERA is optimized for batch analyses (lists of images or products). The scanner integrated into the suite leverages a local CVE dataset: MITRE’s database, CVE List V528 and combines pip-audit,29 the Docker Software Development Kit,30 and Dask31 for parallel execution to deliver fast, configurable, and reproducible results. We designed VERA’s experimental testbed using Docker containers because they provide an optimal environment for scalable, automated, and easily reproducible vulnerability scanning. While we acknowledge that isolated containers do not fully replicate a production hardware deployment, they perfectly preserve the crucial elements required to validate our semi-white-box approach: the exact filesystem, installed packages, and software configurations. Consequently, this environment ensures high fidelity for our core contributions (vulnerability detection, parsing, and filtering) while the impact of hardware-specific defenses on runtime exploitability remains for future work. Figure 3 describes VERA’s architecture. Other Scanners refers to tools like Vanir32 or CVE Binary Tool (CBT)33 . To use the built-in scanner Scanner, it has to (1) create a new database Formatted DB in a custom standard format based on MITRE DB, to eventually (2) scan a Docker image. It is also possible to use another scanner cf. Other Scanners, where CBT would allow to scan an Android emulator through Android Debug Bridge (ADB), Grype can be used to scan a Docker image, Vanir and Yocto’s cve-check34 can be used to scan Android-based and AGL source code. These scans can be realised by another tool we made in order to automate eventual pulling from ADB, and ensure the right configurations are used for the scanners e.g output format, path to save. (3) All the scan results are saved under a specific directory cf. Scan Results where (4) they can be parsed by our tool Parser. Parser allows to merge, filter and sort results, here is done the filtering to exclude unexploitable CVEs in the context of next-gen vehicles. It also allows to see available exploits for each CVE, 28 https://github.com/CVEProject/cvelistV5 29 https://pypi.org/project/pip-audit/ 30 https://docs.docker.com/reference/api/engine/sdk/ 31 https://www.dask.org/ 32 https://github.com/google/vanir 33 https://github.com/ossf/cve-bin-tool 34 https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html
Mount
Formatted DB Parse/update
Read
Runner
Update/read
Save/update
Scanner Exploit
Scan Results
Analyser Save
Scan/Update OS
Scan Scan
Other Scanners
Scan
Read only
Write only
Read & Write
Fig. 3: Architecture of VERA.
(5) so Analyser can more particularly be used to ensure a vulnerability is present, searching a specific symbol, and see by which binaries it is called, and (6) eventually download an exploit under a specific directory Exploits that can be later mounted in one Docker image through Runner. B. Methodology Referring back to Figure 1, our framework applies to any OS, middleware, and application layer, and can also be used with POSIX-compliant virtualization platforms such as QNX Neutrino or INTEGRITY. More precisely, our solution would scan binaries (including libraries) through Grype, CBT, or our built-in scanner, and for repo scanners through Vanir and cve-check for Android and Yocto-based OS. Then, filtering removes package classes that would be meaningless in the context of next-generation vehicles, especially (1) non-sudo command-line utilities, or softwares that cannot lead to a privilege escalation, or remote code execution in an automotive setting (e.g apt, curl, git, ssh); or (2) developer toolchains and interpreters (e.g gcc, cmake, perl). Indeed, we position ourselves as an attacker that have the same capabilities as on a genuine vehicle, where a victim does not have a Command Line Interface (CLI), excluding all CLI tools except sudo commands as an attacker who gained access could exploit them for a later privilege escalation (LPE). It still remains possible to view these filtered packages, for instance, an attacker might
9
want to see GCC vulnerabilities in order to bypass Address Space Layout Randomization (ASLR). Therefore, this filtering shall be seen more as a helper for potential vulnerabilities directly exploitable. The proposed framework is comprehensive because beyond broad identification, it incorporates environment-specific validation through a dockerized setup that mirrors realistic conditions, enabling reproducible and scalable testing. This combination of vulnerability coverage, prioritization, exploitability evaluation, and cross-stack applicability allows the framework to reveal both the breadth of potential threats and the practical constraints that shape real-world attack feasibility. By integrating these components into a single workflow, the framework delivers a holistic view of SDV security exposure that existing tools — typically limited to scanning — cannot achieve. Figure 4 describes the main workflows associated to VERA. For simplicity, the figure omits configuration options and OS image updates. Each updatable OS image, including its packages, was upgraded to the latest available versions and then scanned, as summarized in Table IX. Android and Yocto-based images could not be upgraded and were therefore analyzed in their original form (Table X). The processing pipeline is as follows: 1) Inputs: accepts Docker images, package lists or package files as the analysis seed. 2) Normalization and preprocessing: parses, minify and normalize package/version traces. More precisely, helper scripts extract package lists from images or host outputs and convert them to the canonical format. 3) Systematic evaluation and scoring: For each detected issue, the pipeline attaches canonical severity metadata when available (e.g., CVSS vector/score from the CVE record). If no CVSS is present, VERA queries authoritative sources (e.g. NIST and vendor advisories such as Red Hat). 4) Results generation: outputs JSON structured results containing matched CVEs, their scores CVSS and EPSS. 5) Inspection and reporting: provides lightweight inspection utilities (e.g., parser.sh inspect, parser.sh table) for summaries, with the possibility to filter by severity, ecosystem, package name or type, and exclude CVEs once reviewed (based on the directory inspectignore). 6) Assess Exploitability: VERA can analyse a container OS (e.g., symbols, changelogs, SELinux configuration) to assess CVEs exploitability and identify false positives. Our solution yields several practical advantages: (1) VERA is not just a scanner, but a suite of tools, that filters, sorts and prioritizes CVEs; (2) It provides functionality to scan layered/Open Container Initiative (OCI) container images or Android emulator directly; (3) it provides guidance to assess exploitability, in addition to discovering online exploits.
TABLE V: Simple package filtering. Pre: No filtering, Flt: Filtering applied, Diff: Difference between raw result and filtered result. OS
Pre
Flt
Diff
Eclipse S-CORE Ubuntu 22.04 Ubuntu 20.04 VxWorks 7 VxWorks 7 ROS2 QNX Neutrino Zephyr TeslaOS AutoSD ROS2 AAOS 34 Android 32 Android 30 AGL
9 22 22 77 100 100 193 280 321 331 160 634 757 1217
8 13 13 33 51 56 91 243 129 281 159 627 749 1203
1 9 9 44 49 44 102 37 192 50 1 7 8 14
TABLE VI: CVEs classes by OS. RCE: Remote Code Execution, LPE: Local Privilege Escalation, ID: Information Disclosure (cause data leakage), DoS: Denial of Service (cause disruption). OS
RCE
LPE
ID
DoS
Unknown
Eclipse S-CORE Ubuntu 22.04 Ubuntu 20.04 VxWorks 7 VxWorks 7 ROS2 QNX Neutrino Zephyr TeslaOS AutoSD ROS2 AAOS 34 Android 32 Android 30 AGL
2 4 4 7 8 10 10 20 29 70 14 63 87 226
0 1 1 4 7 6 8 47 2 34 81 307 337 110
1 3 3 2 5 3 8 63 30 28 25 148 202 77
3 3 3 11 17 19 42 85 42 94 34 97 102 614
2 2 2 9 14 18 23 28 26 55 5 12 21 176
VERA. Table VIII summarizes the repo scanners we used for Android and Yocto-based OSes. All tracking-based scanners (e.g., Grype35 , OSV36 or Trivy37 ), which rely on conventional vulnerability databases, are primarily designed to analyze package-based systems and built operating system images for which component metadata and versioning information are available through standard package databases or management mechanisms (such as apt, rpm, or dpkg) or via Software Bills of Materials (SBOMs). These tools perform vulnerability attribution by matching discovered package names and versions against curated vulnerability feeds. However, they cannot be directly applied to Android and Yocto-based operating systems using their default tracking mechanisms, as these platforms rely on fundamentally different build architectures and deployment models that do not preserve standard package database in the final system image. As a result, vulnerability assessment for Android and Yocto typically requires analysis at the source level rather than at the level of the built image. In this context, Vanir is a vulnerability scanner developed by Google specifically for
C. Complementary scanners Table VII summarizes the pros and cons of the scanners the most used by the community, and compare them to our tool
11.1% 40.9% 40.9% 57.1% 49.0% 44.0% 52.8% 13.2% 59.8% 15.1% 0.6% 1.1% 1.1% 1.2%
35 https://github.com/anchore/grype 36 hhttps://github.com/google/osv-scanner 37 https://trivy.dev/
10
(a)
(b)
(c)
Fig. 4: Workflow of VERA: (a) setup, (b) Docker images/Android devices scanning, (c) Results analyses and exploitability assessment. DB: other scanners vulnerability databases (e.g., Grype, OSV)
Android-based systems, which operates by matching source code and patch signatures and is designed to achieve low falsepositive rates. Similarly, the Yocto Project provides a built-in vulnerability analysis mechanism, cve-check (referred to as cve-check in the remainder of this paper), which inspects Yocto recipes and source repositories to identify known vulnerabilities during the build process. Unlike scanners that operate on built OS images, both Vanir and cve-check rely on source-level tracking and platform-specific metadata, making them better suited for vulnerability detection on their
respective operating systems. This source-based approach, however, comes at the cost of increased setup complexity and longer analysis times: several hours may be required to download source trees and complete partial or full builds before scanning can be performed, in contrast to package-based scanners such as Grype or Trivy, which can typically analyze a built OS image or container within minutes. CVE Binary Tool (CBT) represents another example of a scanner applicable to Android-based and Yoctobased components, scanning binaries to retrieve their name
11
Scanner OSV Scanner
Pros • • •
Cons
Accurate open-source dependency scanning via OSV.dev Container scanning Tracks vulnerability states (e.g., fixed, wont-fix).
•
Scans compiled binaries for known vulnerable libs (e.g OpenSSL, zlib) Works offline, simple setup Extract & Scan archives (e.g zip, tar), including APKs EPSS and KEV Indicator
•
• •
No EPSS/risk scoring, Cannot scan large containers Seems less efficient on non-Debian-based OSes
CVE Binary Tool • • • •
• • • •
No container scanning No state tracking Prone to false negatives/positives due to string matching in binary Incomplete Android support Much slower than other scanners
Trivy • • •
Full-featured: containers, filesystems, IaC, dependencies, secrets Supports risk scoring (CVSS, EPSS) Tracks vulnerability states (fixed/unfixed)
•
•
Heavier runtime and slower on large images Seems more prone to false positives/negatives No KEV Indicator
Container and SBOM-based scanning (via Syft) Tracks vulnerability states (fixed/unfixed) Supports risk scoring (CVSS, EPSS) and KEV Indicator
•
Slightly slower than Trivy
Upgrade dependencies before scanning container Android device/emulator scanning (via CBT) Resolve unknown CVSS and EPSS Standardize/compress reports for all scanners Filter and sort results/reports Fast checking CVE presence and exploitability Search for CVE information and online exploits
•
No state tracking Not full support of scanner reports (i.e vulnerability states, EPSS, KEV indicator)
•
Grype • • •
VERA (Ours) • • • • • • •
•
TABLE VII: Scanners comparison Scanner Vanir
Target Android-based
Cons
•
Do not show affected product’s name/version No CVSS/EPSS or KEV indicator
•
No EPSS or KEV indicator
•
Yocto’s built-in cve-check ft.
Yocto-based
TABLE VIII: Repo scanners and version. Because our scanner is not designed to natively analyze Android-based systems, VERA leverages Vanir and CBT for Android-based OSes, and cve-check and CBT for Yoctobased OSes. Since Vanir and cve-check do not provide complete coverage of all CVEs in practice, we use CBT as a complementary scanner. CBT findings are considered unless the corresponding CVEs are identified as patched by Vanir or cve-check. V. E XPERIMENTAL EVALUATION AND USE CASE ANALYSIS We present in this section an experimental evaluation over two representative use cases, designed to assess the practical impact of some identified vulnerabilities (i.e., to evaluate the full exploitation workflow, from CVE detection to end-toend exploitability, thereby validating the relevance of the scan results under realistic attack conditions). As for the quantitative vulnerability analysis, Table IX reports the CVE and CVSS benchmarks for each operating system, together with the subset of vulnerabilities classified as Known Exploited Vulnerabilities (KEV), that is, CVEs that are actively exploited in the wild ; with potential online exploits – only for CVEs with CVSS superior or equal to 5.0, and EPSS superior or equal to 0.0003 (0.03%). Table X is specific for Android and Yocto-based OSes, due to their different scanning methods (whose results are based on Vanir, cve-check merged with
CBT and filtered by their relevance). Note that the default filtering configuration used in our experiments, as reported in Tables IX, X, XI is limited to package-level filtering. In other words, it does not exclude any broad vulnerability class by default. The vulnerability classes discussed in the analysis (e.g., RCE, LPE, ID, and DoS) are used to categorize and prioritize the reported CVEs. To demonstrate the analytical capabilities of our framework, Table V details the percentage of CVEs filtered for each OS, which ranges from 0.6% for AAOS 34 up to 59.8% for AutoSD, alongside a breakdown of CVE classes per OS. In Table VI , we leveraged the CVSS Vector Strings (specifically the metrics used to calculate their base scores) to classify each CVE into distinct impact categories: Remote Code Execution (RCE), Local Privilege Escalation (LPE), Information Disclosure (ID, data leakage), Denial of Service (DoS, program disruption), or Unknown when the vector is ambiguous. The only exception is Vanir’s results for Androidbased OSes, where the vulnerability type is explicitly indicated in their report. It should be noted that Sandbox and Virtual Machine Escapes (SBX/VME) are difficult to isolate relying solely on CVSS vectors, because their scoring metrics closely mirror those of LPEs, they are often reported under the LPE category. Table XI presents a comprehensive comparison of total CVEs/EUVDs for each OS, categorized by type (OS or middleware), purpose (safety or non-safety), and their respective certifications, such as ISO/IEC 15408-5 (EAL) and ISO 26262 (ASIL). Finally, Table XII provides detailed specifications for the tested operating systems. To the best of our knowledge, VERA is the first framework to propose automated report parsing, filtering, and sorting (including specific CVE impact classes such as RCE, LPE, ID, and DoS) across multiple vulnerability scanners, coupled with
12
TABLE IX: CVE & CVSS benchmark by OS. UNKNOWN
OS / Middleware Eclipse S-CORE Ubuntu 22.04 Ubuntu 20.04 VxWorks 7 VxWorks 7 ROS2 QNX Neutrino Zephyr TeslaOS AutoSD ROS2
Gr 0 0 0 0 0 0 0 0 0 0
LOW
VE 0 0 0 0 0 0 0 0 0 0
Gr 2 4 4 18 24 30 34 28 25 43
MEDIUM
VE 2 2 2 7 11 13 14 13 12 26
Gr 6 11 11 39 47 43 90 186 166 136
HIGH
VE 5 5 5 13 20 25 40 169 80 111
Gr 1 6 6 19 28 26 62 65 127 122
CRITICAL
VE 1 5 5 12 19 17 36 60 35 116
Gr 0 1 1 1 1 1 7 1 3 30
TOTAL
VE 0 1 1 1 1 1 1 1 2 28
Gr 9 22 22 77 100 100 193 280 321 331
VE 8 13 13 33 51 56 91 243 129 281
EPSS
Gr 0 22 22 77 100 85 190 44 319 327
VE 8 13 13 33 51 49 90 240 128 278
KEV VE 0 0 0 0 0 0 0 2 0 0
Exploits VE 3 8 8 20 29 36 52 119 75 215
Legend: Exploits: CVEs associated with publicly available proof-of-concept code or reported online exploits (non-exhaustive) CB: CBT, Gr: Grype, VC: Vanir (Android-based) or cve-check (Yocto-based), VE: VERA
TABLE X: CVE & CVSS benchmark by OS. UNKNOWN
OS AAOS 34 Android 32 Android 30 AGL
VC
115 547 641 0
CB
LOW
MEDIUM
VE
VC
CB
VE
VC
0 0 1 1 0 0 1 1
0 0 0 7
5 5 2 2 4 4 23 26
0 0 0 437
CB
VE
13 14 31 71 46 122 463 844
HIGH VC
0 0 0 130
CB
Type
Purpose
EAL
ASIL
None
None
2+
None
2+
None
6+
D
4+
D
None
None
None
B
None
None
None
None
None
None
None
None
None
None
None
None
6+
D
5+
D
None
D
None
B
None
D
None
D
VC
19 129 45 507 53 560 213 292
TABLE XI: Overall comparison of total CVEs/EUVDs for each OS, including their type, purpose, and their certifications ISO/IEC 15408-5 (EAL) and ISO 26262 (ASIL). OS / Middleware Eclipse S-CORE Ubuntu 22.04 Ubuntu 20.04 VxWorks 7 VxWorks 7 ROS2 QNX Neutrino Zephyr AutoSD / RHIVOS AAOS 34 TeslaOS ROS2 Android 32 Android 30 AGL INTEGRITY PikeOS DRIVE OS 6 DRIVE OS 5 LynxOS Mentor Nucleus
CRITICAL VE
CVEs 8 13 13 33 51 56 91 129 159 243 281 627 749 1203 N/A N/A N/A N/A N/A N/A
Legend: Type: = OS, = Middleware. Purpose: = Safety-critical, = Non-safety-critical. CVE: N/A = non available for scanning
a dynamic exploit finder. This approach provides a practical, unified evaluation methodology specifically tailored for the operating systems and middleware used in next-generation vehicles.
CB
TOTAL
VE
VC
CB
0 9 11 0 17 53 0 21 71 6 51 40
115 547 641 580
46 96 124 751
KEV
EPSS VE
159 627 749 1203
VC
CB
VE
0 46 118 0 96 591 0 124 727 576 749 1201
Exploits
VE
VE
3 8 4 3
24 109 102 710
TABLE XII: Tested OS details. OS AAOS Android ROS2 VxWorks TeslaOS QNX Neutrino AGL IVI Demo Qt AutoSD Eclipse S-CORE Zephyr
Version SDK 34 SDK 32 SDK 30 7 7 ROS2 amd-5.4.265 8.0 20.0.1 9 158 0.28.7
Release
Underlying OS
humble humble humble focal focal trout / / /
Ubuntu 22.04 Ubuntu 22.04 Ubuntu 22.04 Ubuntu 20.04 Ubuntu 20.04 CentOS 9 Alpine 3.21.5 Ubuntu 24.04
A CVE shall be seen as a potential attack vector, rather than a vulnerability that can be exploited with certainty. The more CVEs/EUVDs one OS has, the more it has potential attack vectors. We also tested Ubuntu 22.04 LTS and 20.04 LTS, as well as Android, because numerous OS rely on them. Libraries related to archive handling and data encoding (e.g., libarchive, zlib), image processing (e.g., libpng, libjpeg-turbo), XML parsing (e.g., libxml2), database management (e.g., libsqlite), and SSL/TLS (e.g., libssl) are extensively used by both the system and applications and therefore constitute attractive targets for exploitation. In addition, some applications rely on custom embedded libraries, which may also introduce exploitable vulnerabilities. Initial automated scans revealed multiple critical vulnerabilities (CVEs and EUVDs). To demonstrate feasibility, we successfully exploited two of these vulnerabilities in a controlled environment. (1) We successfully exploited CVE-2022-35737 affecting SQLite library running under
13
TABLE XIII: Examples of attack scenarios. Path A
B
Tactic Initial Access
Technique ATM-T0014: Malicious App
Affect Vehicle Function
ATM-T0071: Unintended Vehicle Network Message
Initial Access
ATM-T0011: Browser Compromise
Persistence
ATM-T0023: Modify Isolated Execution Environment
Collection
ATM-T0058: Capture Camera or Audio ATM-T0035: Capture SMS Message ATM-T0043: Location Tracking ATM-T0063: Internet Communication
Exfiltration
Description Install a backdoor in the isolated execution environment (e.g., AAOS sandbox) via a malicious application from the infotainment’s app store Inject spoofed CAN/AE messages (e.g, wheelspeed or torque-request messages) targeting engine/transmission ECUs to cause acceleration or braking
Value 0 1 4 10 17 19
Expertise Layman Proficient Expert Mult. experts
Value 0 3 6 8
Opportunity Unlimited Easy Moderate Difficult
Value 0 1 4 10
Resources Standard Specialized Bespoke Mult. bespoke
Value 0 4 7 9
Knowledge Public Restricted Sensitive Critical
Collect various private data (conversations, SMS, location etc.)
Severe
Major
Moderate
Negligible
Moderate
Moderate
Moderate
Severe
Compromised ECU’s internet connection to exfiltrate data
Value 0 3 7 11
TABLE XV: Attack Potential/Feasibility qualitative scale Attack Potential 0–9 10 – 19 20 – 29 ≥ 30
Impact (Negligible –> Severe) Financ. Operat. Privacy
Compromise the infotainment system via any disclosed vulnerability Ensure continued access across reboots/updates by implanting a backdoor in the isolated execution environment
TABLE XIV: Feasibility factor values Elapsed Time ≤ 1 day ≤ 1 week ≤ 1 month ≤ 3 months ≤ 6 months > 6 months
Safety
Feasibility High Medium Low Very Low
Android Automotive OS,38 but it could be exploited in any application using SQLite database engine subject to the 2GB memory constraint. Further works could search for vulnerabilities affecting other libraries, and their exploitability in known applications. (2) we implemented the de-association attack (Zelle et al. [35])39 against AAOS, AutoSD, and TeslaOS, targeting a SOME/IP service hosted in a container on the same network. On AAOS, the attack was unsuccessful, potentially due to security mechanisms that randomize port numbers. On AutoSD and TeslaOS the attack succeeded, allowing us to disconnect the target container from the legitimate service.40 The testbed architecture used for these experiments deployed the target subsystem inside one or two Docker containers (one container for a standalone service or two containers 38 See the following videocapture for validation purposes: https://github. com/EternalDreamer01/vera/blob/main/demo/cve-sqlite.mp4 39 A de-association attack targets the service discovery mechanism in SOME/IP by convincing clients that a legitimate service is no longer available. In this attack, an attacker eavesdrops on broadcast service discovery messages (FindService) to identify clients interested in a specific service. The attacker then sends spoofed StopOffer messages to these clients, claiming the service has been discontinued. 40 The following videocapture shows the feasibility and success of the attack: https://github.com/EternalDreamer01/vera/blob/main/demo/ attack-deassociation.mp4
when a client/server pair was required for SOME/IP), while the attacker ran in a separate Docker container attached to the same Docker network (bridge). All network traffic between attacker and target was confined to the Docker network to reproduce a realistic intra-host lateral movement scenario. Subsequently, to assess realistic attack progression, we executed two multistage scenarios that chained initial exploitation with lateral movement; both scenarios succeeded. a) Scenario A – Remote compromise via the infotainment application store (safety threat): a victim installs an application obtained through the vehicle’s infotainment application store that embeds a covert backdoor. Upon execution, the backdoor establishes persistent access to the infotainment unit, thereby enabling attackers to remotely compromise a large number of vehicles. This scenario highlights the potential for catastrophic, large-scale attacks [30]. b) Scenario B – Remote compromise via infotainment for personal data collection: an attacker exploits a known vulnerability in the infotainment system to achieve remote code execution (RCE). From this initial foothold, the attacker might want leverage a local privilege escalation (LPE) vulnerability to grant themself more privileges and capabilities. This step is not always necessary, depending on the initial exploited application and objectives. The attacker can then collect any available data such as addresses, contacts, and messages. A likely consequence of this attack is that an adversary who attains control of the infotainment unit can pivot via a vulnerable gateway ECU to the vehicle’s internal CAN/Automotive Ethernet (AE) network, enabling the injection of forged frames and the issuance of malicious commands to safety-critical ECUs (e.g., braking or steering controllers) [28] [27]. Our threat model evaluates specific attack scenarios by adopting the Threat Analysis and Risk Assessment (TARA) methodology from the ISO/SAE 21434 standard [22]. Table XIII describes the discussed scenarios mapping their tactics, techniques, and potential impacts. The specific tactics and techniques are derived from the Automotive Threat Matrix
14
TABLE XVI: Feasibility and risk of attack scenarios’ example. Path A
Tactic Initial Access Affect Vehicle Function
Technique
Elapsed Time
Expertise
Knowledge
Opportunity
Resources
ATM-T0014: Malicious App
≤ 1 week
Proficient
Public
Easy
Standard
ATM-T0071: Unintended Vehicle Network Message
≤ 6 months
Expert
Public
Unlimited
Standard
Overall Feasibility: B
Initial Access Persistence Collection
Feasibility High Low
Vulnerabiliy ex. CWE-912: Hidden Functionality
De-association [35]
Low
ATM-T0011: Browser Compromise
≤ 6 months
Mult. Experts
Public
Easy
Standard
ATM-T0023: Modify Isolated Execution Environment
> 6 months
Mult. Experts
Public
Unlimited
Standard
Low Low
CWE-284: Improper Access Control
CVE-2022-35737
ATM-T0058: Capture Camera or Audio
≤ 1 week
Proficient
Public
Unlimited
Standard
High
N/A
≤ 1 day
Layman
Public
Unlimited
Standard
High Low
N/A
ATM-T0035: Capture SMS Message ATM-T0043: Location Tracking
Exfiltration
ATM-T0063: Internet Communication
Overall Feasibility: Legend: N/A: Not applicable: weakness is due to core design.
TABLE XVII: Risk Matrix. Impact → Feasibility ↓ High Medium Low Very Low
Negligible Very Low Very Low Very Low Very Low
Moderate Medium Low Low Very Low
Major High High Medium Low
Severe Very High High Medium Low
TABLE XVIII: Attack scenarios weighted risk. Path A B
Safety Medium Low
Financ. Medium Low
Risk Operat. Low Low
Privacy Very Low Medium
Overall Medium Medium
by the lowest feasibility among the techniques composing the scenario. Table XVII is the risk matrix: to determine the risk with a given impact (evaluated on Table XIII) and feasibility (overall feasibility calculated on Table XVI). This risk matrix is used to assess the risk of our attack scenarios on Table XVIII. We consider the overall risk to be determined by the highest risk among the different risk of impact categories. Figure 5 illustrates the killchain state machines for the two attack scenarios. VI. D ISCUSSION
41
(ATM) [36]. Furthermore, we evaluate the consequences of these scenarios using the four impact categories defined by TARA: safety, financial, operational, and privacy, with each category rated on a scale from Negligible to Severe. For Scenario A, we estimate: • Severe safety impact: causing accidents via braking or acceleration manipulation; • Major financial impact: costs associated with recalls, legal liabilities; • Moderate operational impact: disruption of vehicle functionality, recalls or repairs; • Negligible privacy impact: limited data exposure. For Scenario B, we estimate: • Moderate safety impact: location tracking for physical harm (indirect safety threat); • Moderate financial impact: fines related to data leakage; • Moderate operational impact: reduced functionality of infotainment systems, recalls or repairs; • Severe privacy impact: personal data exposure. Table XIV and XV describe the values and scales used for our calculations in Table XVI; the sum of the five factors (Table XIV) describe the attack potential/feasibility (cf. Table XV). We considered the overall feasibility to be determined 41 The Auto-ISAC ATM https://atm.automotiveisac.com, is a valuable resource for analyzing complex attacks in CAVs. Inspired by the MITRE ATT&CK framework, the ATM defines 11 tactics representing attacker objectives and 85 techniques detailing specific attack methods. These tactics include Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Manipulate Environment, and Affect Vehicle Function. The ATM is particularly useful for visualizing multi-stage attacks by mapping the sequence of techniques an attacker might employ
a) Key findings: The comprehensive scanning of embedded operating systems and middleware reveals a substantial and heterogeneous vulnerability landscape across the examined platforms. The results presented in Section V validate our claims, i.e., that vulnerability prevalence exhibits significant variance depending on the OS/middleware under examination, with severity distributions ranging from primarily low-risk findings to critically concerning threat vectors. Among the non-Android/Yocto platforms, Eclipse S-CORE exhibits the lowest vulnerability count (8 total), with no critical findings and a moderate distribution across low and medium severity levels. This profile aligns with its specialized design purpose and potentially more controlled dependency footprint. Conversely, platforms such as ROS2 (281 total CVEs/EUVDs), TeslaOS (243), and AutoSD/RHIVOS (129) show substantially higher vulnerability burdens. ROS2 presents an exceptionally high-risk profile with 28 critical-severity vulnerabilities, significantly surpassing other platforms in this severity category. This concentration of critical vulnerabilities in ROS2 represents an attack surface that warrants immediate attention, particularly given ROS2’s adoption in CAVs but also in robotics and autonomous systems research. Regarding the Android and Yocto-based platforms, the number of reported CVEs is significantly higher than for non-Android/Yocto systems. Among these, AAOS 34 exhibits the lowest vulnerability count (159 CVEs), whereas AGL presents the highest (1203 CVEs). The CVSS severity stratification reveals distinct vulnerability patterns across platform categories. Traditional operating systems demonstrate moderate vulnerability loads: Ubuntu 22.04 and 20.04 (both with 22 total CVEs/EUVDs) show well-distributed low and medium vulnerabilities with minimal
15
(a)
(b)
Fig. 5: Killchain state machines for the paths of scenarios A and B.
critical exposures. However, safety-critical platforms certified under ISO/IEC 15408-5 (EAL) or assessed under ISO 26262 (ASIL) are not immune. For instance, VxWorks 7 (EAL 6+) and QNX Neutrino (EAL 4+), exhibit significant totals of 33 and 56 CVEs/EUVDs respectively, that include numerous of high-severity CVSS, demonstrating that certification lowers but does not eliminate observable attack surface. Finally, Android and Yocto-based platforms exhibit a concerningly high number of critical and high-severity CVSS vulnerabilities (e.g., Android 30 accounts for 71 critical and 560 highrated CVEs). This finding is particularly worrying given that most in-vehicle infotainment systems rely on these operating systems (cf. Table III). Moreover, the elevated prevalence of KEVs and publicly available exploits further underscores the inherent fragility and large attack surface of these platforms, as well as the maturity of the adversarial ecosystem targeting them. Finally, regarding the comparison of our tool VERA with existing scanners, Table XI also reports results produced by other tools. For non-Android and non-Yocto operating systems we compared VERA against Grype, Vanir, cve-check and CBT. Trivy’s outputs proved highly inconsistent. More precisely, for CentOS-based (e.g., AutoSD) and Ubuntu-based images (e.g., QNX and TeslaOS) it only reported Go-related CVEs, it returned no findings on Alpine-based images (e.g., Eclipse S-CORE), and it produced a very large number of false positives (> 1000) for ROS-embedded images. For these reasons, Table XI presents only the Grype results. We emphasize that VERA’s objective differs from that of many generic scanners. In other words, rather than exhaustively listing every CVE, VERA applies systematic filtering and targeted analysis to surface vulnerabilities that are plausibly exploitable in next-generation vehicle contexts. Therefore, after this filtering and follow-on investigation, VERA typically reports fewer CVEs than Grype, deliberately trading breadth for higher signal-to-noise so that analysts and decision-makers can concentrate on true, vehicle-relevant
priorities. By prioritizing actionable, context-specific vulnerabilities, VERA reduces remediation noise and enables more effective, risk-based allocation of security resources. b) Interpretation: First, raw CVE/EUVD counts should be interpreted as potential attack surface rather than proof of immediate exploitability. Notice that a CVE denotes a known weakness that could be used as an attack vector under the right conditions. However, the exploitation depends on configuration, deployed components, and presence of vulnerable code paths. Hence, the higher counts seen for some OSes/middleware indicate a larger pool of attack vectors that defenders must consider, not that those systems are necessarily trivially exploitable in their stock configurations. This nuance is central to risk assessment and triage. Second, the distribution of CVEs correlates with two practical realities. One is codebase and dependency surface, maning that OSes and middleware that carry many userland packages, or third-party libraries (archive/image/XML/DB/SSL libraries called out in our evaluation), naturally surface more CVEs. The other is visibility, where open platforms with richer ecosystems and more public scrutiny (e.g., Android/AGL) tend to have more reported CVEs simply because more researchers, vendors, and scanners examine them. Both effects are visible in our results. Third, certification (EAL/ASIL) and perceived safety posture do not eliminate the problem. Indeed, certified kernels and RTOSes still show non-zero vulnerability counts (Table XI). Certification can constrain attack surface and enforce development controls, but it is not a substitute for continuous discovery/patching of flaws in the large software stack that surrounds an RTOS in an automotive product. c) Limitations: We note some limitations in our work. First, vulnerability assessment was performed on Dockerized environments to ensure reproducibility and isolation. While this setup enables systematic comparison, it does not fully capture the complexity of in-vehicle deployments, including vendor-specific kernel builds and configurations, propri-
16
etary implementations, firmware interactions, and hardwaredependent behavior. As a result, some vulnerabilities that depend on platform-specific integrations or runtime conditions may be misrepresented [37]. Second, we rely on CVSS scores to characterize vulnerability severity. Although widely adopted, CVSS reflects intrinsic vulnerability properties and does not account for deployment context, available mitigations, or exploit feasibility, which may lead to over or underestimation of real-world risk. Third, the presence of a potential vulnerability does not imply practical exploitability. Many reported issues require specific compilation options, configurations, or operational conditions that may not be satisfied in actual automotive systems. A precise assessment of exploitability would require access to real-world configurations and proprietary settings, which are outside the scope of this study. This gap described by the second and third limits is well illustrated by our de-association case study. The same reported weakness was exploitable on AutoSD and TeslaOS but failed against AAOS, showing that identical severity ratings may lead to divergent operational outcomes depending on platform configuration and runtime defenses. To reduce such mismatches, VERA can help through semi-automated exploitability checks (especially for symbols/functions presence and calls). By contrast, the other comparative scanners report package-level matches without this additional filtering. VII. R ELATED WORK Our work builds upon research in automotive security, SDV architectures, and vulnerability scanning. This section surveys the most relevant contributions in these areas and highlights the gaps our work aims to address. Table XIX summarizes the related works with respect to key criteria relevant to VERA’s focus on automotive cybersecurity and vulnerability scanning. a) Automotive security analysis: Recent studies have advanced the understanding of automotive cybersecurity, particularly for Connected and Automated Vehicles (CAVs). Eiza et al. [26] reviewed cybersecurity threats in connected vehicles, identifying vulnerabilities in connectivity interfaces such as cellular and V2X systems. Uddin et al. [27] provided a systematic review of recent trends, highlighting remote attack vectors and the increasing complexity of vehicle software stacks. Wang et al. [38] proposed a TARA-based risk assessment aligned with ISO/SAE 21434, focusing on systematic threat modeling for CAVs. Similarly, Jayarathne et al. [39] introduced simulation-based risk assessment for CAVs, emphasizing practical evaluation of attack scenarios. Pitchamaini et al. [11] proposed an approach that integrate the Automotive Threat Matrix (ATM) with the ISO/SAE 21434 TARA process to systematically construct and analyze attack paths. In the same context, Benyahya et. al [45] proposed TARA 2.0, a TARA based framework that focuses on privacy. While prior studies and existing vulnerability scanners establish a strong foundation, they cannot be directly extended to the POSIX-based OSes used in modern vehicles. The primary limitation of these generic tools is their lack of automotive
context: they are too broad and produce an unmanageable amount of noise (mainly false positives) when applied to the highly customized, stripped-down software stacks typical of automotive environments. As demonstrated in our results (Tables IX and X), generic scanners fail to account for automotive-specific package filtering, leading to inflated vulnerability counts. b) Security of SDVs: The shift to SDVs has introduced new security challenges due to increased software complexity and connectivity. Kifor et al. [23] provided a comprehensive survey of automotive cybersecurity frameworks, including those applicable to SDVs, emphasizing the need for robust testing and monitoring. Huq et al. [28] discussed emerging risks in SDVs, such as vulnerabilities in infotainment systems and OTA updates, which align with our threat model. Sghaier et al. [34] provided a comprehensive systemization of knowledge on SDVs, mapping the ecosystem and enabling technologies, identifying principal cyberattack entry points that arise from their architectural and operational characteristics, and proposing a taxonomy of SDV-specific attacks. Specific platforms used in SDVs have also been studied. Jeong et al. [40] analyzed the security of Automotive Grade Linux (AGL), demonstrating practical attacks on infotainment systems. Gong et al. [41] proposed a lightweight protection mechanism for vehicle control functions on Android Automotive OS. These studies highlight the critical role of the OS layer in SDV security but focus on single platforms. In contrast, VERA is designed for scalable analysis across multiple platforms and products, addressing a broader range of SDV environments. Zhang et al. [44] analysed open source components from automotive firmware and compared them with commonly used components in general-purpose operating systems. Their study reports an average of 79.8 open source components per firmware image, representing roughly 16% of binary files. They further note that some open source artifacts are associated with CVEs. However, the analysis does not employ automated vulnerability-scanning tools. Instead, the authors map library versions to CVE entries listed at NVD and enumerate the matches. Consequently, the study is primarily descriptive rather than providing a security-driven vulnerability assessment. More precisely, the study’s primary focus is quantifying and characterizing the presence of open source components in automotive platforms rather than systematically assessing their security posture. c) Privacy concerns in SDVs: Data collection from vehicles is long established. De Vincenzi et al. [1] provided a comprehensive analysis of the security and privacy challenges associated with SDVs, emphasizing a range of architectural and operational security and privacy risks. Mainly, they observe that privacy is frequently treated as secondary to security in SDV research and practice. This oversight leaves privacy as an under-recognized and exploitable attack surface. Jeong et al. [25] highlights that an attacker can track location, obtain phonebook entries, recent call logs, and text messages from Bluetooth-paired smartphones, make a phone call or send a message to any recipient. In 2023, the Mozilla foundation exposed serious privacy violations after researching
17
TABLE XIX: Comparison of related works in automotive cybersecurity and vulnerability scanning Ref.
Primary Focus
Kifor, Popescu [23]
Cybersecurity frameworks
Huq [28]
SDV vulnerabilities
Uddin et al. [27]
Cybersecurity trends
Eiza, Ni [26]
Connected vehicle threats
Wang, Zhang [38]
TARA for CAVs
Jayarathne et al. [39]
Simulation-based risk
Jeong et al. [40]
AGL infotainment security
Gong et al. [41]
Android Automotive security
Buczak, Guven [42]
Container vuln. scanning
Doan, Jung [43]
Dockerfile vuln. scanning
Zhang et al. [44]
Open Source Libraries and CVEs
De Vincenzi et al. [1]
Security and privacy
Jeong et al. [25]
Impact and implications of IVI
This work
Security evaluation for SDV
SDV
CAV
Vuln. Scan
Offline
Scalable
Key Contribution / Limitation + Surveys SDV security frameworks. – Limited focus, no offline support. + Identifies SDV risks (infotainment, OTA). – No focus on vulnerability scanning or scalability. + Reviews CAV attack vectors. – No specific SDV or scanning focus, not scalable. + Identifies connectivity risks. – Limited SDV focus, no scanning or scalability. + TARA-based risk assessment. – No vulnerability scanning, limited SDV focus. + Simulation for CAV risks. – No scanning, limited SDV focus. + Demonstrates AGL attacks. – Platform-specific, no scanning or scalability. + Lightweight protection for Android. – Platform-specific, no scanning or scalability. + Evaluates scanner limitations. – Not automotive-specific, partial offline support. + Improves container scanning. – Not automotive-specific, partial offline support. + Identifies libraries and associated CVEs – Limited review of possible CVEs. + Review security and privacy concerns – No vulnerability scanning. + Security and privacy concerns implied by IVI – No vulnerability scanning. + Practical security evaluation on SDV OSes – SBX/VME not fully addressed, no real-world testing
Legend: = Explicit focus, = Partial or likely focus, = Not addressed. SDV: Focus on software-defined vehicles or POSIX-based systems. CAV: Connected and Autonomous Vehicles. Vuln. Scan: Vulnerability scanning tools or methods. Offline: Support for offline analysis. Scalable: Support for scalable, multi-product analysis.
the privacy policies of multiple vehicles manufacturers [46]. Automobiles from manufacturers such as Nissan, Volkswagen, Toyota and others have been shown to gather private information about their drivers, including sexual activity, immigration status, ethnicity, facial expressions, weight, health and genetic information, and where you drive. These highly sensitive personal data are routinely shared with third parties, including advertisers and data brokers, yet manufacturers frequently provide limited transparency regarding what is collected and how it is disseminated [46]. As vehicles become persistently connected, these data streams also expand the attack surface, increasing exposure to unauthorized access, profiling, and other forms of misuse and privacy violation. d) Vulnerability scanning tools: Several open source options, such as Trivy, Grype, and OSV-Scanner, are widely used to detect CVEs in software dependencies and container images [42]. They have limitations in the automotive context Buczak et al. [42], including inconsistencies in container vulnerability scanning and reliance on online databases. Doan et al. [43] proposed DAVS, a method to improve container scanning by analyzing Dockerfiles, but it does not address the need for offline-first analysis of pre-compiled artifacts. In this work we propose VERA, (1) a suite of tools, that filters, sorts and prioritizes CVEs. (2) it provides functionalities to scan layered/Open Container Initiative (OCI) container images or Android emulator directly, and (3) provides guidance to assess exploitability, retrieve information on a specific CVE and discover online exploits. Unlike penetration testing frameworks like those discussed in [23], which focus on blackbox testing, VERA provides a systematic semi-white-box approach to identify known vulnerabilities through packages
scanners. It also handles the scanning process through CBT (as in black-box settings), and confirm the presence of some CVEs through integrated reverse-engineering tools. Hence, it enables a proactive, in-depth pentesting strategy. VIII. C ONCLUSION Modern vehicles, denoted in our work as Software-defined vehicles (SDVs), are increasingly adopting Portable Operating System Interface (POSIX)-compatible platforms to support new features. Motivated by a simple but consequential observation (POSIX-compatible operating systems and products have long accumulated large numbers of CVEs) we have provided a comprehensive security analysis for SDVs, focusing on software vulnerabilities. We have also presented VERA, a custom vulnerability assessment solution tailored to efficiently discover vulnerabilities on different operating systems, within a dockerized development environment to evaluate exploitability issues. VERA is conceived as a suite for reproducible vulnerability analysis and prioritization, which standardizes and compresses scanner outputs, resolves unknown CVSS and EPSS entries. We also contributed to the CVE Binary Tool (CBT) project, to better support Android’s binaries, and include the results in this paper. As perspectives for future work, we envision refining the vulnerability assessment by incorporating real-world system configurations and usage patterns to better assess the presence and the practical exploitability of identified vulnerabilities. Scanning more automotive operating systems like PikeOS, INTEGRITY, NVIDIA DRIVE OS, etc. would also be interesting. We might focus on a specific OS, like an Android infotainment system as it could be a potential entry point
18
for an attacker, to go deeper in the analysis of vulnerabilities and their exploitability. We could also attempt to implement fully automated vulnerability exploitability testing, extracting the conditions from the CVE data especially the vulnerable symbols. ACKNOWLEDGMENT The work presented in this paper was conducted within the framework of the Horizon Europe AI4CCAM project (grant agreement 101076911), and the Carnot project CARNOT 2025 -TSN-D6/AMI Citroen - véhicule autonome of Télécom SudParis. R EFERENCES [1] Marco De Vincenzi, Mert D. Pesé, Chiara Bodei, Ilaria Matteucci, Richard R. Brooks, Monowar Hasan, Andrea Saracino, Mohammad Hamad, and Sebastian Steinhorst. Contextualizing security and privacy of software-defined vehicles: State of the art and industry perspectives, 2024. [2] Android Automotive OS. Android Automotive OS Update Bulletin—September 2024. Technical report, Android Automotive OS, September 2024. [3] Haochen Gong, Siyu Hong, Shenyi Yang, Rui Chang, Wenbo Shen, Ziqi Yuan, Chenyang Yu, and Yajin Zhou. Harness: Transparent and lightweight protection of vehicle control on untrusted android automotive operating system. In 34th USENIX Security Symposium: USENIX Security 2025. USENIX Association, 2025. [4] Yekatierina Churakova Mathias Ekstedt. Vexed by vex tools: Consistency evaluation of container vulnerability scanners. arXiv preprint arXiv:2503.14388, 2025. [5] Thien-Phuc Doan and Souhwan Jung. Davs: Dockerfile analysis for container image vulnerability scanning. Computers, Materials & Continua, 72(1), 2022. [6] Hongqian Wei, Qiang Ai, Wenqiang Zhao, and Youtong Zhang. Realtime security warning and ecu identification for in-vehicle networks. IEEE Sensors Journal, 23(17):20258–20266, 2023. [7] Chandra Sharma, Samuel Moylan, Eugene Y Vasserman, and George T Amariucai. Review of the security of backward-compatible automotive inter-ecu communication. IEEE Access, 9:114854–114869, 2021. [8] Zhen Zhang, Yuezhong Zhang, Jinfeng Zhang, Jichao Xie, and Shaoxun Liu. An endogenous security study of telematics box in intelligent connected vehiclesc. IEEE Embedded Systems Letters, 2024. [9] Irdin Pekaric, Clemens Sauerwein, and Michael Felderer. Applying security testing techniques to automotive engineering. In Proceedings of the 14th International Conference on Availability, Reliability and Security, pages 1–10. ACM, 2019. [10] Haichun Zhang, Jie Wang, Yijie Wang, Minfeng Li, Jinghan Song, and Zhenglin Liu. Icvtest: A practical black-box penetration testing framework for evaluating cybersecurity of intelligent connected vehicles. Applied Sciences, 14(1), 2024. [11] Ramakrishnan Pitchaimani, Sébastien Canard, Badis Hammi, and Aurel Sorin Spornic. Systematic Risk Analysis of Multi-Stage Attacks in Zonal Automotive E/E Architecture. In 2025 23nd International Symposium on Network Computing and Applications (NCA), pages 1–9. IEEE, 2025. [12] Feng Luo, Xuan Zhang, Zhenyu Yang, Yifan Jiang, Jiajia Wang, Mingzhi Wu, and Wanqiang Feng. Cybersecurity testing for automotive domain: A survey. Sensors, 22(23):9211, 2022. [13] Luca Allodi and Fabio Massacci. Comparing vulnerability severity and exploits using case-control studies. ACM Transactions on Information and System Security (TISSEC), 17(1):1–20, 2014. [14] Ensure comprehensive functional safety for road vehicles, covering all critical aspects from vocabulary to guidelines. Standard, International Organization for Standardization, Geneva, CH, 2018. [15] Road vehicles – Functional safety – Use of pre-existing software architectural elements. Standard, International Organization for Standardization, Geneva, CH, 2024. [16] Road vehicles – Cybersecurity engineering. Standard, International Organization for Standardization, Geneva, CH, 2021. [17] Electrical, electronic and programmable electronic safety-related system. Standard, International Electrotechnical Commission, Geneva, CH, 2022.
[18] Information security, cybersecurity and privacy protection – Evaluation criteria for IT security. Standard, International Organization for Standardization, Geneva, CH, 2022. [19] Ahmann Philipp. Exploring the potential of zephyr in automotive and software defined vehicles. In Open Source Summit Europe 2024, Vienna, Austria, September 2024. The Linux Foundation. [20] Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, et al. Experimental security analysis of a modern automobile. In 2010 IEEE symposium on security and privacy, pages 447–462. IEEE, 2010. [21] Charlie Miller and Chris Valasek. Remote exploitation of an unaltered passenger vehicle. Black Hat USA, 2015(S 91):1–91, 2015. [22] ISO/SAE. Iso/sae 21434:2021 road vehicles – cybersecurity engineering, 2021. [23] Claudiu Vasile Kifor and Aurelian Popescu. Automotive cybersecurity: A survey on frameworks, standards, and testing and monitoring technologies. Sensors, 24(18):6139, 2024. [24] Mohammad Sayad Haghighi, Faezeh Farivar, Alireza Jolfaei, Azin Bayrami Asl, and Wei Zhou. Cyber attacks via consumer electronics: Studying the threat of covert malware in smart and autonomous vehicles. IEEE Transactions on Consumer Electronics, 69(4):825–832, 2023. [25] Seonghoon Jeong, Minsoo Ryu, Hyunjae Kang, and Huy Kang Kim. Infotainment System Matters: Understanding the Impact and Implications of In-Vehicle Infotainment System Hacking with Automotive Grade Linux. In 13th ACM Conference on Data and Application Security and Privacy, CODASPY ’23, page 201–212, New York, NY, USA, 2023. Association for Computing Machinery. [26] Mahmoud Hashem Eiza and Qiang Ni. Driving with sharks: A review of cybersecurity threats in connected vehicles. IEEE Transactions on Intelligent Transportation Systems, 18(11):3081–3090, 2017. [27] Mohammad Nasim Uddin, Mohammad Jabir Hossain Chowdhury, Fahad Faisal, and Debashis Dipta. Systematic review on the recent trends of cybersecurity in automobile industry. IEEE Access, 11:106947–106964, 2023. [28] Numaan Huq. Automotive cyber security - emerging risks and new case study insights. ATZelectronics worldwide, 19:14–19, 2024. [29] Lembhe Pankaj. Security vulnerabilities in toll collection system. Journal of Engineering and Applied Sciences Technology, pages 1–7, 10 2023. [30] Haibo He, Wei Li, and Jun Zhang. Security analysis of over-theair updates for connected vehicles. IEEE Internet of Things Journal, 5(6):4965–4974, 2018. [31] Daniel Grimm, Marco Stang, and Eric Sax. Context-aware security for vehicles and fleets: A survey. IEEE Access, 9:101809–101846, 2021. [32] Shahida Malik and Weiqing Sun. Analysis and simulation of cyber attacks against connected and autonomous vehicles. In 2020 International Conference on Connected and Autonomous Driving (MetroCAD), pages 62–70, 2020. [33] National Highway Traffic Safety Administration. Cybersecurity best practices for the safety of modern vehicles. Technical Report DOT HS 812 333, NHTSA, 2022. [34] Khaoula Sghaier, Badis Hammi, Ghada Gharbi, Pierre Merdrignac, Pierre Parrend, and Didier Verna. Advancing security in softwaredefined vehicles: A comprehensive survey and taxonomy. arXiv preprint arXiv:2510.09675, 2025. [35] Daniel Zelle, Timm Lauser, Dustin Kern, and Christoph Krauß. Analyzing and securing some/ip automotive services with formal and practical methods. In Proceedings of the 16th International Conference on Availability, Reliability and Security. Association for Computing Machinery, 2021. [36] Automotive threat matrix. https://atm.automotiveisac.com/, 2024. [37] Akshay Mittal and Vivek Venkatesan. Evaluating container security and reproducibility in research software engineering. Authorea Preprints, 2025. [38] Xin Wang and Yifan Zhang. Systematic risk assessment for connected and autonomous vehicles using tara and iso/sae 21434. IEEE Transactions on Intelligent Transportation Systems, 22(7):4478–4489, 2021. [39] Madhawa Jayarathne, Julien Epps, and Karin Maag. Simulationbased cybersecurity risk assessment for connected and autonomous vehicles. IEEE Transactions on Intelligent Transportation Systems, 25(10):103005, 2024. [40] Junsung Jeong, Sangwoo Kim, and Jaewoo Lee. Security analysis of infotainment systems in software-defined vehicles. IEEE Transactions on Vehicular Technology, 71(5):4872–4883, 2022.
19
[41] Wei Gong, Li Zhang, and Jian Wang. Lightweight protection mechanism for vehicle control on android automotive os. IEEE Transactions on Dependable and Secure Computing, 20(3):2100–2112, 2023. [42] Anna L. Buczak and Erhan Guven. A survey of cybersecurity tools for vulnerability scanning in containers. IEEE Communications Surveys & Tutorials, 24(4):2356–2387, 2022. [43] Thanh Doan and Souhwan Jung. Davs: Dockerfile analysis for container image vulnerability scanning. IEEE Access, 10:87654–87665, 2022. [44] Yanan Zhang, Yuqiao Ning, Chao Ma, Longhai Yu, and Zhen Guo. Empirical study for open source libraries in automotive software systems. IEEE Access, 11:123717–123728, 2023. [45] Meriem Benyahya, Anastasija Collen, Teri Lenard, and Niels Alexander Nijdam. Tara 2.0 for connected and automated vehicles. IEEE Transactions on Intelligent Transportation Systems, 2025. [46] Mozilla. Privacy Nightmare on Wheels: Every Car Brand Reviewed By Mozilla – Including Ford, Volkswagen and Toyota – Flunks Privacy Test. https://www.mozillafoundation.org, 2023.