摘要

協(xié)同、互聯(lián)與自動化出行（CCAM）是復(fù)雜的信息物理系統(tǒng)（CPS），在安全關(guān)鍵型環(huán)境中整合了計(jì)算、通信和控制功能。其核心是片上系統(tǒng)（SoC）平臺，該平臺將處理單元、通信接口、人工智能加速器和安全模塊集成于單芯片之中。汽車領(lǐng)域制定了 AUTOSAR（汽車開放系統(tǒng)架構(gòu)）標(biāo)準(zhǔn)，旨在更好地管理這種復(fù)雜性，該標(biāo)準(zhǔn)定義了分層軟件結(jié)構(gòu)和接口，并促進(jìn)軟硬件組件的復(fù)用。然而，在實(shí)際應(yīng)用中，這種集成式 SoC 軟件架構(gòu)仍面臨安全挑戰(zhàn)，尤其是在實(shí)時、安全關(guān)鍵型環(huán)境中。近期報(bào)告顯示，與 SoC 相關(guān)的漏洞數(shù)量激增，但目前缺乏對這些漏洞在符合 AUTOSAR 標(biāo)準(zhǔn)的架構(gòu)中的根本原因及影響的系統(tǒng)性分析。本研究通過分析 180 個公開報(bào)告的汽車 SoC 漏洞，填補(bǔ)了這一空白。這些漏洞被映射到一個具有代表性的 SoC 軟件架構(gòu)模型，該模型遵循 AUTOSAR 的分層抽象和面向服務(wù)原則。研究識別出 16 個漏洞根本原因和 56 個受影響的軟件模塊，并分析了不同通用缺陷枚舉（CWE）類別和架構(gòu)層的漏洞緩解延遲。研究揭示了主要的漏洞模式和補(bǔ)丁延遲較長的關(guān)鍵模塊，并為汽車 CPS 平臺的安全防護(hù)提供了切實(shí)可行的見解，包括針對 SoC 軟件架構(gòu)的改進(jìn)檢測、優(yōu)先級排序和定位策略指南。

1、引言

安全的軟件架構(gòu)在現(xiàn)代協(xié)同、互聯(lián)與自動化出行（CCAM）中起著至關(guān)重要的作用。隨著功能需求的不斷增長 —— 從性能優(yōu)化、信息娛樂到自動駕駛，汽車軟件系統(tǒng)需要持續(xù)演進(jìn)。汽車片上系統(tǒng)（SoC）一直是 CCAM 生態(tài)系統(tǒng)的核心組成部分，將多種功能集成在單芯片上。歷史上，微控制器主要處理發(fā)動機(jī)控制和制動等獨(dú)立任務(wù)。在過去二十年中，英偉達(dá)、高通、英特爾等廠商的 SoC 已從提供常規(guī)信息娛樂和安全功能，轉(zhuǎn)變?yōu)楦咝阅苋斯ぶ悄茯?qū)動的處理器，支持自動駕駛、高級信息娛樂和其他互聯(lián)功能。這一轉(zhuǎn)變帶來了顯著的架構(gòu)復(fù)雜性。軟件模塊數(shù)量的增加、模塊間的分層交互以及 SoC 內(nèi)部功能集成的不斷深化，為系統(tǒng)級分析和安全防護(hù)帶來了新的挑戰(zhàn)。

由于汽車軟件采用了開放的生態(tài)系統(tǒng)，同時包含汽車專用模塊和通用模塊，汽車 CPS 的安全性已成為一個緊迫的問題。近期涉及數(shù)據(jù)泄露、遠(yuǎn)程控制漏洞利用和服務(wù)中斷的事件凸顯了普遍存在的風(fēng)險。已有研究表明，過去八年報(bào)告的汽車軟件漏洞中，近 67% 與基于 SoC 的系統(tǒng)直接相關(guān)。考慮到現(xiàn)代 SoC 的集成密度，單一功能中的漏洞可能會危及整個系統(tǒng)棧。

盡管 AUTOSAR 提供了標(biāo)準(zhǔn)化的參考架構(gòu)，但其規(guī)范（尤其是在經(jīng)典平臺和自適應(yīng)平臺中）具有抽象性和平臺無關(guān)性，并非為現(xiàn)實(shí)世界漏洞的直接映射而設(shè)計(jì)。相比之下，漏洞通常在代碼層面被報(bào)告，與特定的驅(qū)動程序、固件或系統(tǒng)服務(wù)軟件相關(guān)聯(lián)。因此，我們首先通過研究開源 SoC 軟件倉庫，推導(dǎo)了一個中間架構(gòu)模型，以了解實(shí)際模塊（如無線局域網(wǎng)驅(qū)動程序、進(jìn)程間通信服務(wù)、硬件抽象層等）的結(jié)構(gòu)和部署方式。隨后，我們將該架構(gòu)與 AUTOSAR 概念對齊，以保持兼容性。我們從國家漏洞數(shù)據(jù)庫（NVD）中選取了一組經(jīng)過篩選的公開報(bào)告的汽車 SoC 軟件（ASoCS）漏洞，并將其映射到該代表性架構(gòu)模型。盡管開源汽車倉庫的可用性有限，但本研究通過以下一系列重點(diǎn)研究問題（RQ）揭示了關(guān)鍵趨勢和模式：

