## 3 Methodology
### Phase 2: CVSS v4.0 Scoring  
The vulnerabilities identified in Phase 1 were assessed using the CVSS v4.0 framework. To ensure relevance to the automotive context, the assigned CVSS scores were validated against automotive-specific criteria detailed in [40; 41]. This validation process considered factors such as the following:  
* Exploitability of vulnerabilities within vehicular communication channels (e.g., CAN bus vulnerabilities). * The potential impact on the automated driving system. The methodology for assessing cybersecurity risks in the automotive domain is built upon a targeted survey. This survey was distributed to cybersecurity risk analysts specializing in the automotive domain, and we are pleased to report a (100%) response rate, with 10 experts providing their valuable insights. These individuals are not general automotive industry experts but rather seasoned cybersecurity risk analysts, each possessing over a decade of dedicated experience directly in vehicle security systems and automotive product development. Their expertise extends across critical areas, including an in-depth understanding of in-vehicle network architectures, proficiency in relevant automotive cybersecurity standards (e.g., ISO 21434, UNECE WP29 R155), extensive experience in automotive-specific threat modeling and risk assessment, and practical knowledge of cybersecurity testing methodologies. The primary goal of this survey was to leverage their granular knowledge to validate the CVSS v4.0 scoring attributes for each of the 15 identified attack types, thereby ensuring robust alignment with real-world threat assessment. The survey was meticulously designed to evaluate each attack scenario specifically using the CVSS v4.0 metrics, drawing directly on their deep specialized insights from years of practical experience in this critical and evolving field. The structured questionnaire was used to collect expert evaluations for each individual attack. Each attack was described using the standardized format outlined in Table 1, ensuring consistency and minimizing ambiguity. The questionnaire covered all base metrics of the CVSS v4.0 framework, and each question included predefined answer choices corresponding to the standardized metric values as shown below:  
* Attack Vector (AV): What level of proximity is required to exploit the vulnerability? * Network (N): Exploitable remotely (e.g., via the internet);
* Adjacent (A): Requires same local network (e.g., Bluetooth and Wi-Fi);
* Local (L): Requires local access (e.g., USB port or internal interface);
* Physical (P): Requires direct physical contact (e.g., hardware tampering). * Attack Complexity (AC): How difficult is it to successfully execute the attack? * Low (L): Easy to exploit, no significant preconditions;
* High (H): Requires advanced techniques or overcoming security mechanisms. * Attack Requirements (AT): Are any specific conditions or configurations needed for the attack? * None (N): Works with standard/default settings;
* Present (P): Requires specific or non-default settings (e.g., debug mode enabled). * Privileges Required (PR): What level of system privileges must an attacker have to perform the attack? * None (N): No prior access required;
* Low (L): Basic user-level access;
* High (H): Administrative or elevated privileges. * User Interaction (UI): Does the attack require any user action to succeed? * None (N): Fully automated, with no user input needed;
* Required (R): Needs user engagement (e.g., clicking a malicious link). * Confidentiality (C): To what extent does the attack compromise data confidentiality? * None (N): No data exposure;
* Low (L): Limited or non-sensitive data exposure;
* High (H): Full or critical data disclosure. * Integrity (I): To what extent can the attack modify or corrupt data? * None (N): No data tampering;
* Low (L): Minor or non-critical data changes;
* High (H): Complete or critical data manipulation. * Availability (A): What is the impact on system availability?