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