· RQ1：汽車 SoC 軟件（ASoCS）漏洞的根本原因是什么？這些根本原因在多大程度上能夠解釋已識別的漏洞？

· RQ2：漏洞在汽車 SoC 軟件（ASoCS）架構(gòu)模型棧的不同架構(gòu)組件 / 模塊中如何分布？

· RQ3：漏洞緩解時間在不同的通用缺陷枚舉（CWE）類別和汽車 SoC 軟件（ASoCS）模塊之間有何差異？

本研究在汽車 SoC 軟件（ASoCS）架構(gòu)及其漏洞方面做出了以下貢獻(xiàn)：1）采用基于文獻(xiàn)、符合 AUTOSAR 標(biāo)準(zhǔn)的汽車 SoC 軟件（ASoCS）架構(gòu)模型，研究架構(gòu)層面臨的現(xiàn)實(shí)世界漏洞風(fēng)險；2）通過回答上述研究問題，呈現(xiàn)關(guān)于汽車 SoC 軟件（ASoCS）漏洞的多項(xiàng)發(fā)現(xiàn)；3）討論 CPS 和 AUTOSAR 特定用例，以反映研究結(jié)果的實(shí)際意義。特別是，我們的發(fā)現(xiàn)能夠幫助軟件架構(gòu)師和安全測試負(fù)責(zé)人更快地識別高風(fēng)險模塊、優(yōu)先開展安全設(shè)計(jì)工作，并改進(jìn)漏洞分析。此外，我們的組件級漏洞映射有助于在組件選擇和采購過程中做出更明智的決策，從而提升基于 SoC 的車輛平臺的整體軟件質(zhì)量和安全態(tài)勢。

2、相關(guān)工作

本節(jié)重點(diǎn)介紹分析汽車 CPS 軟件及其安全性的相關(guān)研究，其中部分為分析類研究，部分提出了實(shí)際解決方案。

加西亞等人開展了一項(xiàng)探索性研究，分析了兩個最受歡迎的自動駕駛開源軟件項(xiàng)目（Autoware 和百度 Apollo）中的汽車軟件漏洞。他們研究了 499 個漏洞，報(bào)告了其根本原因，并識別了受影響的軟件組件。

馬什庫爾等人提出了一種面向安全關(guān)鍵型軟件系統(tǒng)的模型驅(qū)動工程系統(tǒng)映射方法。作者從汽車領(lǐng)域選取了 29 篇研究論文（數(shù)量最多），其中 11 篇屬于架構(gòu)和設(shè)計(jì)階段。通過對這些論文的審查，我們發(fā)現(xiàn)很少有研究在其分析中采用參考架構(gòu)。其中一篇論文采用 Evita 汽車參考架構(gòu)研究車載網(wǎng)絡(luò)，但未發(fā)現(xiàn)任何涉及汽車 SoC 軟件架構(gòu)映射的論文。

巴蘇和斯塔龍對 2018-2024 年期間的汽車軟件漏洞進(jìn)行了實(shí)證研究，主要關(guān)注 1663 個已識別漏洞的通用漏洞評分系統(tǒng)（CVSS）得分、攻擊向量和通用缺陷枚舉（CWE）類別的分布情況。

貝拉等人提出了 CINNAMON，這是一個基于 AUTOSAR 經(jīng)典平臺的基礎(chǔ)軟件模塊（BSW），通過在標(biāo)準(zhǔn)安全車載通信（SecOC）模塊現(xiàn)有的完整性和認(rèn)證保障基礎(chǔ)上增加機(jī)密性，增強(qiáng)了車載通信安全性。與不提供加密功能的 SecOC 不同，CINNAMON 集成了加密保護(hù)、新鮮度驗(yàn)證和可配置安全配置文件。作者在基于 STM32 的電子控制單元（ECU）原型上實(shí)現(xiàn)并評估了該模塊，且僅產(chǎn)生了最小的性能開銷。他們的工作通過展示如何將安全模塊設(shè)計(jì)嵌入到 AUTOSAR 的通信棧中，補(bǔ)充了我們的漏洞中心型分析。

盡管已有研究在汽車軟件安全方面提供了寶貴的見解（如漏洞分類、CVE 分析或模型驅(qū)動的安全技術(shù)），但大多數(shù)研究要么聚焦于單個倉庫，要么提供高層級分析，缺乏架構(gòu)層面的支撐。我們的映射方法將漏洞與符合 AUTOSAR 標(biāo)準(zhǔn)的架構(gòu)中的功能塊對齊，基于現(xiàn)實(shí)世界的軟件結(jié)構(gòu)提供了實(shí)用、可操作的見解。通過在具有代表性的 SoC 軟件棧中定義明確的層和模塊內(nèi)組織和分析漏洞，本研究有助于實(shí)現(xiàn)有針對性的漏洞定位和更深入的根本原因識別。這種架構(gòu)視角能夠支持安全測試人員、軟件架構(gòu)師和采購團(tuán)隊(duì)等行業(yè)從業(yè)者精準(zhǔn)定位高風(fēng)險模塊、預(yù)測緩解延遲，并在組件選擇和軟件質(zhì)量保證方面做出明智決策。

3、方法論：架構(gòu)建模、漏洞數(shù)據(jù)收集與映射

