企业官网建设流程全解析

在自动驾驶系统开发与安全评估中，如何高效、精准地识别那些攻击者可能触及的软件弱点，是保障车辆安全上路的关键挑战。传统的静态代码分析和动态模糊测试虽然有效，但往往耗时耗力，且难以覆盖复杂的多模块交互场景。本文将探讨一种结合大语言模型（LLM）的动态威胁分析方法，旨在构建一个辅助分析框架，帮助安全工程师和开发者系统性地发现并评估自动驾驶系统中那些真正“可被攻击者利用”的软件漏洞。无论你是从事自动驾驶软件研发、车联网安全测试，还是对LLM在安全领域的应用感兴趣，本文都将提供一个从理论到实践的完整视角，包含核心概念、方法设计、原型实现思路以及工程化考量。

1. 背景与核心概念：为什么需要LLM辅助的动态威胁分析？

自动驾驶车辆是一个复杂的软硬件集成系统，其软件栈通常包括感知、定位、规划、控制等多个模块，并涉及大量的通信（V2X）、数据融合和决策逻辑。这些软件中的任何一个弱点，都可能被攻击者利用，导致车辆行为异常，引发严重的安全事故。

1.1 传统软件弱点分析的局限性传统的安全分析方法主要分为两类：

• 静态应用程序安全测试（SAST）：在不运行代码的情况下分析源代码或二进制文件，寻找潜在漏洞模式。其优点是覆盖全面，但误报率高，且难以判断一个漏洞在真实的、动态的运行环境中是否真的可被触发和利用。
• 动态应用程序安全测试（DAST）：在程序运行时进行测试，例如模糊测试（Fuzzing）、渗透测试。它能发现真实可触发的漏洞，但测试用例的生成和路径覆盖往往依赖于经验，对于自动驾驶这种状态空间巨大的系统，难以穷尽所有可能的攻击面。

核心问题在于：一个软件弱点（如缓冲区溢出、整数溢出）是否构成真正的威胁，取决于它是否在系统的“攻击者可达路径”上。攻击者可能通过车载网络（CAN总线）、无线通信（蓝牙/Wi-Fi/蜂窝网络）、物理接口（OBD-II）或恶意输入（伪造的传感器数据）来接触并触发这个弱点。

1.2 LLM能带来什么改变？大语言模型（LLM）在代码理解、逻辑推理和自然语言处理方面展现出强大能力。在动态威胁分析中，LLM可以扮演以下角色：

• 智能代码理解器：快速解析复杂的自动驾驶代码库（C++/Python/Rust），理解函数调用关系、数据流和控制流，辅助构建更精确的系统模型。
• 攻击面枚举与场景生成器：基于对系统架构和通信协议的理解，自动或半自动地枚举可能的攻击入口（如特定的CAN消息ID、ROS Topic、API端点），并生成更贴近真实攻击场景的测试用例或模糊测试种子。
• 动态执行日志分析器：在动态测试（如Fuzzing）过程中，实时分析程序崩溃、异常或边缘行为的日志，快速定位根本原因，并判断其是否属于攻击者可达的弱点。
• 威胁建模辅助工具：帮助安全分析师构建和维护系统的威胁模型，自动关联资产、威胁、弱点和安全控制措施。

1.3 核心目标：Attacker-Reachable Software Weaknesses本文聚焦的“攻击者可达的软件弱点”是评估风险的黄金标准。它指的是同时满足以下两个条件的弱点：

1. 存在性：在软件中存在一个可被利用的缺陷（如内存错误、逻辑错误）。
2. 可达性：攻击者能够通过某种可行的攻击向量，将精心构造的输入传递到该缺陷点，从而触发非预期的、有害的行为。 LLM辅助的动态威胁分析，其终极目标就是高效、自动化地识别和验证这类弱点，将安全工作的重点从“发现所有缺陷”转向“评估最关键的风险”。

2. 环境准备与原型框架设计思路

在开始具体实现前，我们需要明确技术选型和环境依赖。本文提出的框架是一个概念验证原型，旨在展示核心工作流程。

2.1 核心组件与工具链一个LLM辅助的动态威胁分析框架可能包含以下组件：

