摘要

協同、互聯與自動化出行（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 收集與篩選

該過程包括以下步驟：

1. 下載 CVE 列表：從國家漏洞數據庫（NVD）下載 2018 年至 2025 年 2 月的年度 CVE 列表（JSON 格式），并導入數據庫。詳細步驟可參見我們之前的研究。

2. 汽車 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 個漏洞。

1. 汽車 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 領域。

（添加微信號NewCarRen咨詢）