本研究遵循的方法分為三個部分。首先，如步驟 1 所述，推導(dǎo)汽車 SoC 軟件（ASoCS）架構(gòu)模型；其次，在步驟 2 中收集汽車 SoC 軟件（ASoCS）漏洞（即通用漏洞披露（CVE）[5]），并識別其中包含開源代碼的漏洞；最后，在步驟 3 中介紹漏洞映射方法，包括：i）與根本原因的映射；ii）與架構(gòu)模塊的映射；iii）與緩解時間的映射。

所有手動分析或決策均由兩名研究人員（一名來自行業(yè)，一名來自學(xué)術(shù)界）共同完成。我們使用科恩卡帕系數(shù)（Cohen’s Kappa coefficient）衡量兩名研究人員之間的一致性，得分達(dá)到 0.81，表明我們的手動流程具有高度一致性。

3.1 步驟 1：汽車 SoC 軟件架構(gòu)模型

本研究采用基于廣泛使用的汽車和嵌入式平臺及標(biāo)準(zhǔn)的歸納式、文獻(xiàn)驅(qū)動方法，推導(dǎo)了具有代表性的汽車 SoC 軟件（ASoCS）架構(gòu)模型。該模型是通過對開源倉庫（包括安卓開源項(xiàng)目（AOSP）、代碼極光論壇（CAF）和高通板級支持包（BSP）層）的詳細(xì)調(diào)查構(gòu)建的。研究這些倉庫是為了了解 SoC 組件的功能分解和文件組織。通過分析目錄結(jié)構(gòu)、依賴圖和接口定義，提取重復(fù)出現(xiàn)的架構(gòu)模式和軟件邊界。為確保與行業(yè)實(shí)踐的結(jié)構(gòu)一致性，我們將提取的架構(gòu)層與 AUTOSAR 對齊，AUTOSAR 為現(xiàn)代汽車平臺定義了面向服務(wù)的分層架構(gòu)模型。圖 1（完整軟件架構(gòu)）和圖 2（中央處理器模塊的內(nèi)核空間和用戶空間）展示了我們架構(gòu)模型的簡明視圖。主要推導(dǎo)原則如下：

中央處理器（CP）的分層分解

中央處理器（CP）分為用戶空間、內(nèi)核空間和安全執(zhí)行環(huán)境（SEE），以反映嵌入式汽車環(huán)境中的安卓 / Linux 系統(tǒng)層。此外，我們模型中用戶空間和內(nèi)核空間的分離與 AUTOSAR 的分層抽象一致，其中應(yīng)用級功能（自適應(yīng)應(yīng)用程序）與底層執(zhí)行服務(wù)（如基礎(chǔ)層中提供的基于 POSIX 的操作系統(tǒng)和執(zhí)行管理模塊）解耦。

圖1、汽車SoC軟件架構(gòu)模型

圖2、ASoCS，中央處理器：內(nèi)核和用戶空間

基于功能的子系統(tǒng)隔離

數(shù)字信號、通信、圖形處理等模塊根據(jù)驍龍汽車（Snapdragon Automotive）和英偉達(dá) DRIVE 等平臺進(jìn)行分離。每個模塊都有固件、驅(qū)動程序和特定功能的應(yīng)用程序接口（API），與中央處理器（CP）交互但半獨(dú)立運(yùn)行。其中一些模塊（如通信、輸入輸出內(nèi)存管理單元（IOMMU）、進(jìn)程間通信（IPC）等）對應(yīng)于 AUTOSAR 平臺中定義的基礎(chǔ)軟件模塊。然而，為了捕捉現(xiàn)實(shí)世界中的 SoC 集成模式，我們的模型還包括了神經(jīng)處理器和圖形處理器等額外模塊，這些模塊在 AUTOSAR 中未被明確指定或抽象。這種偏差是合理的，因?yàn)槿斯ぶ悄芗铀倨骱突诟呒増D形處理器（GPU）的信息娛樂系統(tǒng)在汽車 SoC 中的集成日益增多。這種混合方法使我們能夠在保持與 AUTOSAR 面向服務(wù)原則總體對齊的同時，適應(yīng)商業(yè) SoC 平臺中存在的架構(gòu)多樣性。

安全域識別

我們的模型中明確保留了安全執(zhí)行環(huán)境（SEE）等組件，以反映高通和基于 ARM 的 SoC 中常見的可信執(zhí)行環(huán)境（TEE）實(shí)現(xiàn)。盡管 AUTOSAR 提到了安全服務(wù)，但通常將可信執(zhí)行環(huán)境（TEE）視為硬件抽象或中間件的一部分，沒有進(jìn)行模塊化表示。由于這些組件與漏洞定位和威脅建模直接相關(guān)，我們選擇將其作為獨(dú)立模塊納入模型。

抽象供應(yīng)商特定標(biāo)簽

我們特別注意抽象供應(yīng)商特定標(biāo)簽（如 “高級駕駛輔助系統(tǒng)（ADAS）”），同時保留功能類別，如音頻處理、處理器間通信和電源管理等服務(wù)。

盡管在呈現(xiàn)結(jié)果時會討論其中一些模塊和子模塊的功能，但每個模塊的詳細(xì)描述超出了本文的范圍。表 1 展示了汽車 SoC 架構(gòu)與 AUTOSAR 概念的對齊情況。

表 1、推導(dǎo)的 SoC 架構(gòu)與 AUTOSAR 概念的功能對齊