• 目标系统：自动驾驶软件模块（例如，基于ROS 2的感知节点、规划算法）。本文将以一个简化的CAN总线消息处理模块为例。
• 动态分析引擎：用于执行目标程序并监控其行为。例如：
  • AFL++、LibFuzzer：用于基于覆盖率的模糊测试。
  • Sanitizers（AddressSanitizer, UndefinedBehaviorSanitizer）：用于在运行时检测内存错误和未定义行为。
  • 自定义的测试执行环境。
• LLM集成层：负责与LLM交互。可以选择：
  • OpenAI GPT-4/4o API
  • Claude API
  • 本地部署的开源模型（如Llama 3、Qwen2.5-Coder、DeepSeek-Coder）。考虑到代码安全和延迟，本地模型是更优选择。
• 协调与监控脚本：使用Python编写，负责串联整个流程——启动测试、收集日志、调用LLM、解析结果、生成报告。

2.2 示例环境说明为了便于演示，我们假设以下环境：

• 操作系统：Ubuntu 22.04 LTS
• 编程语言：Python 3.10+（用于协调脚本），C++（用于示例目标程序）
• 编译工具：GCC/G++ 11+， 启用-fsanitize=address,undefined进行编译
• LLM服务：使用Ollama本地运行qwen2.5-coder:7b模型。你需要先安装Ollama并拉取该模型。
• 其他工具：jq(用于处理JSON)，tmux或screen(用于管理进程)

2.3 原型框架工作流程我们的框架将遵循一个闭环流程：

1. 初始化：加载目标程序信息（代码、接口文档）、配置LLM、定义攻击面（如CAN ID列表）。
2. 测试用例生成与增强：LLM根据攻击面和历史测试结果，生成或优化模糊测试的初始种子（seed corpus）。
3. 动态执行与监控：启动插桩后的目标程序，使用增强后的种子进行模糊测试或定向测试，同时收集代码覆盖率、崩溃、Sanitizer报告等数据。
4. 日志分析与根本原因推断：将崩溃堆栈、输入数据等日志发送给LLM，要求其分析弱点类型、根本原因，并判断攻击者可达性。
5. 报告与反馈：LLM生成结构化的分析报告。分析结果（如新发现的攻击向量）被反馈到步骤2，用于指导下一轮的测试用例生成。

3. 核心实现：构建一个简化的分析管道

本节我们将构建一个最小可行原型，演示LLM如何辅助分析一个简单的C++程序中的内存安全弱点。

3.1 目标程序：一个有缺陷的CAN消息处理器我们创建一个简单的C++程序can_processor.cpp，它模拟处理CAN消息，但存在一个典型的缓冲区溢出漏洞。

// 文件：can_processor.cpp #include <iostream> #include <cstring> #include <cstdint> // 模拟CAN消息结构 struct CanMessage { uint32_t id; uint8_t dlc; // 数据长度码 (0-8) uint8_t data[8]; }; // 有缺陷的消息处理函数 void processCanMessage(const CanMessage* msg) { char buffer[16]; // 固定大小的本地缓冲区 // 漏洞：未检查 dlc 是否超过 buffer 容量，直接使用 memcpy std::memcpy(buffer, msg->data, msg->dlc); // 如果 dlc > 16，则缓冲区溢出 buffer[15] = '\0'; // 尝试添加终止符，但溢出后可能无效 std::cout << "Processed CAN ID: 0x" << std::hex << msg->id << ", Data preview: " << buffer << std::endl; } // 主函数，从标准输入读取模拟的CAN数据 int main(int argc, char* argv[]) { CanMessage msg; // 简单从二进制输入读取数据（模拟来自网络或总线的数据） // 格式：4字节ID + 1字节DLC + 最多8字节数据 if (std::fread(&msg, sizeof(uint32_t) + 1, 1, stdin) != 1) { std::cerr << "Failed to read CAN header" << std::endl; return 1; } // 读取数据部分 if (msg.dlc > 0 && msg.dlc <= 8) { if (std::fread(msg.data, 1, msg.dlc, stdin) != msg.dlc) { std::cerr << "Failed to read CAN data" << std::endl; return 1; } } processCanMessage(&msg); return 0; }

使用AddressSanitizer编译此程序：

g++ -fsanitize=address,undefined -g -o can_processor can_processor.cpp

3.2 LLM辅助的测试用例生成器我们编写一个Python脚本llm_fuzz_seed_generator.py，它使用LLM基于对代码的分析来生成可能触发漏洞的测试输入。

