摘要
协同、互联与自动化出行（CCAM）是复杂的信息物理系统（CPS），在安全关键型环境中整合了计算、通信和控制功能。其核心是片上系统（SoC）平台，该平台将处理单元、通信接口、人工智能加速器和安全模块集成于单芯片之中。汽车领域制定了 AUTOSAR（汽车开放系统架构）标准，旨在更好地管理这种复杂性，该标准定义了分层软件结构和接口，并促进软硬件组件的复用。然而，在实际应用中，这种集成式 SoC 软件架构仍面临安全挑战，尤其是在实时、安全关键型环境中。近期报告显示，与 SoC 相关的漏洞数量激增，但目前缺乏对这些漏洞在符合 AUTOSAR 标准的架构中的根本原因及影响的系统性分析。本研究通过分析 180 个公开报告的汽车 SoC 漏洞，填补了这一空白。这些漏洞被映射到一个具有代表性的 SoC 软件架构模型，该模型遵循 AUTOSAR 的分层抽象和面向服务原则。研究识别出 16 个漏洞根本原因和 56 个受影响的软件模块，并分析了不同通用缺陷枚举（CWE）类别和架构层的漏洞缓解延迟。研究揭示了主要的漏洞模式和补丁延迟较长的关键模块，并为汽车 CPS 平台的安全防护提供了切实可行的见解，包括针对 SoC 软件架构的改进检测、优先级排序和定位策略指南。
1、引言
安全的软件架构在现代协同、互联与自动化出行（CCAM）中起着至关重要的作用。随着功能需求的不断增长 ------ 从性能优化、信息娱乐到自动驾驶，汽车软件系统需要持续演进。汽车片上系统（SoC）一直是 CCAM 生态系统的核心组成部分，将多种功能集成在单芯片上。历史上，微控制器主要处理发动机控制和制动等独立任务。在过去二十年中，英伟达、高通、英特尔等厂商的 SoC 已从提供常规信息娱乐和安全功能，转变为高性能人工智能驱动的处理器，支持自动驾驶、高级信息娱乐和其他互联功能。这一转变带来了显著的架构复杂性。软件模块数量的增加、模块间的分层交互以及 SoC 内部功能集成的不断深化，为系统级分析和安全防护带来了新的挑战。
由于汽车软件采用了开放的生态系统，同时包含汽车专用模块和通用模块，汽车 CPS 的安全性已成为一个紧迫的问题。近期涉及数据泄露、远程控制漏洞利用和服务中断的事件凸显了普遍存在的风险。已有研究表明，过去八年报告的汽车软件漏洞中，近 67% 与基于 SoC 的系统直接相关。考虑到现代 SoC 的集成密度，单一功能中的漏洞可能会危及整个系统栈。
尽管 AUTOSAR 提供了标准化的参考架构，但其规范（尤其是在经典平台和自适应平台中）具有抽象性和平台无关性，并非为现实世界漏洞的直接映射而设计。相比之下，漏洞通常在代码层面被报告，与特定的驱动程序、固件或系统服务软件相关联。因此，我们首先通过研究开源 SoC 软件仓库，推导了一个中间架构模型，以了解实际模块（如无线局域网驱动程序、进程间通信服务、硬件抽象层等）的结构和部署方式。随后，我们将该架构与 AUTOSAR 概念对齐，以保持兼容性。我们从国家漏洞数据库（NVD）中选取了一组经过筛选的公开报告的汽车 SoC 软件（ASoCS）漏洞，并将其映射到该代表性架构模型。尽管开源汽车仓库的可用性有限，但本研究通过以下一系列重点研究问题（RQ）揭示了关键趋势和模式：
· RQ1：汽车 SoC 软件（ASoCS）漏洞的根本原因是什么？这些根本原因在多大程度上能够解释已识别的漏洞？
· RQ2：漏洞在汽车 SoC 软件（ASoCS）架构模型栈的不同架构组件 / 模块中如何分布？
· RQ3：漏洞缓解时间在不同的通用缺陷枚举（CWE）类别和汽车 SoC 软件（ASoCS）模块之间有何差异？
本研究在汽车 SoC 软件（ASoCS）架构及其漏洞方面做出了以下贡献：1）采用基于文献、符合 AUTOSAR 标准的汽车 SoC 软件（ASoCS）架构模型，研究架构层面临的现实世界漏洞风险；2）通过回答上述研究问题，呈现关于汽车 SoC 软件（ASoCS）漏洞的多项发现；3）讨论 CPS 和 AUTOSAR 特定用例，以反映研究结果的实际意义。特别是，我们的发现能够帮助软件架构师和安全测试负责人更快地识别高风险模块、优先开展安全设计工作，并改进漏洞分析。此外，我们的组件级漏洞映射有助于在组件选择和采购过程中做出更明智的决策，从而提升基于 SoC 的车辆平台的整体软件质量和安全态势。
2、相关工作
本节重点介绍分析汽车 CPS 软件及其安全性的相关研究，其中部分为分析类研究，部分提出了实际解决方案。
加西亚等人开展了一项探索性研究，分析了两个最受欢迎的自动驾驶开源软件项目（Autoware 和百度 Apollo）中的汽车软件漏洞。他们研究了 499 个漏洞，报告了其根本原因，并识别了受影响的软件组件。
马什库尔等人提出了一种面向安全关键型软件系统的模型驱动工程系统映射方法。作者从汽车领域选取了 29 篇研究论文（数量最多），其中 11 篇属于架构和设计阶段。通过对这些论文的审查，我们发现很少有研究在其分析中采用参考架构。其中一篇论文采用 Evita 汽车参考架构研究车载网络，但未发现任何涉及汽车 SoC 软件架构映射的论文。
巴苏和斯塔龙对 2018-2024 年期间的汽车软件漏洞进行了实证研究，主要关注 1663 个已识别漏洞的通用漏洞评分系统（CVSS）得分、攻击向量和通用缺陷枚举（CWE）类别的分布情况。
贝拉等人提出了 CINNAMON，这是一个基于 AUTOSAR 经典平台的基础软件模块（BSW），通过在标准安全车载通信（SecOC）模块现有的完整性和认证保障基础上增加机密性，增强了车载通信安全性。与不提供加密功能的 SecOC 不同，CINNAMON 集成了加密保护、新鲜度验证和可配置安全配置文件。作者在基于 STM32 的电子控制单元（ECU）原型上实现并评估了该模块，且仅产生了最小的性能开销。他们的工作通过展示如何将安全模块设计嵌入到 AUTOSAR 的通信栈中，补充了我们的漏洞中心型分析。
尽管已有研究在汽车软件安全方面提供了宝贵的见解（如漏洞分类、CVE 分析或模型驱动的安全技术），但大多数研究要么聚焦于单个仓库，要么提供高层级分析，缺乏架构层面的支撑。我们的映射方法将漏洞与符合 AUTOSAR 标准的架构中的功能块对齐，基于现实世界的软件结构提供了实用、可操作的见解。通过在具有代表性的 SoC 软件栈中定义明确的层和模块内组织和分析漏洞，本研究有助于实现有针对性的漏洞定位和更深入的根本原因识别。这种架构视角能够支持安全测试人员、软件架构师和采购团队等行业从业者精准定位高风险模块、预测缓解延迟，并在组件选择和软件质量保证方面做出明智决策。
3、方法论：架构建模、漏洞数据收集与映射
本研究遵循的方法分为三个部分。首先，如步骤 1 所述，推导汽车 SoC 软件（ASoCS）架构模型；其次，在步骤 2 中收集汽车 SoC 软件（ASoCS）漏洞（即通用漏洞披露（CVE）[5]），并识别其中包含开源代码的漏洞；最后，在步骤 3 中介绍漏洞映射方法，包括：i）与根本原因的映射；ii）与架构模块的映射；iii）与缓解时间的映射。
所有手动分析或决策均由两名研究人员（一名来自行业，一名来自学术界）共同完成。我们使用科恩卡帕系数（Cohen's Kappa coefficient）衡量两名研究人员之间的一致性，得分达到 0.81，表明我们的手动流程具有高度一致性。
3.1 步骤 1：汽车 SoC 软件架构模型
本研究采用基于广泛使用的汽车和嵌入式平台及标准的归纳式、文献驱动方法，推导了具有代表性的汽车 SoC 软件（ASoCS）架构模型。该模型是通过对开源仓库（包括安卓开源项目（AOSP）、代码极光论坛（CAF）和高通板级支持包（BSP）层）的详细调查构建的。研究这些仓库是为了了解 SoC 组件的功能分解和文件组织。通过分析目录结构、依赖图和接口定义，提取重复出现的架构模式和软件边界。为确保与行业实践的结构一致性，我们将提取的架构层与 AUTOSAR 对齐，AUTOSAR 为现代汽车平台定义了面向服务的分层架构模型。图 1（完整软件架构）和图 2（中央处理器模块的内核空间和用户空间）展示了我们架构模型的简明视图。主要推导原则如下：
中央处理器（CP）的分层分解
中央处理器（CP）分为用户空间、内核空间和安全执行环境（SEE），以反映嵌入式汽车环境中的安卓 / Linux 系统层。此外，我们模型中用户空间和内核空间的分离与 AUTOSAR 的分层抽象一致，其中应用级功能（自适应应用程序）与底层执行服务（如基础层中提供的基于 POSIX 的操作系统和执行管理模块）解耦。
图1、汽车SoC软件架构模型
图2、ASoCS，中央处理器：内核和用户空间
基于功能的子系统隔离
数字信号、通信、图形处理等模块根据骁龙汽车（Snapdragon Automotive）和英伟达 DRIVE 等平台进行分离。每个模块都有固件、驱动程序和特定功能的应用程序接口（API），与中央处理器（CP）交互但半独立运行。其中一些模块（如通信、输入输出内存管理单元（IOMMU）、进程间通信（IPC）等）对应于 AUTOSAR 平台中定义的基础软件模块。然而，为了捕捉现实世界中的 SoC 集成模式，我们的模型还包括了神经处理器和图形处理器等额外模块，这些模块在 AUTOSAR 中未被明确指定或抽象。这种偏差是合理的，因为人工智能加速器和基于高级图形处理器（GPU）的信息娱乐系统在汽车 SoC 中的集成日益增多。这种混合方法使我们能够在保持与 AUTOSAR 面向服务原则总体对齐的同时，适应商业 SoC 平台中存在的架构多样性。
安全域识别
我们的模型中明确保留了安全执行环境（SEE）等组件，以反映高通和基于 ARM 的 SoC 中常见的可信执行环境（TEE）实现。尽管 AUTOSAR 提到了安全服务，但通常将可信执行环境（TEE）视为硬件抽象或中间件的一部分，没有进行模块化表示。由于这些组件与漏洞定位和威胁建模直接相关，我们选择将其作为独立模块纳入模型。
抽象供应商特定标签
我们特别注意抽象供应商特定标签（如 "高级驾驶辅助系统（ADAS）"），同时保留功能类别，如音频处理、处理器间通信和电源管理等服务。
尽管在呈现结果时会讨论其中一些模块和子模块的功能，但每个模块的详细描述超出了本文的范围。表 1 展示了汽车 SoC 架构与 AUTOSAR 概念的对齐情况。
表 1、推导的 SoC 架构与 AUTOSAR 概念的功能对齐
如图 2 所示，中央处理器（CP）运行通用代码，控制任务的发送，并管理自身与其他专用处理器（数字信号模块（DSM）、图形处理模块（GPM）等）之间的通信。例如，考虑使用上述模型检测附近车辆减速并向驾驶员发出警报的用例场景，步骤如下：i）摄像头传感器捕获视频流，并将数据发送到中央处理器（CP）的图像信号处理器（ISP）子模块（内核空间）；ii）在检查数据非空、所有像素完全饱和等各种因素后，图像信号处理器（ISP）驱动程序将数据发送到数字信号模块（DSM）进行实时目标检测；iii）数字信号模块（DSM）使用其人工智能模型进行实时目标检测（尝试确定另一辆车是否确实在减速）；iv）一旦数字信号模块（DSM）检测到车辆减速，便将该信息传达给图形处理模块（GPM）的中央处理器（CP）内核驱动程序，该驱动程序进而将消息发送到图形处理模块（GPM）固件；v）图形处理模块（GPM）使用其驱动程序在信息娱乐系统上呈现警告信息。
3.2 步骤 2：汽车 SoC 软件 CVE 收集与筛选
该过程包括以下步骤：
-
下载 CVE 列表：从国家漏洞数据库（NVD）下载 2018 年至 2025 年 2 月的年度 CVE 列表（JSON 格式），并导入数据库。详细步骤可参见我们之前的研究。
-
汽车 SoC 软件（ASoCS）CVE 筛选 ------ 第一阶段：基于 CVE 描述文本和通用平台枚举（CPE）执行搜索查询，以筛选汽车 SoC 软件（ASoCS）漏洞。关键词包括 "汽车（Auto）""片上系统（SoC）""高通（Qualcomm）""汽车行业（Automotive）""德州仪器（Texas）""恩智浦（NXP）""瑞萨（Renesas）""英伟达（NVIDIA）""骁龙（Snapdragon）"，用于筛选 CVE 描述文本；芯片组名称（如 QCA6574AU、QCA6595AU、QCA6584AU 等）用于筛选通用平台枚举（CPE）。
这种双重搜索查询非常有效，因为有时 CVE 描述可能不包含表明其与汽车 SoC 软件（ASoCS）相关联的直接关键词，而在所有此类情况下，通用平台枚举（CPE）描述中的芯片组名称可以提供相关结果。此外，可能存在通用平台枚举（CPE）未注册所有受影响的有效芯片组的情况，此时 CVE 描述可以起到补充作用。本步骤最终筛选出 1113 个漏洞。
- 汽车 SoC 软件（ASoCS）CVE 筛选 ------ 第二阶段：获得漏洞列表后，我们进一步检查这些漏洞是否有可用的开源仓库。CVE 详情页面中的一些超链接提供了访问漏洞代码及其补丁的途径。此外，一些较旧的代码仓库已从一个主机迁移到另一个主机，导致仓库链接无法访问。最终列表包含 180 个汽车 SoC 软件（ASoCS）漏洞实例。
3.3 步骤 3：漏洞映射
映射 ------ 漏洞的根本原因
采用手动分析流程将漏洞映射到其根本原因。为使流程尽可能客观，180 个漏洞中的每个漏洞都分配给两名研究人员（一名来自行业，一名来自学术界）。研究人员独立检查分配的 CVE 的源代码和提交信息。尽管从理论上讲，一个 CVE 可能由多个因素导致，但为了本研究的目的，每个漏洞实例都映射到一个最可能的根本原因。做出这一决定是为了保持手动分类的一致性并减少歧义。我们最初遵循描述的根本原因分类法来分析汽车 SoC 软件（ASoCS）漏洞。随后，我们通过开放式编码技术更新了分类法，以定制根本原因列表。每位研究人员将 CVE 与其根本原因映射后，进行内部讨论以消除分歧，并确定统一的映射版本。
映射 ------ 软件架构模块
汽车 SoC 软件（ASoCS）架构模型已在步骤 1 中描述。我们尝试将每个漏洞映射到架构模型中的软件模块。为此，采用了四级映射方案，即每个漏洞映射到主软件模块，然后是层次结构中的三个子模块。例如，CVE-2024-33049 被映射为中央处理器（CP）→内核空间→无线局域网（WLAN）模块→无线局域网漫游和扫描管理模块。映射过程包括检查代码仓库中漏洞文件的位置，并进一步手动检查代码内容。这有助于理解其主要功能，从而确定它应归属的合适子模块。继续以 CVE-2024-33049 为例，我们发现相关文件为 umac/scan/dispatcher/src/wlan_scan_utils_api.c。下面，我们通过指导性问题解释如何将这个示例漏洞文件放置在特定的软件模块中：
该文件的用途是什么？wlan_scan_utils_api.c 文件控制 Wi-Fi 扫描、网络发现和连接管理。它还处理网络发现、切换和无缝漫游服务（802.11k、802.11v、802.11r）期间所需的接入点（AP）扫描。
为什么该文件属于中央处理器（CP）而不是独立的 Wi-Fi 模块？Wi-Fi 是操作系统网络栈的一部分，而非独立模块。此外，扫描需要与操作系统（如 Linux）网络服务直接交互。
为什么该文件属于内核空间而不是用户空间？用户空间组件可以请求扫描，但不能直接访问或控制无线局域网（WLAN）硬件。这主要由内核无线局域网（WLAN）驱动程序处理，该驱动程序执行实际的 Wi-Fi 扫描、管理连接并与无线局域网（WLAN）固件交互。
这个示例表明，我们追踪包含漏洞代码的文件，手动查看其细节，并利用这些信息在架构模型中找到最佳关联位置。
同样，这种映射由两名研究人员独立完成，通过讨论解决分歧，形成统一的映射结果。
映射 ------ 漏洞缓解时间
跟踪漏洞缓解时间在汽车 SoC 软件（ASoCS）安全分析中至关重要，因为补丁延迟可能导致安全关键型系统暴露于漏洞利用之下，随着时间的推移增加风险。了解这些延迟有助于优先开展强化工作，并改进对高影响组件的响应策略。因此，在本研究中，我们记录了所有 180 个漏洞代码的漏洞缓解时间，随后将其映射到不同的软件模块和通用缺陷枚举（CWE）。使用公式 1 计算缓解时间（MT）（以天为单位）：
其中，GCD=Git 提交日期（提交被合并或应用到公共仓库的时间戳，即公开可见的时间）；GAD=Git 提交创作日期（补丁提交的创作时间戳，即开发者最初编写的时间）；RD = 报告日期（漏洞在国家漏洞数据库（NVD）发布或通过官方安全公告披露的日期）。
缓解时间通常计算为 Git 提交日期（GCD）与报告日期（RD）之间的天数。在特殊情况下（如报告日期晚于提交日期），则假设漏洞是内部发现的，此时缓解时间计算为 Git 提交日期（GCD）与 Git 提交创作日期（GAD）之间的天数。如果 Git 提交创作日期（GAD）和 Git 提交日期（GCD）为同一天，则将缓解时间视为 1 天（以避免零值条目）。
受影响的芯片组和通用缺陷枚举（CWE）可直接从国家漏洞数据库（NVD）CVE 详情页面提供的超链接获取。
4、结果与分析
我们的最终结果包括 180 个汽车 SoC 软件（ASoCS）漏洞的列表，以及第 3 节中描述的所有映射。在本节中，我们通过呈现 CVE、通用缺陷枚举（CWE）、软件模块和漏洞缓解时间之间的不同关系，回答我们的研究问题。
RQ1：汽车 SoC 软件（ASoCS）漏洞的根本原因是什么？这些根本原因在多大程度上能够解释已识别的漏洞？
表 2 列出了 180 个 CVE 中识别出的 16 个根本原因中的前 10 个。
表 2、汽车 SoC 软件（ASoCS）漏洞的根本原因
研究结果表明，缺失大小 / 长度验证是最常见的根本原因，占 180 个 CVE 中的 72 个，其次是不当条件检查（25 个）和不当并发控制（20 个）。
图3、软件模块间根本原因的分布
在图 3 中，我们使用桑基图分析了每个根本原因在已识别软件模块中的影响。图 3 的主要观察结果如下：
· 无线局域网（WLAN）和音频子系统模块中分别有 31 个和 14 个 CVE 由缺失大小 / 长度验证导致（由粗流线表示）；
· 图形处理器（GPU）模块显示出最多样化的相关根本原因（11 个），其次是进程间通信（IPC）和无线局域网（WLAN）模块，分别有 9 个和 7 个相关根本原因（由多条流线表示）；
不当条件检查这一根本原因分布在最多的模块中（11 个），其次是缺失大小 / 长度验证和不当并发控制，分别分布在 9 个和 6 个软件模块中。
图4、根本原因与CWE的关联
我们还映射了这些根本原因与已识别的汽车 SoC 软件（ASoCS）漏洞的通用缺陷枚举（CWE）类别之间的关联。图 4 展示了一个网络图，描述了通用缺陷枚举（CWE）（紫色节点）与根本原因（多色节点）之间的关系。图 4 的主要观察结果如下：
· 缺失大小 / 长度验证这一根本原因导致了 22 个 CWE-129（数组索引的不当验证）和 12 个 CWE-120（未检查输入大小的缓冲区复制（"经典缓冲区溢出"））实例（由粗边表示）；
· 不当条件检查和缺失大小 / 长度验证分别与 11 个和 10 个不同的通用缺陷枚举（CWE）相关联（由节点相关联的边数表示）；
· CWE-416（释放后使用）可能由 12 个不同的根本原因导致，其次是 CWE-120（未检查输入大小的缓冲区复制（"经典缓冲区溢出"）），有 8 个根本原因。
RQ1 的研究结果揭示了汽车 SoC 软件（ASoCS）中频繁出现的根本原因及其与不同软件模块和通用缺陷枚举（CWE）类别的关联。这种双层映射不仅揭示了哪些架构组件最容易出现特定类型的缺陷，还帮助将这些问题置于标准化漏洞分类的背景下。此类见解对于指导特定模块的强化工作、为安全开发实践提供信息，以及使修复策略与汽车 SoC 软件（ASoCS）栈中的已知缺陷模式对齐至关重要。
RQ2：漏洞在汽车 SoC 软件（ASoCS）架构模型栈的不同架构组件 / 模块中如何分布？
我们的研究结果表明，内核空间、用户空间和安全执行环境分别占汽车 SoC 软件（ASoCS）总漏洞的 86.6%、11.9% 和 1.5%。图 5 进一步详细说明了漏洞在内核空间的分布情况。从树状图可以明显看出，无线局域网（WLAN）（42 个）、音频子系统（22 个）、进程间通信（IPC）（19 个）和图形处理器（GPU）（18 个）模块是导致漏洞总数最多的模块。每个这些模块都进一步展开，可以看到无线局域网漫游和扫描管理（16 个）、MLO 管理器（12 个）和 ALSA（12 个）子模块的漏洞数量最多。
图5、CVE在软件模块中的分布
图 6 通过热力图展示了通用缺陷枚举（CWE）在漏洞数量最多的模块中的分布情况。其中，红色单元格表示某个特定通用缺陷枚举（CWE）类型在该模块中出现的次数最多；颜色从浅色逐渐变为深蓝色时，通用缺陷枚举（CWE）的数量逐渐减少。热力图的主要观察结果如下：
· 图形处理器（GPU）模块分布有 9 种通用缺陷枚举（CWE），其次是无线局域网（WLAN）和音频子系统，各有 8 种通用缺陷枚举（CWE），进程间通信（IPC）有 7 种；
· 无线局域网（WLAN）模块以 CWE-126（缓冲区越读）为主（25 个实例）；音频子系统模块有 7 个 CWE-120（未检查输入大小的缓冲区复制（"经典缓冲区溢出"））实例；图形处理器（GPU）和进程间通信（IPC）模块分别有 9 个和 8 个 CWE-416（释放后使用）实例。
图6、CWE在软件模块中的分布
RQ2 的答案提供了漏洞和通用缺陷枚举（CWE）在汽车 SoC 软件（ASoCS）架构栈中的频率和分布情况。这些发现可以帮助系统架构师和开发人员优先开展安全审查、重构或隔离策略。此外，这种映射支持分层防御方法，使有针对性的缓解工作与 SoC 栈中组件的结构角色对齐。
RQ3：漏洞缓解时间在不同的通用缺陷枚举（CWE）类别和汽车 SoC 软件（ASoCS）模块之间有何差异？
结果显示，CWE-416（释放后使用）和 CWE-126（缓冲区越读）分别占总漏洞缓解时间的 25.4% 和 24.5%。另一方面，无线局域网（WLAN）和进程间通信（IPC）模块分别占总缓解时间的 26.4% 和 23.2%。
图7、顶部）CWE和底部）模块的漏洞缓解时间变化
我们进一步分析了一些频繁出现的通用缺陷枚举（CWE）的缓解时间（以天为单位）变化情况。图 7.a）以小提琴图的形式展示了这一结果。CWE-120 和 CWE-190 的缓解时间变化较小（所有 CVE 均在 1 至 3 个月内得到缓解）。对于 CWE-416，尽管大多数 CVE 在 1 至 3 个月内得到缓解，但有少数需要更长的时间（5 至 7 个月）。对于 CWE-126，大多数 CVE 在 1 至 4 个月内得到解决，除了 1 个需要 11 个月。最后，CWE-823 的曲线分布较广，表明该通用缺陷枚举（CWE）的不同实例具有不同的缓解时间（最短为 1 个月，最长接近 10 个月）。
我们还探讨了缓解时间在一些漏洞最多的软件模块中的变化情况。图 7.b）的小提琴图显示，音频子系统模块的变化最小，大多数 CVE 在 1 至 2 个月内得到缓解。变化次小的是图形处理器（GPU）模块，略有波动（大多数 CVE 在 3.5 个月内得到缓解，少数延长至 4.5 个月）。无线局域网（WLAN）和进程间通信（IPC）模块的变化较大，缓解时间范围从 1 天到大约 1 年不等。
在回答 RQ3 时，我们发现，分析通用缺陷枚举（CWE）和架构模块之间的缓解时间差异，可以为汽车 SoC 软件（ASoCS）栈的运行安全状况提供有价值的见解，这对于汽车等安全关键型 CPS 系统尤为重要。补丁延迟较短的模块通常反映出组件维护良好、开发人员参与积极、CI/CD 集成高效或依赖结构简单。相比之下，持续较长的缓解时间可能表明架构复杂、所有权不足或在维护工作流中的可见性低。映射这些延迟有助于识别高风险模块，这些模块的补丁延迟可能导致安全关键型系统长期暴露于漏洞风险之下。这些见解可以指导安全强化优先级、促进架构重构，并通过解决 CCAM 中安全响应较慢的架构领域，为更具弹性的软件生命周期管理做出贡献。
总结
研究发现，缺失大小 / 长度验证是汽车 SoC 软件（ASoCS）中最主要的根本原因。无线局域网（WLAN）模块占总漏洞的 37%（主要类别：CWE-126）。图形处理器（GPU）模块显示出最多样化的通用缺陷枚举（CWE）类别。CWE-416 的缓解时间最长。无线局域网（WLAN）和进程间通信（IPC）模块的缓解时间变化较大。
5、讨论
从 CPS 的角度来看，这些发现引发了重大担忧。考虑到汽车行业正迅速向完全集中化的 SoC 和软件定义的车辆架构迈进，在最坏情况下，单个软件模块的 CVE 可能被攻击者轻易利用，以获取整个系统的访问权限。例如，假设一个由黑客控制的路侧单元（RSU）或接入点向 SoC Wi-Fi 驱动程序（我们模型的无线局域网（WLAN）模块的一部分）发送恶意信标帧（MBF）。由于 wlan_mlo_t2lm.c 文件中存在现有的漏洞（CWE-126 类型，缓冲区越读），该模块将在没有任何验证的情况下接受恶意信标帧（MBF）。这可能导致各种安全问题，如因读取未初始化内存导致的数据泄露、Wi-Fi 栈崩溃导致的分布式拒绝服务（DDoS）、车与基础设施（V2I）交通信号通信失败、车与车（V2V）防撞警报失败、车队管理和空中下载（OTA）更新失败等。
尽管我们的架构并非直接基于 AUTOSAR 蓝图构建，但其与 AUTOSAR 自适应平台在结构和服务层上的相似性使我们能够推断潜在的集成和迁移用例。例如，对于采用 AUTOSAR（尤其是自适应平台）的组织，我们的发现提供了对基于 SoC 的系统中遇到的现实世界漏洞的实际视角。假设一个一级汽车供应商正在将其信息娱乐和互联电子控制单元（ECU）从专有实时操作系统（RTOS）过渡到 AUTOSAR 自适应平台。该电子控制单元（ECU）集成了基于骁龙的 SoC，并通过 Wi-Fi 支持车与基础设施（V2I）功能。在这种情况下，我们的发现可以帮助安全负责人评估构成最高安全风险的模块，以及应优先进行缓解或架构强化的领域。根据评估结果，该公司可以在第三方软件采购过程中做出不同的集成强化决策、有针对性的模糊测试和缓冲区边界检查，并坚持要求 Wi-Fi 驱动程序采用内存安全实现等。
6、有效性威胁
我们在考虑研究的有效性时，采用了沃林和斯塔龙提出的框架。
在构念有效性方面，主要风险是遗漏重要的汽车 SoC 软件（ASoCS）漏洞。我们的研究方法和对开源 SoC 软件的限制可能导致遗漏一些汽车 SoC 软件（ASoCS）最受欢迎组件（如高级驾驶辅助系统（ADAS）或数字驾驶舱）中的漏洞实例。构念有效性还可能受到实时模块与高端模块的纳入 / 排除的影响。
在结论有效性方面，我们认为主要风险在于手动映射过程。尽管我们考虑使用自动化工具（如大型语言模型（LLM）），但我们选择手动进行，以便能够验证结果或在需要时进行讨论。
缓解时间线的研究可能与模块的架构角色或集成深度相关，但我们也承认，开源项目动态（如贡献者活动和治理）可能会影响这些结果，这构成了内部有效性的潜在威胁。
外部有效性的一个关键限制是，汽车 SoC 软件（ASoCS）架构模型是从开源仓库手动推导的，可能无法代表商业 SoC 实现的所有变体。尽管我们将模型与 AUTOSAR 概念对齐，但我们承认缺乏正式验证（如专家访谈或行业确认的映射）。
7、结论与未来工作
随着时间的推移，汽车 SoC 软件架构正变得更加集中化和复杂。这种演进支持了诸如高效空中下载（OTA）更新、通过云环境提供更多客户服务、无缝数据共享和优化功耗等优势，但同时也放大了紧密集成的 CPS 平台固有的安全风险。本研究深入探讨了汽车 SoC 软件（ASoCS）架构栈中一些最易受攻击的区域。通过将 180 个现实世界的漏洞映射到软件模块、通用缺陷枚举（CWE）类别、根本原因、芯片组和缓解延迟，我们识别出了关键趋势，例如漏洞集中在 Wi-Fi 模块以及频繁出现的缺失大小 / 长度验证缺陷。
我们的模型源自公开可用的仓库，并与 AUTOSAR 原则对齐，有助于识别在传统安全审计中可能被忽视的易受攻击组件。采用 AUTOSAR 的安全测试人员和架构师可以利用我们的根本原因映射和延迟模式，优先处理高风险模块、指导有针对性的强化，并在平台采用过程中验证集成决策。未来的工作包括与 AUTOSAR 从业者和领域专家一起验证架构模型，以及扩展攻击路径分析以支持更广泛的 CPS 领域。