如圖 2 所示，中央處理器（CP）運(yùn)行通用代碼，控制任務(wù)的發(fā)送，并管理自身與其他專用處理器（數(shù)字信號模塊（DSM）、圖形處理模塊（GPM）等）之間的通信。例如，考慮使用上述模型檢測附近車輛減速并向駕駛員發(fā)出警報(bào)的用例場景，步驟如下：i）攝像頭傳感器捕獲視頻流，并將數(shù)據(jù)發(fā)送到中央處理器（CP）的圖像信號處理器（ISP）子模塊（內(nèi)核空間）；ii）在檢查數(shù)據(jù)非空、所有像素完全飽和等各種因素后，圖像信號處理器（ISP）驅(qū)動程序?qū)?shù)據(jù)發(fā)送到數(shù)字信號模塊（DSM）進(jìn)行實(shí)時目標(biāo)檢測；iii）數(shù)字信號模塊（DSM）使用其人工智能模型進(jìn)行實(shí)時目標(biāo)檢測（嘗試確定另一輛車是否確實(shí)在減速）；iv）一旦數(shù)字信號模塊（DSM）檢測到車輛減速，便將該信息傳達(dá)給圖形處理模塊（GPM）的中央處理器（CP）內(nèi)核驅(qū)動程序，該驅(qū)動程序進(jìn)而將消息發(fā)送到圖形處理模塊（GPM）固件；v）圖形處理模塊（GPM）使用其驅(qū)動程序在信息娛樂系統(tǒng)上呈現(xiàn)警告信息。

3.2 步驟 2：汽車 SoC 軟件 CVE 收集與篩選

該過程包括以下步驟：

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

2. 汽車 SoC 軟件（ASoCS）CVE 篩選 —— 第一階段：基于 CVE 描述文本和通用平臺枚舉（CPE）執(zhí)行搜索查詢，以篩選汽車 SoC 軟件（ASoCS）漏洞。關(guān)鍵詞包括 “汽車（Auto）”“片上系統(tǒng)（SoC）”“高通（Qualcomm）”“汽車行業(yè)（Automotive）”“德州儀器（Texas）”“恩智浦（NXP）”“瑞薩（Renesas）”“英偉達(dá)（NVIDIA）”“驍龍（Snapdragon）”，用于篩選 CVE 描述文本；芯片組名稱（如 QCA6574AU、QCA6595AU、QCA6584AU 等）用于篩選通用平臺枚舉（CPE）。

這種雙重搜索查詢非常有效，因?yàn)橛袝r CVE 描述可能不包含表明其與汽車 SoC 軟件（ASoCS）相關(guān)聯(lián)的直接關(guān)鍵詞，而在所有此類情況下，通用平臺枚舉（CPE）描述中的芯片組名稱可以提供相關(guān)結(jié)果。此外，可能存在通用平臺枚舉（CPE）未注冊所有受影響的有效芯片組的情況，此時 CVE 描述可以起到補(bǔ)充作用。本步驟最終篩選出 1113 個漏洞。

1. 汽車 SoC 軟件（ASoCS）CVE 篩選 —— 第二階段：獲得漏洞列表后，我們進(jìn)一步檢查這些漏洞是否有可用的開源倉庫。CVE 詳情頁面中的一些超鏈接提供了訪問漏洞代碼及其補(bǔ)丁的途徑。此外，一些較舊的代碼倉庫已從一個主機(jī)遷移到另一個主機(jī)，導(dǎo)致倉庫鏈接無法訪問。最終列表包含 180 個汽車 SoC 軟件（ASoCS）漏洞實(shí)例。

3.3 步驟 3：漏洞映射

映射 —— 漏洞的根本原因

采用手動分析流程將漏洞映射到其根本原因。為使流程盡可能客觀，180 個漏洞中的每個漏洞都分配給兩名研究人員（一名來自行業(yè)，一名來自學(xué)術(shù)界）。研究人員獨(dú)立檢查分配的 CVE 的源代碼和提交信息。盡管從理論上講，一個 CVE 可能由多個因素導(dǎo)致，但為了本研究的目的，每個漏洞實(shí)例都映射到一個最可能的根本原因。做出這一決定是為了保持手動分類的一致性并減少歧義。我們最初遵循描述的根本原因分類法來分析汽車 SoC 軟件（ASoCS）漏洞。隨后，我們通過開放式編碼技術(shù)更新了分類法，以定制根本原因列表。每位研究人員將 CVE 與其根本原因映射后，進(jìn)行內(nèi)部討論以消除分歧，并確定統(tǒng)一的映射版本。

映射 —— 軟件架構(gòu)模塊

汽車 SoC 軟件（ASoCS）架構(gòu)模型已在步驟 1 中描述。我們嘗試將每個漏洞映射到架構(gòu)模型中的軟件模塊。為此，采用了四級映射方案，即每個漏洞映射到主軟件模塊，然后是層次結(jié)構(gòu)中的三個子模塊。例如，CVE-2024-33049 被映射為中央處理器（CP）→內(nèi)核空間→無線局域網(wǎng)（WLAN）模塊→無線局域網(wǎng)漫游和掃描管理模塊。映射過程包括檢查代碼倉庫中漏洞文件的位置，并進(jìn)一步手動檢查代碼內(nèi)容。這有助于理解其主要功能，從而確定它應(yīng)歸屬的合適子模塊。繼續(xù)以 CVE-2024-33049 為例，我們發(fā)現(xiàn)相關(guān)文件為 umac/scan/dispatcher/src/wlan_scan_utils_api.c。下面，我們通過指導(dǎo)性問題解釋如何將這個示例漏洞文件放置在特定的軟件模塊中：