# 文件：llm_fuzz_seed_generator.py import subprocess import json import sys import os # 配置Ollama本地模型端点 OLLAMA_URL = "http://localhost:11434/api/generate" MODEL_NAME = "qwen2.5-coder:7b" def analyze_code_with_llm(code_snippet): """ 将代码片段发送给LLM，请求其分析潜在漏洞和生成测试用例的思路。 """ prompt = f""" 你是一个高级网络安全分析师。请分析以下C++函数中的安全弱点，并生成一个能触发该弱点的具体测试输入（二进制格式描述）。 代码： ```cpp {code_snippet}

函数processCanMessage接收一个CanMessage指针。结构体定义如下： struct CanMessage {{ uint32_t id; uint8_t dlc; // 数据长度码 (0-8) uint8_t data[8]; }};

任务：

1. 指出代码中存在的具体安全漏洞类型。
2. 解释攻击者如何构造输入来利用此漏洞。
3. 提供一个具体的、十六进制表示的测试用例。这个用例应该能导致processCanMessage函数发生缓冲区溢出。请按以下格式描述：
   • CAN ID (4字节，小端序): e.g., 0x100
   • DLC (1字节): e.g., 0x20 (即十进制32，大于缓冲区大小16)
   • 数据 (DLC指定的字节数): e.g., 0x41 0x42 ... (填充足够多的字节)

请以JSON格式回答，包含字段：vulnerability_type,explanation,test_input_hex。 """ # 构建请求数据 request_data = { "model": MODEL_NAME, "prompt": prompt, "stream": False, "options": { "temperature": 0.1, # 低温度以获得更确定性的输出 } }

try: # 调用Ollama API result = subprocess.run( ['curl', '-s', '-X', 'POST', OLLAMA_URL, '-H', 'Content-Type: application/json', '-d', json.dumps(request_data)], capture_output=True, text=True, check=True ) response = json.loads(result.stdout) llm_output = response.get('response', '').strip() # 尝试从LLM输出中提取JSON部分（LLM可能在JSON外添加了说明文字） # 这里进行简单处理，实际应用中需要更健壮的解析 start_idx = llm_output.find('{') end_idx = llm_output.rfind('}') + 1 if start_idx != -1 and end_idx != 0: json_str = llm_output[start_idx:end_idx] return json.loads(json_str) else: print(f"LLM did not return valid JSON. Output: {llm_output}") return None except (subprocess.CalledProcessError, json.JSONDecodeError) as e: print(f"Error calling LLM or parsing response: {e}") return None

def generate_seed_file(analysis_result, output_path="llm_generated_seed.bin"): """ 根据LLM的分析结果，生成一个二进制的种子文件。 """ if not analysis_result or 'test_input_hex' not in analysis_result: print("No valid test input from LLM.") return

hex_str = analysis_result['test_input_hex'].replace('0x', '').replace(' ', '').replace(',', '') try: # 将十六进制字符串转换为字节 bytes_data = bytes.fromhex(hex_str) with open(output_path, 'wb') as f: f.write(bytes_data) print(f"[+] Seed file generated: {output_path}") print(f"[+] LLM identified vulnerability: {analysis_result.get('vulnerability_type', 'N/A')}") except ValueError as e: print(f"Error converting hex to bytes: {e}. Hex string: {hex_str}")

ifname== "main": # 读取目标代码文件 code_file = "can_processor.cpp" if not os.path.exists(code_file): print(f"Error: {code_file} not found.") sys.exit(1)

with open(code_file, 'r') as f: code = f.read() print("[*] Sending code to LLM for analysis and test case generation...") result = analyze_code_with_llm(code) if result: print("[*] LLM Analysis Result:") print(json.dumps(result, indent=2)) generate_seed_file(result) else: print("[!] Failed to get analysis from LLM.")

运行此脚本前，请确保Ollama服务已启动且模型已加载。脚本会输出LLM的分析结果并生成一个二进制种子文件。 **3.3 执行动态测试与收集崩溃信息** 现在我们使用生成的种子文件来运行目标程序，并触发崩溃。 ```bash # 1. 运行LLM辅助的种子生成器 python3 llm_fuzz_seed_generator.py # 2. 使用生成的种子文件作为输入，运行目标程序 # AddressSanitizer会在检测到错误时输出详细的报告 ./can_processor < llm_generated_seed.bin

如果LLM成功生成了一个dlc > 16的测试用例，程序将因缓冲区溢出而崩溃，AddressSanitizer会输出类似如下的报告：

================================================================= ==114514==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd4a3b82f0 ... WRITE of size 32 at 0x7ffd4a3b82f0 thread T0 #0 0x55a1b2b3c1d1 in processCanMessage(...) can_processor.cpp:14 #1 0x55a1b2b3c2ca in main can_processor.cpp:35 ...

3.4 LLM辅助的崩溃日志分析接下来，我们编写另一个脚本llm_crash_analyzer.py，将崩溃日志和原始的测试输入发送给LLM，要求其进行根本原因分析和可达性判断。

# 文件：llm_crash_analyzer.py import subprocess import json import sys def analyze_crash_with_llm(crash_log, test_input_hex, code_snippet): """ 将崩溃日志、测试输入和代码发送给LLM，进行深入分析。 """ prompt = f""" 你是一个漏洞分析专家。以下是来自一个自动驾驶CAN消息处理器的测试崩溃报告、触发崩溃的输入以及相关源代码。 源代码片段（有漏洞的函数）： ```cpp {code_snippet}

触发崩溃的测试输入（十六进制）： {test_input_hex}

AddressSanitizer崩溃日志摘要：

{crash_log[:2000]} # 截取前2000字符，通常包含关键信息

请完成以下任务：

1. 根本原因分析：精确描述漏洞的触发机理。是缓冲区溢出、整数溢出还是其他？在代码的哪一行？
2. 攻击者可达性评估：
   • 攻击向量：攻击者可以通过什么渠道传递这个恶意输入？（例如：伪造CAN总线消息、通过车载信息娱乐系统注入、远程OTA更新等）
   • 前提条件：触发此漏洞需要满足哪些系统状态或条件？（例如：车辆处于某种模式、特定ECU上电等）
   • 影响评估：成功利用此漏洞可能导致什么后果？（例如：程序崩溃导致功能失效、任意代码执行、车辆控制权被篡改）
3. 修复建议：提供1-2条具体的代码修复建议。

请以JSON格式回答，包含以下字段：root_cause,attack_vector,prerequisites,potential_impact,fix_suggestions(列表)。 """ request_data = { "model": MODEL_NAME, "prompt": prompt, "stream": False, "options": {"temperature": 0.1} }

try: result = subprocess.run( ['curl', '-s', '-X', 'POST', OLLAMA_URL, '-H', 'Content-Type: application/json', '-d', json.dumps(request_data)], capture_output=True, text=True, check=True ) response = json.loads(result.stdout) llm_output = response.get('response', '').strip() start_idx = llm_output.find('{') end_idx = llm_output.rfind('}') + 1 if start_idx != -1 and end_idx != 0: return json.loads(llm_output[start_idx:end_idx]) else: print("Could not parse JSON from LLM response.") return None except Exception as e: print(f"Error during LLM analysis: {e}") return None

ifname== "main": # 这里需要手动或从文件读取崩溃日志和测试输入 # 示例：从文件读取 with open('asan_crash.log', 'r') as f: crash_log_content = f.read() with open('llm_generated_seed.bin', 'rb') as f: test_input_bytes = f.read() test_input_hex = test_input_bytes.hex() with open('can_processor.cpp', 'r') as f: code_content = f.read()

print("[*] Sending crash log to LLM for in-depth analysis...") analysis = analyze_crash_with_llm(crash_log_content, test_input_hex, code_content) if analysis: print("\n" + "="*60) print("LLM-AIDED DYNAMIC THREAT ANALYSIS REPORT") print("="*60) print(f"Root Cause: {analysis.get('root_cause', 'N/A')}") print(f"\nAttack Vector: {analysis.get('attack_vector', 'N/A')}") print(f"Prerequisites: {analysis.get('prerequisites', 'N/A')}") print(f"Potential Impact: {analysis.get('potential_impact', 'N/A')}") print(f"\nFix Suggestions:") for i, suggestion in enumerate(analysis.get('fix_suggestions', []), 1): print(f" {i}. {suggestion}") print("="*60) else: print("[!] Crash analysis failed.")

运行此脚本，你将得到一份结构化的威胁分析报告，其中包含了LLM对漏洞可达性和影响的评估。 ## 4. 整合与自动化：构建完整的分析循环 将上述步骤整合，我们可以设计一个自动化的分析管道。以下是一个高级别的协调脚本 `llm_assisted_dynamic_analysis.py` 的框架： ```python # 文件：llm_assisted_dynamic_analysis.py (框架示例) import subprocess import time import os from pathlib import Path class LLMAssistedDynamicAnalyzer: def __init__(self, target_binary, source_code, initial_seeds_dir): self.target_binary = target_binary self.source_code = source_code self.seeds_dir = Path(initial_seeds_dir) self.crashes_dir = Path("./crashes") self.crashes_dir.mkdir(exist_ok=True) self.llm_analysis_history = [] def run_fuzzing_session(self, duration_sec=300): """ 使用AFL++或其他fuzzer运行一个会话。 """ # 这里简化表示，实际需要调用AFL的命令行 # afl-fuzz -i seeds_dir -o output_dir -- ./target_binary @@ cmd = f"afl-fuzz -i {self.seeds_dir} -o afl_output -M master -- {self.target_binary} @@" print(f"[*] Starting fuzzing: {cmd}") # 使用subprocess.Popen在后台运行 # ... 实际实现需要处理进程和超时 def monitor_and_collect_crashes(self, output_dir): """ 监控fuzzing输出，收集新的崩溃用例。 """ crashes_queue = Path(output_dir) / "master" / "crashes" new_crashes = [] for crash_file in crashes_queue.glob("id:*"): # 检查是否是新崩溃 # ... 实现去重逻辑 new_crashes.append(crash_file) return new_crashes def analyze_crash_with_llm(self, crash_file, input_file): """ 对单个崩溃用例进行LLM辅助分析（集成第3.4节的功能）。 """ # 1. 使用调试器或ASAN运行目标程序，获取更详细的崩溃日志 # 2. 调用LLM分析函数 # 3. 返回结构化的分析结果 pass def generate_enhanced_seeds(self, analysis_results): """ 基于历史分析结果，让LLM生成更有针对性的新测试种子。 """ # 提示LLM：“基于过去发现的X个缓冲区溢出漏洞都发生在memcpy操作，且DLC未被验证， # 请生成一些边界条件的测试用例，例如DLC=0, DLC=9, DLC=255等。” pass def run(self, iterations=5): """ 主循环：模糊测试 -> 收集崩溃 -> LLM分析 -> 生成新种子 -> 继续测试。 """ for i in range(iterations): print(f"\n[*] Iteration {i+1}/{iterations}") # 1. 运行模糊测试 self.run_fuzzing_session(duration_sec=60) # 2. 收集崩溃 new_crashes = self.monitor_and_collect_crashes("afl_output") print(f"[+] Found {len(new_crashes)} new crashes.") # 3. 分析每个崩溃 for crash in new_crashes: analysis = self.analyze_crash_with_llm(crash, ...) if analysis and self.is_attacker_reachable(analysis): # 可达性判断 self.llm_analysis_history.append(analysis) self.generate_report(analysis) # 4. 基于分析历史，生成增强种子，放入 seeds_dir 供下一轮使用 if self.llm_analysis_history: self.generate_enhanced_seeds(self.llm_analysis_history[-5:]) # 取最近5次分析 time.sleep(2) def is_attacker_reachable(self, analysis): """ 根据LLM的分析结果，判断弱点是否攻击者可达（可基于规则或LLM评分）。 """ # 简单的规则：如果攻击向量明确且不为空，则认为是可达的。 attack_vec = analysis.get('attack_vector', '').lower() unreachable_keywords = ['物理隔离', '需要内核权限', '调试接口'] if any(kw in attack_vec for kw in unreachable_keywords): return False return bool(attack_vec) def generate_report(self, analysis): """ 生成最终的安全报告。 """ report_path = f"./reports/crash_{len(self.llm_analysis_history)}.md" with open(report_path, 'w') as f: f.write(f"# 安全漏洞分析报告\n\n") f.write(f"**根本原因**: {analysis['root_cause']}\n\n") f.write(f"**攻击向量**: {analysis['attack_vector']}\n\n") f.write(f"**可达性评估**: {'高 - 攻击者可达' if self.is_attacker_reachable(analysis) else '中/低'}\n\n") f.write(f"**修复建议**:\n") for sugg in analysis['fix_suggestions']: f.write(f"- {sugg}\n") print(f"[+] Report generated: {report_path}") if __name__ == "__main__": analyzer = LLMAssistedDynamicAnalyzer( target_binary="./can_processor", source_code="can_processor.cpp", initial_seeds_dir="./initial_seeds" ) analyzer.run(iterations=3)

这个框架展示了如何将LLM嵌入到一个动态分析循环中，实现从漏洞发现、分析到测试用例进化的自动化。

5. 常见问题与排查思路

在实现和运行上述框架时，你可能会遇到以下问题：

6. 最佳实践与工程化建议

将LLM辅助动态威胁分析应用于真实的自动驾驶项目，需要遵循以下最佳实践：

6.1 系统与数据准备

• 构建精准的系统模型：为LLM提供尽可能完整的上下文，包括系统架构图、软件模块依赖关系、通信协议规范（如CANdb/DBC文件、ROS msg定义）、硬件接口文档。这能极大提升LLM对攻击面和可达性判断的准确性。
• 创建高质量的种子语料库：初始的测试种子不应是随机的。应包含：1) 正常通信流量抓包；2) 协议规范中的有效消息示例；3) 历史测试中发现的边缘用例。LLM可以从这些高质量种子开始进行变异和增强。
• 定义清晰的攻击面清单：明确列出所有可能的攻击入口，如：车载诊断接口、无线通信模块（蓝牙/Wi-Fi/4G/5G）、USB端口、传感器输入接口、V2X通信、OTA更新通道等。在Prompt中让LLM专注于这些清单内的向量。

