Abstract
Connected and automated mobility (CCAM) is a complex cyber-physical system (CPS) that integrates computing, communication, and control functions in safety-critical environments. At its core is the system-on-chip (SoC) platform, which integrates processing units, communication interfaces, artificial intelligence accelerators, and security modules into a single chip. The Automotive Open System Architecture (AUTOSAR) standard was developed specifically for the automotive domain to better manage this complexity — it defines a layered software structure and interfaces and promotes the reuse of software and hardware components. However, in practical applications, this integrated SoC software architecture still presents security challenges, especially in real-time, safety-critical environments. Recent reports indicate a surge in vulnerabilities associated with SoCs, but a systematic analysis of the root causes and impacts of these vulnerabilities within AUTOSAR-compliant architectures remains lacking. This study fills this gap: it analyzes 180 publicly reported automotive SoC vulnerabilities and maps them to a representative SoC software architecture model that adheres to AUTOSAR’s layered abstraction and service-oriented principles. The study identifies 16 root causes and 56 affected software modules, examining the delay in vulnerability mitigation across different Common Weakness Enumeration (CWE) categories and architectural layers. We reveal dominant vulnerability patterns and key modules with longer patch delay times, providing actionable insights for securing automotive CPS platforms, including guidelines for improving SoC software architecture vulnerability detection, prioritization, and localization strategies.
1. Introduction
A secure software architecture plays a critical role in modern collaborative, connected, and automated mobility (CCAM). The functionalities of CCAM are continuously expanding, requiring automotive software systems to evolve persistently, from performance optimization and infotainment to autonomous driving. Automotive system-on-chip (SoC) has been a core component of the CCAM ecosystem, integrating multiple functionalities into a single chip. Historically, microcontrollers were responsible only for isolated tasks such as engine control and braking; however, over the past two decades, SoCs from manufacturers like NVIDIA, Qualcomm, and Intel have evolved from providing basic infotainment and safety functions to supporting high-performance AI-driven processors for autonomous driving, advanced infotainment, and other connected functionalities. This transition has brought significant architectural complexity, with an increasing number of software modules within the SoC, layered interactions between modules, and enhanced functional integration, all of which pose new challenges for system-level analysis and security protection.
Given that the automotive software ecosystem comprises both automotive-specific and general-purpose modules, the security of automotive cyber-physical systems (CPS) has become an urgent issue. Recent incidents of data breaches, remote control attacks, and service disruptions highlight the pervasive risks. Existing studies have shown that nearly 67% of automotive software vulnerabilities reported in the past eight years are directly related to SoC-based systems. Given the high integration of modern SoCs, a vulnerability in a single function can jeopardize the security of the entire software stack.
Although AUTOSAR provides a standardized reference architecture, its specifications (especially those related to the classic platform and adaptive platform) are abstract and platform-independent, not designed for direct mapping of real vulnerabilities. In contrast, vulnerabilities are typically reported at the code level and are related to specific drivers, firmware, or system service software. Therefore, we first derived an intermediate architecture model by analyzing open-source SoC software codebases to clarify the structure and deployment of actual modules (such as WLAN drivers, inter-process communication (IPC) services, hardware abstraction layers (HAL), etc.); we then aligned this architecture with AUTOSAR concepts to maintain compatibility. We filtered publicly reported automotive SoC software (ASoCS) vulnerabilities from the National Vulnerability Database (NVD) and mapped them to this representative architecture model. Although the availability of open-source automotive codebases is limited, this study reveals key trends and patterns by addressing the following focused research questions (RQs):
· RQ1: What are the root causes of automotive SoC software (ASoCS) vulnerabilities? To what extent can these root causes explain the identified vulnerabilities?
· RQ2: How are vulnerabilities distributed across different architectural components/modules in the automotive SoC software architecture model stack?
· RQ3: What differences exist in vulnerability mitigation times across different CWE categories and automotive SoC software modules?
This study contributes to the field of automotive SoC software architecture and its vulnerabilities by: 1) providing a literature-driven automotive SoC software architecture model compliant with AUTOSAR standards, examining the impact of real vulnerabilities on each architectural layer; 2) presenting multiple findings regarding automotive SoC software vulnerabilities by answering the aforementioned research questions; 3) interpreting the research findings in conjunction with specific use cases of cyber-physical systems (CPS) and AUTOSAR. Specifically, the results can help software architects and security testing leads to more quickly identify high-risk modules, prioritize security design efforts, and improve vulnerability analysis; additionally, component-level vulnerability mapping can inform component selection and procurement decisions, enhancing the overall software quality and security posture of SoC-based automotive platforms.
2. Related Work
We reviewed related research analyzing automotive CPS software and its security, including both analytical studies and those proposing practical solutions.
An exploratory study by Garcia et al. analyzed software defects in two mainstream open-source projects in the autonomous driving domain (Autoware and Baidu Apollo). This study analyzed 499 defects, identified their root causes, and recognized the affected software components.
Mashkour et al. conducted a systematic mapping study on model-driven engineering for safety-critical software systems. The authors filtered 29 core research papers in the automotive domain, of which 11 focused on architecture and design phases. Analysis revealed that only a few of these papers employed reference architectures, with one using the Evita automotive reference architecture in the vehicular networking domain, but no studies have addressed mapping analysis of automotive SoC software architectures.
Basu and Stalun conducted an empirical study on automotive software vulnerabilities from 2018 to 2024, focusing on the distribution of Common Vulnerability Scoring System (CVSS) scores, attack vectors, and CWE categories across 1663 identified vulnerabilities.
Bella et al. proposed a basic software module (BSW) named CINNAMON, built on the AUTOSAR classic platform, which enhances vehicular communication security by adding confidentiality protection to the existing integrity and authentication guarantees of the standard secure onboard communication (SecOC) module. Unlike SecOC, which does not provide encryption, CINNAMON integrates cryptographic protection, freshness verification, and configurable security profiles. The authors implemented and evaluated this module on an STM32-based electronic control unit (ECU) prototype, verifying that it incurs only minimal performance overhead. This study demonstrates how to embed secure module design within the AUTOSAR communication stack, complementing our vulnerability-oriented analysis.
While existing research provides valuable insights into automotive software security (such as defect classification, CVE analysis, and model-driven security techniques), most studies either focus on a single codebase or conduct high-level analyses, lacking architectural support. Our mapping approach aligns vulnerabilities with functional blocks within AUTOSAR-compliant architectures, providing practical, actionable insights based on real software structures. By systematically analyzing vulnerabilities within clearly defined representative SoC software stack layers and modules, this study aids in targeted vulnerability localization and deeper root cause identification. This architectural perspective can help security testers, software architects, procurement teams, and other industry practitioners accurately identify high-risk modules, anticipate mitigation delays, and make more informed decisions regarding component selection and software quality assurance.
3. Research Method: Architecture Modeling, Vulnerability Data Collection, and Mapping
This research method consists of three parts: the first step derives the automotive SoC software (ASoCS) architecture model; the second step collects automotive SoC software vulnerabilities (i.e., Common Vulnerabilities and Exposures (CVE)) and filters for those containing open-source code; the third step describes the mapping method for vulnerabilities to root causes, architectural modules, and mitigation times.
All manual analysis or decision-making processes were collaboratively completed by two researchers (one from industry and one from academia). We employed Cohen’s Kappa coefficient to measure the consistency between the two researchers, achieving a final score of 0.81, indicating a high level of agreement in the manual process.
3.1 Step One: Automotive SoC Software Architecture Model
This study adopts an inductive, literature-driven approach to derive a representative automotive SoC software (ASoCS) architecture model for analysis, based on widely used automotive and embedded platforms and standards. The model construction process is as follows: a detailed survey of open-source codebases such as the Android Open Source Project (AOSP), Code Aurora Forum (CAF), and Qualcomm Board Support Package (BSP) layers was conducted to analyze the functional decomposition and file organization of SoC components; by parsing directory structures, dependency graphs, and interface definitions, recurring architectural patterns and software boundaries were extracted. To ensure structural consistency with industry practices, we aligned the extracted architectural layers with AUTOSAR — AUTOSAR defines a service-oriented layered architecture model for modern automotive platforms. Figures 1 (complete software architecture) and 2 (kernel space and user space of the central processing unit) present a simplified view of this architecture model.
Figure 1: Automotive SoC Software Architecture Model
Figure 2: ASoCS, Central Processor: Kernel and User Space
The core derivation principles are as follows:
Layered decomposition of the central processor (CP): The central processor is divided into user space, kernel space, and secure execution environment (SEE) to match the layered structure of Android/Linux systems in embedded automotive environments. Additionally, the separation of user space and kernel space in the model aligns with AUTOSAR’s layered abstraction — in AUTOSAR, application layer functionalities (adaptive applications) are decoupled from the underlying execution services provided by the basic layer (such as POSIX-based operating systems and execution management modules).
Function-based subsystem isolation: Referring to platforms like Snapdragon Automotive and NVIDIA DRIVE, digital signal modules, communication modules, graphics processing modules, etc., are separated. Each module is equipped with firmware, drivers, and function-oriented application programming interfaces (APIs), which, while interacting with the central processor, can operate semi-independently. Among them, communication modules, input-output memory management units (IOMMU), inter-process communication (IPC), and other modules correspond to the basic software modules defined by the AUTOSAR platform. However, to capture real-world SoC integration patterns, the model also includes modules like neural processors and graphics processors — these modules are not explicitly defined or abstracted in AUTOSAR. The rationale for this design is that the integration of AI accelerators and GPU-based infotainment systems in automotive SoCs is increasingly prevalent. This hybrid approach maintains overall alignment with AUTOSAR’s service-oriented principles while accommodating the architectural diversity of commercial SoC platforms.
Identification of security domains: The model explicitly retains components such as the secure execution environment (SEE) to reflect the common implementation of trusted execution environments (TEE) in Qualcomm and ARM architecture SoCs. Although AUTOSAR mentions security services, it typically categorizes TEE under hardware abstraction layers or middleware without modular characterization. Given that TEE is directly related to vulnerability localization and threat modeling, we list it as an independent module.
Abstraction of vendor-specific labels: During the research process, vendor-specific labels (such as “Advanced Driver Assistance Systems (ADAS)”) were deliberately abstracted while retaining functional categories like audio processing, inter-process communication, and power management.
While some functions of individual modules and submodules will be mentioned in the results section, detailed descriptions of each module are beyond the scope of this study. Table 1 presents the alignment relationship between the automotive SoC software architecture and AUTOSAR concepts.
Table 1: Alignment of the Derived SoC Architecture with AUTOSAR Concepts
For example, in the use case of “detecting surrounding vehicles decelerating and alerting the driver,” the execution flow based on the above model is as follows: i) a camera sensor captures a video stream and sends the data to the image signal processor (ISP) submodule in the central processor’s kernel space; ii) the ISP driver checks conditions such as non-empty data and pixel saturation before sending the data to the digital signal module for real-time object detection; iii) the digital signal module uses an AI model to complete real-time object detection (determining whether surrounding vehicles are indeed decelerating); iv) upon detecting vehicle deceleration, the digital signal module immediately transmits this information to the kernel driver of the graphics processor module in the central processor, which then sends the message to the graphics processor firmware; v) the graphics processor renders warning information on the infotainment interface through the driver.
3.2 Step Two: Collection and Filtering of Automotive SoC Software CVEs
This process includes the following steps:
1. Download CVE list: Download the annual CVE list from the National Vulnerability Database (NVD) for the years 2018 to February 2025 (in JSON format) and import it into the database. Specific steps are detailed in our previous research.
2. Filtering automotive SoC software CVEs — Phase One: Execute search queries based on CVE description text and Common Platform Enumeration (CPE) to filter automotive SoC software vulnerabilities. Keywords used for filtering in CVE description text include: Auto, SoC, Qualcomm, Automotive, Texas, NXP, Renesas, NVIDIA, Snapdragon; while filtering in CPE uses chipset names (e.g., QCA6574AU, QCA6595AU, QCA6584AU, etc.). A complete list of keywords can be found in reference 3. This dual search query approach has significant advantages: sometimes the CVE description may not contain keywords directly pointing to automotive SoC software, in which case the chipset names in the CPE description can supplement identification; conversely, if the CPE does not record all affected valid chipsets, the CVE description can serve as a supplement. Details on optimizing query statements in this step can be found in our previous research. This step ultimately filtered out 1113 vulnerabilities.
3. Filtering automotive SoC software CVEs — Phase Two: After obtaining the vulnerability list, further verify the availability of open-source codebases. Some hyperlinks in the CVE detail pages can access the vulnerability code and patches; however, some early codebases may have broken links due to migration. Ultimately, 180 instances of automotive SoC software vulnerabilities were filtered out.
3.3 Step Three: Vulnerability Mapping
Mapping root causes of vulnerabilities: A manual analysis process was employed to map vulnerabilities to their root causes. To maximize objectivity, all 180 vulnerabilities were handled independently by two researchers (one from industry and one from academia). The researchers independently examined the source code and commit information corresponding to the assigned CVEs. Theoretically, a CVE may be caused by multiple factors, but to maintain consistency in manual classification and reduce ambiguity, this study maps each vulnerability instance to a single, most likely root cause. Early in the research, we referenced root cause classification methods from the literature to analyze automotive SoC software vulnerabilities, subsequently updating the classification method through open coding techniques to customize the root cause list. After the two researchers completed the mapping, internal discussions were held to resolve discrepancies and determine a unified mapping version.
Software architecture module mapping: The automotive SoC software architecture model was described in the first step. We attempted to map each vulnerability to software modules within the model, employing a four-level mapping scheme — each vulnerability is first mapped to the main software module, then sequentially to three levels of submodules. For example, the mapping path for CVE-2024-33049 is: Central Processor (CP) → Kernel Space → WLAN Module → WLAN Roaming and Scanning Management Module. During the mapping process, it is necessary to check the location of the vulnerability file in the codebase and manually analyze the code content to clarify its core functionality, thereby determining the corresponding submodule. For instance, for CVE-2024-33049, the associated file is umac/scan/dispatcher/src/wlan_scan_utils_api.c. The following guiding questions illustrate the module attribution determination process for this vulnerability file:
· What is the purpose of this file? The wlan_scan_utils_api.c file is responsible for controlling Wi-Fi scanning, network discovery, and connection management, while handling access point (AP) scanning required for network discovery, switching, and seamless roaming services (802.11k, 802.11v, 802.11r).
· Why is this file attributed to the central processor rather than an independent Wi-Fi module? Wi-Fi is part of the operating system’s network stack and is not an independent module; moreover, scanning operations require direct interaction with the operating system (e.g., Linux) network services.
· Why is this file attributed to kernel space rather than user space? User space components can initiate scanning requests but cannot directly access or control Wi-Fi hardware; management of Wi-Fi hardware is the responsibility of the kernel space Wi-Fi driver, which includes executing actual Wi-Fi scans, managing connections, and interacting with Wi-Fi firmware.
This example illustrates how the research team accurately maps the file containing the vulnerable code to the corresponding location in the architecture model by tracing the file, manually analyzing its details. Similarly, this mapping process was independently completed by two researchers, with discrepancies resolved through discussion to reach a unified mapping result.
Mapping vulnerability mitigation times: Tracking vulnerability mitigation times is crucial for automotive SoC software security analysis — patch delays can expose safety-critical systems to attack risks for extended periods, increasing security hazards over time. Understanding these delays helps prioritize hardening efforts and optimize response strategies for high-impact components. Therefore, this study records the mitigation times of 180 vulnerability codes and maps them to different software modules and CWE categories. The calculation of mitigation time (MT) uses Formula 1 (unit: days):
Where:
· GCD (Git Commit Date): The timestamp when the content was merged/applied to the public codebase (i.e., the publicly visible time);
· GAD (Git Commit Creation Date): The timestamp when the patch was created (i.e., the time the developer initially wrote the patch);
· RD (Report Date): The date the vulnerability was published in the NVD or disclosed through an official security announcement.
Mitigation time is typically calculated as the difference in days between the Git commit date and the report date. In special cases, if the report date is later than the commit date, it indicates that the vulnerability was discovered internally; in this case, the mitigation time is the difference in days between the Git commit date and the Git commit creation date; if the Git commit creation date and the Git commit date are the same day, the mitigation time is counted as 1 day (to avoid zero values).
4. Results and Analysis
This study ultimately identified 180 automotive SoC software vulnerabilities and completed all mapping work described in Section 3. This section presents the relationships between CVEs, CWEs, software modules, and vulnerability mitigation times, addressing the research questions.
RQ1: What are the root causes of automotive SoC software (ASoCS) vulnerabilities? To what extent can these root causes explain the identified vulnerabilities?
Table 2 lists the top 10 categories among the 16 root causes corresponding to the 180 CVEs.
The research results indicate that “missing size/length validation” is the most common root cause, involving 72 CVEs; followed by “improper condition checking” (25) and “improper concurrency control” (20).
Table 2: Root Causes of Automotive SoC Software Vulnerabilities
Figure 3 uses a Sankey diagram to analyze the distribution of these root causes across software modules, with the main findings as follows:
· 31 CVEs and 14 CVEs are attributed to “missing size/length validation” originating from the WLAN module and audio subsystem module, respectively (indicated by thick lines);
· The graphics processor module involves the most types of root causes (11), followed by the inter-process communication module (9) and WLAN module (7) (indicated by multiple lines);
· The module with the highest number of instances of “improper condition checking” is the most numerous (11), followed by “missing size/length validation” (9) and “improper concurrency control” (6).
The study also analyzes the mapping relationship between these root causes and automotive SoC software vulnerabilities’ CWE categories, with Figure 4 displaying a network diagram illustrating this association (purple nodes represent CWE, multi-colored nodes represent root causes), with the main findings as follows:
· “Missing size/length validation” leads to 22 instances of CWE-129 (improper array index validation) and 12 instances of CWE-120 (buffer copy without checking input size, i.e., “classic buffer overflow”) (indicated by thick edges);
· “Improper condition checking” and “missing size/length validation” are associated with 11 and 10 different CWEs, respectively (indicated by the number of edges connecting nodes);
CWE-416 (use after free) can be caused by 12 different root causes, followed by CWE-120 (8).
Figure 3: Distribution of Root Causes Among Software Modules
Figure 4: Association Between Root Causes and CWEs
The results of RQ1 clarify the frequently occurring root causes of vulnerabilities in automotive SoC software and their associations with different software modules and CWE categories. This dual-layer mapping not only reveals which architectural components are susceptible to specific types of defects but also incorporates these issues into a standardized vulnerability classification system. This conclusion can guide module-level hardening and the formulation of secure development standards, aligning remediation strategies with known defect patterns in automotive SoC software stacks.
RQ2: How are vulnerabilities distributed across different architectural components/modules in the automotive SoC software architecture model stack?
The research results show that vulnerabilities in kernel space, user space, and secure execution environments account for 86.6%, 11.9%, and 1.5%, respectively. Figure 5 further details the distribution of CVEs in kernel space: the tree diagram shows that the WLAN (42), audio subsystem (22), inter-process communication (19), and graphics processor (18) modules have the highest number of CVEs. Further breakdown of these modules reveals that the WLAN roaming and scanning management (16), multi-link operation (MLO) manager (12), and Advanced Linux Sound Architecture (ALSA) (12) submodules have the highest number of CVEs.
Figure 5: Distribution of CVEs in Software Modules
Figure 6: Distribution of CWEs in Software Modules
Figure 6 presents a heatmap showing the distribution of high-frequency CWEs across modules (red cells indicate the highest occurrence of a specific CWE in the corresponding module, with color gradients from light blue to dark blue indicating decreasing CWE counts), with the main findings as follows:
· The graphics processor module involves 9 types of CWEs, followed by the WLAN module and audio subsystem module (each with 8), and the inter-process communication module (7);
· The WLAN module is primarily associated with CWE-126 (buffer read out-of-bounds) (25 instances), the audio subsystem module with CWE-120 (7 instances), and the graphics processor module and inter-process communication module with CWE-416 (9 instances) and CWE-416 (8 instances), respectively.
The answer to RQ2 clarifies the frequency and distribution characteristics of CVEs and CWEs within the automotive SoC software architecture stack, helping system architects and developers prioritize security reviews, refactoring, or isolation strategies in these critical areas, while supporting layered defenses that align mitigation measures with the structural roles of components within the SoC stack.
RQ3: What differences exist in vulnerability mitigation times across different Common Weakness Enumeration (CWE) categories and automotive SoC software modules?
The results show that CWE-416 (use after free) and CWE-126 (buffer read out-of-bounds) account for 25.4% and 24.5% of total mitigation times, respectively; while the WLAN module and inter-process communication module account for 26.4% and 23.2% of total mitigation times, respectively.
Figure 7: Top) CWE and Bottom) Module Vulnerability Mitigation Time Variations
The study further analyzes the differences in mitigation times (days) for high-frequency CWEs, with Figure 7.a) presenting the results in a violin plot:
· Mitigation times for CWE-120 and CWE-190 (integer overflow or wraparound) show little fluctuation, with all CVEs completed within 1-3 months;
· Most CVEs for CWE-416 are fixed within 1-3 months, but a few take 5-7 months;
· Most CVEs for CWE-126 are fixed within 1-4 months, with only 1 case taking 11 months;
· CWE-823 (use of uninitialized pointer) has the widest distribution, with mitigation times ranging from 1 month to nearly 10 months.
The study also analyzes the differences in mitigation times for high-vulnerability modules, with Figure 7.b) showing a violin plot:
· The audio subsystem module has the least fluctuation in mitigation times, with most CVEs fixed within 1-2 months;
· The graphics processor module has the next least fluctuation, with most CVEs fixed within 3.5 months, and a few extending to 4.5 months;
· The WLAN module and inter-process communication module exhibit significant fluctuations in mitigation times, ranging from 1 day to about 1 year.
In answering RQ3, the analysis of mitigation times across CWE and architectural module dimensions provides important references for the operational security status of the automotive SoC software stack (which is particularly critical for safety-critical CPS systems like vehicles). Modules with shorter patch delays typically reflect good component maintenance, high developer engagement, efficient CI/CD integration, or simple dependency structures; conversely, prolonged mitigation times may indicate architectural complexity, unclear ownership, or low visibility in maintenance processes. Mapping these delays helps identify high-risk modules — the patch delays for these modules may expose safety-critical systems to risks for extended periods. This conclusion can guide the prioritization of security hardening efforts, drive architectural refactoring, and enhance the resilience of software lifecycle management by addressing areas of the architecture that respond slowly to security issues in CCAM.
Conclusion
“Missing size/length validation” is the primary root cause of vulnerabilities in automotive SoC software; vulnerabilities in the WLAN module account for 37% (primarily CWE-126); the graphics processor module involves the most CWE categories; CWE-416 has the longest mitigation time; and the WLAN module and inter-process communication module exhibit the greatest fluctuations in mitigation times.
5. Discussion
From the perspective of cyber-physical systems (CPS), the findings of this research raise critical concerns: as the automotive industry accelerates its transition to centralized SoC and software-defined vehicle architectures, in the worst-case scenario, a single software module’s CVE could be exploited by attackers to control the entire system. For example, a roadside unit (RSU) or access point controlled by an attacker sends malicious beacon frames (MBF) to the SoC Wi-Fi driver (part of the WLAN module in this model); due to the presence of CWE-126 (buffer read out-of-bounds) vulnerability in the wlan_mlo_t2lm.c file, this module fails to validate and receives the malicious beacon frames, potentially leading to various security issues: data leakage from uninitialized memory reads, distributed denial of service (DDoS) caused by Wi-Fi stack crashes, vehicle-to-infrastructure (V2I) communication failures, vehicle-to-vehicle (V2V) collision warning failures, fleet management and over-the-air (OTA) update interruptions, etc.
Although the architecture model of this study is not directly constructed based on the AUTOSAR blueprint, its structural and service layer similarities with the AUTOSAR adaptive platform make its conclusions generalizable to potential integration and migration use cases. For instance, a tier-one automotive supplier is migrating infotainment and connected electronic control units (ECUs) from proprietary real-time operating systems (RTOS) to the AUTOSAR adaptive platform, integrating Snapdragon SoCs and supporting V2I functionality via Wi-Fi. In this scenario, the results of this study can assist security leads in assessing high-security-risk modules and identifying areas that require prioritized mitigation or architectural hardening. Based on this assessment, companies can implement targeted integration hardening measures during third-party software procurement, conduct directed fuzz testing and buffer boundary checks, and require Wi-Fi drivers to adopt memory-safe implementations, among other actions.
6. Validity Threats
This study evaluates validity threats based on the framework by Wohlin and Staron:
Construct validity: The main risk is the omission of significant automotive SoC software vulnerabilities. The research method itself and the limitation of only using open-source SoC software may lead to vulnerabilities in core components of automotive SoCs, such as advanced driver assistance systems (ADAS) and digital cockpits, being overlooked. Additionally, the inclusion/exclusion criteria for real-time modules and high-end modules may also affect construct validity.
Conclusion validity: The main risk arises from the manual mapping process. Although automated tools such as large language models (LLMs) could be employed, the study ultimately chose to complete the mapping manually for ease of verification and discussion of results.
Internal validity: While mitigation time analysis is related to the architectural role or integration depth of modules, the dynamic characteristics of open-source projects (such as contributor activity and governance models) may also influence results, posing a potential threat to internal validity.
External validity: The core limitation is that the automotive SoC software architecture model is derived from open-source codebases, which may not cover all commercial SoC implementation variants. Although the model aligns with AUTOSAR concepts, it lacks formal validation (e.g., expert interviews, industry-validated mapping relationships).
7. Conclusion and Future Work
The automotive SoC software architecture is becoming increasingly centralized and complex. This evolution, while enhancing the efficiency of over-the-air (OTA) updates, expanding customer services empowered by cloud environments, enabling seamless data sharing, and optimizing power consumption, also exacerbates the inherent security risks of highly integrated cyber-physical systems (CPS) platforms. This study reveals the key areas most susceptible to vulnerabilities within the automotive SoC software architecture stack: by mapping 180 real vulnerabilities to software modules, CWE categories, root causes, chipsets, and mitigation delays, core trends (such as the concentration of WLAN module vulnerabilities and the high incidence of “missing size/length validation” defects) are identified.
The model constructed in this study, based on public codebases and aligned with AUTOSAR principles, helps identify vulnerable components that may be overlooked in traditional security audits. Security testers and architects using AUTOSAR can leverage the root cause mapping and delay patterns from this study to prioritize high-risk modules, conduct targeted hardening, and validate integration decisions during platform migration. Future research directions include collaborating with AUTOSAR practitioners and domain experts to validate the architecture model and expanding attack path analysis to cover a broader range of cyber-physical systems (CPS) domains.
This article is translated using software; please refer to the original text for any inaccuracies. For downloads, please scan the QR code:
Previous Highlights