該文件的用途是什么？wlan_scan_utils_api.c 文件控制 Wi-Fi 掃描、網(wǎng)絡(luò)發(fā)現(xiàn)和連接管理。它還處理網(wǎng)絡(luò)發(fā)現(xiàn)、切換和無縫漫游服務(wù)（802.11k、802.11v、802.11r）期間所需的接入點(diǎn)（AP）掃描。

為什么該文件屬于中央處理器（CP）而不是獨(dú)立的 Wi-Fi 模塊？Wi-Fi 是操作系統(tǒng)網(wǎng)絡(luò)棧的一部分，而非獨(dú)立模塊。此外，掃描需要與操作系統(tǒng)（如 Linux）網(wǎng)絡(luò)服務(wù)直接交互。

為什么該文件屬于內(nèi)核空間而不是用戶空間？用戶空間組件可以請求掃描，但不能直接訪問或控制無線局域網(wǎng)（WLAN）硬件。這主要由內(nèi)核無線局域網(wǎng)（WLAN）驅(qū)動程序處理，該驅(qū)動程序執(zhí)行實(shí)際的 Wi-Fi 掃描、管理連接并與無線局域網(wǎng)（WLAN）固件交互。

這個示例表明，我們追蹤包含漏洞代碼的文件，手動查看其細(xì)節(jié)，并利用這些信息在架構(gòu)模型中找到最佳關(guān)聯(lián)位置。

同樣，這種映射由兩名研究人員獨(dú)立完成，通過討論解決分歧，形成統(tǒng)一的映射結(jié)果。

映射 —— 漏洞緩解時間

跟蹤漏洞緩解時間在汽車 SoC 軟件（ASoCS）安全分析中至關(guān)重要，因?yàn)檠a(bǔ)丁延遲可能導(dǎo)致安全關(guān)鍵型系統(tǒng)暴露于漏洞利用之下，隨著時間的推移增加風(fēng)險。了解這些延遲有助于優(yōu)先開展強(qiáng)化工作，并改進(jìn)對高影響組件的響應(yīng)策略。因此，在本研究中，我們記錄了所有 180 個漏洞代碼的漏洞緩解時間，隨后將其映射到不同的軟件模塊和通用缺陷枚舉（CWE）。使用公式 1 計(jì)算緩解時間（MT）（以天為單位）：

其中，GCD=Git 提交日期（提交被合并或應(yīng)用到公共倉庫的時間戳，即公開可見的時間）；GAD=Git 提交創(chuàng)作日期（補(bǔ)丁提交的創(chuàng)作時間戳，即開發(fā)者最初編寫的時間）；RD = 報(bào)告日期（漏洞在國家漏洞數(shù)據(jù)庫（NVD）發(fā)布或通過官方安全公告披露的日期）。

緩解時間通常計(jì)算為 Git 提交日期（GCD）與報(bào)告日期（RD）之間的天數(shù)。在特殊情況下（如報(bào)告日期晚于提交日期），則假設(shè)漏洞是內(nèi)部發(fā)現(xiàn)的，此時緩解時間計(jì)算為 Git 提交日期（GCD）與 Git 提交創(chuàng)作日期（GAD）之間的天數(shù)。如果 Git 提交創(chuàng)作日期（GAD）和 Git 提交日期（GCD）為同一天，則將緩解時間視為 1 天（以避免零值條目）。

受影響的芯片組和通用缺陷枚舉（CWE）可直接從國家漏洞數(shù)據(jù)庫（NVD）CVE 詳情頁面提供的超鏈接獲取。

4、結(jié)果與分析

我們的最終結(jié)果包括 180 個汽車 SoC 軟件（ASoCS）漏洞的列表，以及第 3 節(jié)中描述的所有映射。在本節(jié)中，我們通過呈現(xiàn) CVE、通用缺陷枚舉（CWE）、軟件模塊和漏洞緩解時間之間的不同關(guān)系，回答我們的研究問題。

RQ1：汽車 SoC 軟件（ASoCS）漏洞的根本原因是什么？這些根本原因在多大程度上能夠解釋已識別的漏洞？

表 2 列出了 180 個 CVE 中識別出的 16 個根本原因中的前 10 個。

表 2、汽車 SoC 軟件（ASoCS）漏洞的根本原因

研究結(jié)果表明，缺失大小 / 長度驗(yàn)證是最常見的根本原因，占 180 個 CVE 中的 72 個，其次是不當(dāng)條件檢查（25 個）和不當(dāng)并發(fā)控制（20 個）。

圖3、軟件模塊間根本原因的分布

在圖 3 中，我們使用桑基圖分析了每個根本原因在已識別軟件模塊中的影響。圖 3 的主要觀察結(jié)果如下：

· 無線局域網(wǎng)（WLAN）和音頻子系統(tǒng)模塊中分別有 31 個和 14 個 CVE 由缺失大小 / 長度驗(yàn)證導(dǎo)致（由粗流線表示）；

