Automating Function-Level TARA for Automotive Full-Lifecycle Security

TL;DR

DefenseWeaver automates function-level Threat Analysis and Risk Assessment (TARA) for automotive cybersecurity by leveraging component-specific data and a multi-agent Large Language Model (LLM) framework. It introduces OpenXSAM++ as a structured representation for complex automotive configurations and combines LoRA fine-tuning with Retrieval-Augmented Generation (RAG) to adapt to evolving threats and standards. The system constructs attack trees by decomposing configurations into atomic structures, inferring attack methods with specialized LLM agents, and aggregating risk via a ISO/SAE 21434-aligned feasibility/impact scoring scheme. In real-world automotive deployments and cross-domain case studies (UAV and ECDIS), DefenseWeaver generated thousands of attack-tree artifacts, identified novel, configuration-dependent attack paths, and reduced analysis time by orders of magnitude compared with human experts, enabling scalable, proactive cybersecurity across industries.

Abstract

As modern vehicles evolve into intelligent and connected systems, their growing complexity introduces significant cybersecurity risks. Threat Analysis and Risk Assessment (TARA) has therefore become essential for managing these risks under mandatory regulations. However, existing TARA automation methods rely on static threat libraries, limiting their utility in the detailed, function-level analyses demanded by industry. This paper introduces DefenseWeaver, the first system that automates function-level TARA using component-specific details and large language models (LLMs). DefenseWeaver dynamically generates attack trees and risk evaluations from system configurations described in an extended OpenXSAM++ format, then employs a multi-agent framework to coordinate specialized LLM roles for more robust analysis. To further adapt to evolving threats and diverse standards, DefenseWeaver incorporates Low-Rank Adaptation (LoRA) fine-tuning and Retrieval-Augmented Generation (RAG) with expert-curated TARA reports. We validated DefenseWeaver through deployment in four automotive security projects, where it identified 11 critical attack paths, verified through penetration testing, and subsequently reported and remediated by the relevant automakers and suppliers. Additionally, DefenseWeaver demonstrated cross-domain adaptability, successfully applying to unmanned aerial vehicles (UAVs) and marine navigation systems. In comparison to human experts, DefenseWeaver outperformed manual attack tree generation across six assessment scenarios. Integrated into commercial cybersecurity platforms such as UAES and Xiaomi, DefenseWeaver has generated over 8,200 attack trees. These results highlight its ability to significantly reduce processing time, and its scalability and transformative impact on cybersecurity across industries.

Figures (15)

• Figure 1: DefenseWeaver is capable of automating function-level TARA by leveraging the power of LLMs for components with detailed attributes.
• Figure 2: Comparison of (a) vehicle-level TARA and (b) function-level TARA. Function-level TARA needs to consider extra dimensions such as hardware configurations (e.g., TC399), software versions (e.g., OpenSSL 1.1.0a), communication channels (e.g., CAN bus), interfaces (e.g., JTAG), internal connections (e.g., radio module and MCU) to comprehensively evaluate potential vulnerabilities.
• Figure 3: Framework of DefenseWeaver. Given a vehicle configuration and threat scenarios, DefenseWeaver will automatically convert the visual diagrams into proper representations (atomic structures), generate specific attack methods for each node (sub-trees) before assembling them into attack trees, and evaluate the risk level (from 1 to 5) according to the most feasible attack path for each threat scenario.
• Figure 4: A simplified IVN topology with one unique attack endpoint (BCM-MCU) and two entrypoints (IVI and OBD) according to given threat scenarios (e.g., disrupt the availability of BCM-MCU). The nodes are connected with channels.
• Figure 5: (a) Logical paths without detailed attack methods in each node, where irrelevant and redundant components (e.g., $B$) are removed. (b) The segmented node ($C$) and constructed atomic structures ($C_1$ and $C_2$) are derived based on the exit channels (e.g, channel $5$ and $6$) for sub-tree generation.