6.2 Prompt工程与LLM交互

• 角色扮演与任务分解：在Prompt中明确LLM的角色（如“资深汽车安全研究员”），并将复杂任务分解为多步。例如，先要求“识别代码缺陷”，再要求“评估该缺陷在给定攻击面下的可达性”，最后要求“生成验证用例”。
• 提供结构化示例：在Few-shot Prompting中，提供几个“代码-漏洞-可达性分析-测试用例”的完整示例，教导LLM你期望的输出格式和推理深度。
• 设置合理的推理参数：对于代码分析和漏洞推理，使用较低的temperature（如0.1-0.3）以获得更确定、一致的结果。对于创意性的测试用例生成，可以适当调高。

6.3 集成到CI/CD与安全流程

• 作为辅助工具，而非决策主体：LLM的分析结果应始终被视为“辅助信息”或“初筛结果”，必须与传统的静态分析工具（如Coverity, Klocwork）、动态分析工具（如模糊测试）以及人工代码审计相结合。
• 设立漏洞分类与分流机制：根据LLM分析报告中的“攻击向量”和“潜在影响”，建立自动化的漏洞工单分类系统。高可达性、高影响的漏洞应立即触发警报并分配给资深安全工程师。
• 持续迭代与反馈：将安全工程师对LLM分析报告的复核结果（正确/错误，原因）收集起来，形成一个反馈数据集。这个数据集可以用于微调LLM或优化Prompt，形成闭环，不断提升分析的准确率。

6.4 安全与合规考量

• 代码与数据安全：如果使用云端LLM API，务必不要上传包含核心知识产权或未公开漏洞细节的源代码。应对代码进行适当的脱敏处理（如替换关键变量名、保留逻辑结构），或严格使用本地部署的模型。
• 合规性：确保整个安全测试流程符合公司内部的研发安全规范以及外部的行业标准（如ISO 21434, UN R155）。所有测试应在专用的、隔离的测试环境（如硬件在环HIL、车辆在环VIL）中进行，严禁对实际上路车辆进行未授权的安全测试。

通过将大语言模型与传统的动态安全测试方法相结合，我们能够构建一个更智能、更聚焦于真实威胁的自动化分析管道。这种方法的核心价值在于，它不仅能发现漏洞，更能持续评估漏洞的被利用风险，从而帮助自动驾驶团队将有限的安全资源投入到修复那些最危险、攻击者最可能触及的软件弱点上。虽然目前该技术仍处于探索阶段，在准确性、效率以及与现有工具链的集成度上面临挑战，但它无疑为自动驾驶软件安全工程提供了一个充满潜力的新方向。