· 圖形處理器（GPU）模塊顯示出最多樣化的相關(guān)根本原因（11 個），其次是進(jìn)程間通信（IPC）和無線局域網(wǎng)（WLAN）模塊，分別有 9 個和 7 個相關(guān)根本原因（由多條流線表示）；

不當(dāng)條件檢查這一根本原因分布在最多的模塊中（11 個），其次是缺失大小 / 長度驗(yàn)證和不當(dāng)并發(fā)控制，分別分布在 9 個和 6 個軟件模塊中。

圖4、根本原因與CWE的關(guān)聯(lián)

我們還映射了這些根本原因與已識別的汽車 SoC 軟件（ASoCS）漏洞的通用缺陷枚舉（CWE）類別之間的關(guān)聯(lián)。圖 4 展示了一個網(wǎng)絡(luò)圖，描述了通用缺陷枚舉（CWE）（紫色節(jié)點(diǎn)）與根本原因（多色節(jié)點(diǎn)）之間的關(guān)系。圖 4 的主要觀察結(jié)果如下：

· 缺失大小 / 長度驗(yàn)證這一根本原因?qū)е铝?22 個 CWE-129（數(shù)組索引的不當(dāng)驗(yàn)證）和 12 個 CWE-120（未檢查輸入大小的緩沖區(qū)復(fù)制（“經(jīng)典緩沖區(qū)溢出”））實(shí)例（由粗邊表示）；

· 不當(dāng)條件檢查和缺失大小 / 長度驗(yàn)證分別與 11 個和 10 個不同的通用缺陷枚舉（CWE）相關(guān)聯(lián)（由節(jié)點(diǎn)相關(guān)聯(lián)的邊數(shù)表示）；

· CWE-416（釋放后使用）可能由 12 個不同的根本原因?qū)е拢浯问?CWE-120（未檢查輸入大小的緩沖區(qū)復(fù)制（“經(jīng)典緩沖區(qū)溢出”）），有 8 個根本原因。

RQ1 的研究結(jié)果揭示了汽車 SoC 軟件（ASoCS）中頻繁出現(xiàn)的根本原因及其與不同軟件模塊和通用缺陷枚舉（CWE）類別的關(guān)聯(lián)。這種雙層映射不僅揭示了哪些架構(gòu)組件最容易出現(xiàn)特定類型的缺陷，還幫助將這些問題置于標(biāo)準(zhǔn)化漏洞分類的背景下。此類見解對于指導(dǎo)特定模塊的強(qiáng)化工作、為安全開發(fā)實(shí)踐提供信息，以及使修復(fù)策略與汽車 SoC 軟件（ASoCS）棧中的已知缺陷模式對齊至關(guān)重要。

RQ2：漏洞在汽車 SoC 軟件（ASoCS）架構(gòu)模型棧的不同架構(gòu)組件 / 模塊中如何分布？

我們的研究結(jié)果表明，內(nèi)核空間、用戶空間和安全執(zhí)行環(huán)境分別占汽車 SoC 軟件（ASoCS）總漏洞的 86.6%、11.9% 和 1.5%。圖 5 進(jìn)一步詳細(xì)說明了漏洞在內(nèi)核空間的分布情況。從樹狀圖可以明顯看出，無線局域網(wǎng)（WLAN）（42 個）、音頻子系統(tǒng)（22 個）、進(jìn)程間通信（IPC）（19 個）和圖形處理器（GPU）（18 個）模塊是導(dǎo)致漏洞總數(shù)最多的模塊。每個這些模塊都進(jìn)一步展開，可以看到無線局域網(wǎng)漫游和掃描管理（16 個）、MLO 管理器（12 個）和 ALSA（12 個）子模塊的漏洞數(shù)量最多。

圖5、CVE在軟件模塊中的分布

圖 6 通過熱力圖展示了通用缺陷枚舉（CWE）在漏洞數(shù)量最多的模塊中的分布情況。其中，紅色單元格表示某個特定通用缺陷枚舉（CWE）類型在該模塊中出現(xiàn)的次數(shù)最多；顏色從淺色逐漸變?yōu)樯钏{(lán)色時，通用缺陷枚舉（CWE）的數(shù)量逐漸減少。熱力圖的主要觀察結(jié)果如下：

· 圖形處理器（GPU）模塊分布有 9 種通用缺陷枚舉（CWE），其次是無線局域網(wǎng)（WLAN）和音頻子系統(tǒng)，各有 8 種通用缺陷枚舉（CWE），進(jìn)程間通信（IPC）有 7 種；

· 無線局域網(wǎng)（WLAN）模塊以 CWE-126（緩沖區(qū)越讀）為主（25 個實(shí)例）；音頻子系統(tǒng)模塊有 7 個 CWE-120（未檢查輸入大小的緩沖區(qū)復(fù)制（“經(jīng)典緩沖區(qū)溢出”））實(shí)例；圖形處理器（GPU）和進(jìn)程間通信（IPC）模塊分別有 9 個和 8 個 CWE-416（釋放后使用）實(shí)例。

圖6、CWE在軟件模塊中的分布

RQ2 的答案提供了漏洞和通用缺陷枚舉（CWE）在汽車 SoC 軟件（ASoCS）架構(gòu)棧中的頻率和分布情況。這些發(fā)現(xiàn)可以幫助系統(tǒng)架構(gòu)師和開發(fā)人員優(yōu)先開展安全審查、重構(gòu)或隔離策略。此外，這種映射支持分層防御方法，使有針對性的緩解工作與 SoC 棧中組件的結(jié)構(gòu)角色對齊。

RQ3：漏洞緩解時間在不同的通用缺陷枚舉（CWE）類別和汽車 SoC 軟件（ASoCS）模塊之間有何差異？

結(jié)果顯示，CWE-416（釋放后使用）和 CWE-126（緩沖區(qū)越讀）分別占總漏洞緩解時間的 25.4% 和 24.5%。另一方面，無線局域網(wǎng)（WLAN）和進(jìn)程間通信（IPC）模塊分別占總緩解時間的 26.4% 和 23.2%。

圖7、頂部）CWE和底部）模塊的漏洞緩解時間變化

我們進(jìn)一步分析了一些頻繁出現(xiàn)的通用缺陷枚舉（CWE）的緩解時間（以天為單位）變化情況。圖 7.a）以小提琴圖的形式展示了這一結(jié)果。CWE-120 和 CWE-190 的緩解時間變化較小（所有 CVE 均在 1 至 3 個月內(nèi)得到緩解）。對于 CWE-416，盡管大多數(shù) CVE 在 1 至 3 個月內(nèi)得到緩解，但有少數(shù)需要更長的時間（5 至 7 個月）。對于 CWE-126，大多數(shù) CVE 在 1 至 4 個月內(nèi)得到解決，除了 1 個需要 11 個月。最后，CWE-823 的曲線分布較廣，表明該通用缺陷枚舉（CWE）的不同實(shí)例具有不同的緩解時間（最短為 1 個月，最長接近 10 個月）。

我們還探討了緩解時間在一些漏洞最多的軟件模塊中的變化情況。圖 7.b）的小提琴圖顯示，音頻子系統(tǒng)模塊的變化最小，大多數(shù) CVE 在 1 至 2 個月內(nèi)得到緩解。變化次小的是圖形處理器（GPU）模塊，略有波動（大多數(shù) CVE 在 3.5 個月內(nèi)得到緩解，少數(shù)延長至 4.5 個月）。無線局域網(wǎng)（WLAN）和進(jìn)程間通信（IPC）模塊的變化較大，緩解時間范圍從 1 天到大約 1 年不等。

在回答 RQ3 時，我們發(fā)現(xiàn)，分析通用缺陷枚舉（CWE）和架構(gòu)模塊之間的緩解時間差異，可以為汽車 SoC 軟件（ASoCS）棧的運(yùn)行安全狀況提供有價值的見解，這對于汽車等安全關(guān)鍵型 CPS 系統(tǒng)尤為重要。補(bǔ)丁延遲較短的模塊通常反映出組件維護(hù)良好、開發(fā)人員參與積極、CI/CD 集成高效或依賴結(jié)構(gòu)簡單。相比之下，持續(xù)較長的緩解時間可能表明架構(gòu)復(fù)雜、所有權(quán)不足或在維護(hù)工作流中的可見性低。映射這些延遲有助于識別高風(fēng)險模塊，這些模塊的補(bǔ)丁延遲可能導(dǎo)致安全關(guān)鍵型系統(tǒng)長期暴露于漏洞風(fēng)險之下。這些見解可以指導(dǎo)安全強(qiáng)化優(yōu)先級、促進(jìn)架構(gòu)重構(gòu)，并通過解決 CCAM 中安全響應(yīng)較慢的架構(gòu)領(lǐng)域，為更具彈性的軟件生命周期管理做出貢獻(xiàn)。

總結(jié)

研究發(fā)現(xiàn)，缺失大小 / 長度驗(yàn)證是汽車 SoC 軟件（ASoCS）中最主要的根本原因。無線局域網(wǎng)（WLAN）模塊占總漏洞的 37%（主要類別：CWE-126）。圖形處理器（GPU）模塊顯示出最多樣化的通用缺陷枚舉（CWE）類別。CWE-416 的緩解時間最長。無線局域網(wǎng)（WLAN）和進(jìn)程間通信（IPC）模塊的緩解時間變化較大。

5、討論

從 CPS 的角度來看，這些發(fā)現(xiàn)引發(fā)了重大擔(dān)憂。考慮到汽車行業(yè)正迅速向完全集中化的 SoC 和軟件定義的車輛架構(gòu)邁進(jìn)，在最壞情況下，單個軟件模塊的 CVE 可能被攻擊者輕易利用，以獲取整個系統(tǒng)的訪問權(quán)限。例如，假設(shè)一個由黑客控制的路側(cè)單元（RSU）或接入點(diǎn)向 SoC Wi-Fi 驅(qū)動程序（我們模型的無線局域網(wǎng)（WLAN）模塊的一部分）發(fā)送惡意信標(biāo)幀（MBF）。由于 wlan_mlo_t2lm.c 文件中存在現(xiàn)有的漏洞（CWE-126 類型，緩沖區(qū)越讀），該模塊將在沒有任何驗(yàn)證的情況下接受惡意信標(biāo)幀（MBF）。這可能導(dǎo)致各種安全問題，如因讀取未初始化內(nèi)存導(dǎo)致的數(shù)據(jù)泄露、Wi-Fi 棧崩潰導(dǎo)致的分布式拒絕服務(wù)（DDoS）、車與基礎(chǔ)設(shè)施（V2I）交通信號通信失敗、車與車（V2V）防撞警報(bào)失敗、車隊(duì)管理和空中下載（OTA）更新失敗等。

盡管我們的架構(gòu)并非直接基于 AUTOSAR 藍(lán)圖構(gòu)建，但其與 AUTOSAR 自適應(yīng)平臺在結(jié)構(gòu)和服務(wù)層上的相似性使我們能夠推斷潛在的集成和遷移用例。例如，對于采用 AUTOSAR（尤其是自適應(yīng)平臺）的組織，我們的發(fā)現(xiàn)提供了對基于 SoC 的系統(tǒng)中遇到的現(xiàn)實(shí)世界漏洞的實(shí)際視角。假設(shè)一個一級汽車供應(yīng)商正在將其信息娛樂和互聯(lián)電子控制單元（ECU）從專有實(shí)時操作系統(tǒng)（RTOS）過渡到 AUTOSAR 自適應(yīng)平臺。該電子控制單元（ECU）集成了基于驍龍的 SoC，并通過 Wi-Fi 支持車與基礎(chǔ)設(shè)施（V2I）功能。在這種情況下，我們的發(fā)現(xiàn)可以幫助安全負(fù)責(zé)人評估構(gòu)成最高安全風(fēng)險的模塊，以及應(yīng)優(yōu)先進(jìn)行緩解或架構(gòu)強(qiáng)化的領(lǐng)域。根據(jù)評估結(jié)果，該公司可以在第三方軟件采購過程中做出不同的集成強(qiáng)化決策、有針對性的模糊測試和緩沖區(qū)邊界檢查，并堅(jiān)持要求 Wi-Fi 驅(qū)動程序采用內(nèi)存安全實(shí)現(xiàn)等。

6、有效性威脅

我們在考慮研究的有效性時，采用了沃林和斯塔龍?zhí)岢龅目蚣堋?/span>

在構(gòu)念有效性方面，主要風(fēng)險是遺漏重要的汽車 SoC 軟件（ASoCS）漏洞。我們的研究方法和對開源 SoC 軟件的限制可能導(dǎo)致遺漏一些汽車 SoC 軟件（ASoCS）最受歡迎組件（如高級駕駛輔助系統(tǒng)（ADAS）或數(shù)字駕駛艙）中的漏洞實(shí)例。構(gòu)念有效性還可能受到實(shí)時模塊與高端模塊的納入 / 排除的影響。

在結(jié)論有效性方面，我們認(rèn)為主要風(fēng)險在于手動映射過程。盡管我們考慮使用自動化工具（如大型語言模型（LLM）），但我們選擇手動進(jìn)行，以便能夠驗(yàn)證結(jié)果或在需要時進(jìn)行討論。

緩解時間線的研究可能與模塊的架構(gòu)角色或集成深度相關(guān)，但我們也承認(rèn)，開源項(xiàng)目動態(tài)（如貢獻(xiàn)者活動和治理）可能會影響這些結(jié)果，這構(gòu)成了內(nèi)部有效性的潛在威脅。

外部有效性的一個關(guān)鍵限制是，汽車 SoC 軟件（ASoCS）架構(gòu)模型是從開源倉庫手動推導(dǎo)的，可能無法代表商業(yè) SoC 實(shí)現(xiàn)的所有變體。盡管我們將模型與 AUTOSAR 概念對齊，但我們承認(rèn)缺乏正式驗(yàn)證（如專家訪談或行業(yè)確認(rèn)的映射）。

7、結(jié)論與未來工作

隨著時間的推移，汽車 SoC 軟件架構(gòu)正變得更加集中化和復(fù)雜。這種演進(jìn)支持了諸如高效空中下載（OTA）更新、通過云環(huán)境提供更多客戶服務(wù)、無縫數(shù)據(jù)共享和優(yōu)化功耗等優(yōu)勢，但同時也放大了緊密集成的 CPS 平臺固有的安全風(fēng)險。本研究深入探討了汽車 SoC 軟件（ASoCS）架構(gòu)棧中一些最易受攻擊的區(qū)域。通過將 180 個現(xiàn)實(shí)世界的漏洞映射到軟件模塊、通用缺陷枚舉（CWE）類別、根本原因、芯片組和緩解延遲，我們識別出了關(guān)鍵趨勢，例如漏洞集中在 Wi-Fi 模塊以及頻繁出現(xiàn)的缺失大小 / 長度驗(yàn)證缺陷。

我們的模型源自公開可用的倉庫，并與 AUTOSAR 原則對齊，有助于識別在傳統(tǒng)安全審計(jì)中可能被忽視的易受攻擊組件。采用 AUTOSAR 的安全測試人員和架構(gòu)師可以利用我們的根本原因映射和延遲模式，優(yōu)先處理高風(fēng)險模塊、指導(dǎo)有針對性的強(qiáng)化，并在平臺采用過程中驗(yàn)證集成決策。未來的工作包括與 AUTOSAR 從業(yè)者和領(lǐng)域?qū)＜乙黄痱?yàn)證架構(gòu)模型，以及擴(kuò)展攻擊路徑分析以支持更廣泛的 CPS 領(lǐng)域。

（添加微信號NewCarRen咨詢）