智能網聯汽車軟件安全治理國際化啟示
文 | 中汽智聯技術有限公司 李翠萍 張巧
隨著智能網聯汽車功能的不斷豐富,汽車已從傳統機械裝置演變為集成電子系統和軟件的智能化終端。在機械驅動向軟件驅動轉型的過程中,軟件體系差異日益成為汽車價值差異化的關鍵,軟件及服務能力逐漸成為汽車產業的核心競爭力。然而,伴隨技術迭代加速,智能網聯汽車軟件安全風險呈顯著上升趨勢。中汽信息安全研究中心2023年發布的汽車行業十大風險報告顯示,安全風險的本質多源于不安全的固件和軟件代碼,“車輛固件和軟件存在已知漏洞”和“車輛固件和軟件可被非授權獲取”在十大風險源中分別位列第二和第三。全球汽車行業因軟件安全問題引發的安全事件也頻繁發生。針對智能網聯汽車,由于部分產品間可能還存在系統軟件復用的情況,因此,一旦出現軟件安全漏洞,則可能導致大量的車輛產品面臨安全風險,影響范圍廣泛。例如,2021年6月,特斯拉汽車宣布召回28萬余輛不同型號的電動汽車,相關召回車輛存在主動巡航控制系統安全問題,易造成駕駛員部分情形誤激活主動巡航功能,可能導致車輛速度突增,給安全駕駛帶來極大安全風險。2022年7月,本田無鑰匙進入系統被曝存在重放攻擊漏洞,影響幾乎所有本田系列車輛,黑客可遠程開鎖甚至啟動,給車輛財產和駕乘人員生命安全帶來極高風險。由此可見,重視智能網聯汽車軟件安全風險,提高汽車行業的軟件安全治理水平顯得尤為重要。
一、智能網聯汽車軟件安全風險分析
隨著互聯網和信息技術的飛速發展,軟件已經成為現代社會不可或缺的一部分,軟件安全問題在各行業都引發了高度重視。在汽車產業智能化、網聯化轉型進程中,智能網聯汽車高度集成的軟件系統,使其軟件安全風險呈現獨特性與復雜性,亟需開展系統性研究與應對。
(一)智能網聯汽車軟件安全風險由來分析
智能網聯汽車軟件安全風險并非孤立存在,其背后交織著產業生態與技術架構的多重因素。汽車行業供應鏈復雜、開源軟件廣泛應用以及軟件管理體系尚不完善等現狀,共同催生了日益嚴峻的安全風險,需從開發流程、技術應用、管理機制等維度深挖根源。
1. 多主體參與的軟件開發流程
智能網聯汽車軟件架構日益復雜,多主體參與的軟件開發流程增加了安全風險。智能網聯汽車嵌入式軟件架構可以大致分為系統架構、電子控制單元(Electronic Control Unit,ECU)、軟件組件(Software Component,SWC)三個層級,SWC層級可以細分為應用軟件(Application Software,ASW)和基礎軟件(Basic Software,BSW)。整車軟件開發工作工程量巨大,以單芯片艙駕融合軟件系統為例,系統涉及QNX、Linux等諸多的操作系統,其中,QNX約有1300萬行代碼,Linux kernel約4800萬行,AUTOSAR約8200萬行,安卓車機約2億行,同時,每家汽車制造商還有自己的架構平臺,平臺供應商平均就有300至600家。當前,汽車主機廠的部分ECU是直接從供應商采購或委外開發,對于涉及關鍵核心技術的ECU,主機廠可能負責算法和策略軟件的開發及軟件集成,對于BSW往往還是委外開發。從發展趨勢上看,雖然目前主機廠正在逐步形成自有軟件團隊,轉向自主開發或與供應商合作進行白盒開發,但受現階段的開發模式限制,智能網聯汽車軟件開發涉及參與主體眾多,不僅導致主機廠對車輛產品軟件資產可見性有限,也使得對于車輛產品的軟件質量和軟件安全的把控難度增加。
2. 開源組件引入的開源安全風險
智能網聯汽車產品中的開源軟件不斷增多,不可避免地引入開源安全風險。現代軟件大部分是由組件組成的,軟件中的90%的代碼由第三方編寫,包含了商業組件和開源組件。開源組件(Open Source Software,OSS),又稱開放源代碼軟件,是指遵循開源許可證的軟件工具、庫、接口或固件,可以被任何人自由地使用、修改和分發。這些組件通常由社區維護和支持,旨在幫助開發人員快速構建軟件并提高開發效率。根據網絡安全公司Cybellum《2022年汽車網絡安全現狀報告》統計,汽車產品中最常用的十大組件均為開源組件。新思科技《2024年度開源安全與風險分析報告》的統計分析結果也顯示,統計樣本中的所有汽車行業代碼庫均包含開源代碼。對于開源軟件,一方面其往往依賴于其他代碼庫和組件,從而導致安全風險的傳遞,統計數據顯示,汽車行業三分之一的代碼庫包含高風險漏洞,加之開源軟件的廣泛使用,極有可能將安全風險范圍進一步擴大;另一方面,開源軟件還面臨供應鏈“投毒”風險,攻擊者可以通過惡意破壞開源組件導致供應鏈下游軟件遭到破壞。此外,開源后門植入和開源數據泄露風險導致的安全事件也屢見不鮮,嚴重威脅著整個行業的安全。
3. 行業軟件管理維護及更新不足
行業的快速發展帶來了汽車軟件規模和復雜度的持續提升,現階段由于運營模式、開發效率以及成本控制等多方面的限制,針對汽車軟件的管理面臨著諸多困難,最終致使行業軟件管理維護及更新不足,運營安全風險日益增加。根據Cybellum《2023年汽車安全展望:實現安全的未來》報告,24%的汽車軟件產品包含10年以上的老版本軟件,例如bzip2-1.0.6、libcap-2.22、zlib-1.2.8等,這些老版本的組件庫會直接關聯各種漏洞,進而給車輛帶來不同程度的安全風險,部分CVSS 3.0評分為10.0的CVE漏洞仍然存在于車輛的嵌入式軟件組件中。同時,長期未維護的開源代碼庫也往往存在更高的安全風險,統計顯示,91%的代碼庫包含至少比最新版本落后10個版本的開源代碼,49%的代碼庫包含2年內未更新的組件,在汽車上廣泛使用的部分開源軟件項目也面臨長時間無人維護更新,繼續使用這些軟件組件將導致運營安全風險日益增加。
(二)智能網聯汽車軟件安全風險危害分析
相較于其他智能設備,智能網聯汽車運行場景的特殊性與系統架構的復雜性,決定了其安全風險的潛在危害更具破壞性。其高速動態運行特性、龐大的系統規模以及高頻的數據交互,使得軟件安全漏洞一旦被觸發,將迅速波及駕乘安全、交通秩序乃至國家安全等多個關鍵領域。
1. 安全漏洞威脅駕乘安全
軟件定義汽車時代下,汽車逐漸發展成為與電腦、手機等類似的與消費者有多重交互的電子產品,隨著汽車軟件服務的增多,車輛不可避免地會存在軟件安全漏洞。但與傳統電子產品不同,汽車軟件系統復雜、代碼量大,且汽車軟件安全漏洞一旦被黑客惡意利用,可能導致車輛失竊、重要數據泄露、車輛轉向及剎車控制等,輕則造成車輛財產損失,重則直接威脅駕乘人員的人身安全。
2. 功能安全問題易造成安全事故
車輛的智能化、網聯化功能高度依賴軟件,一旦軟件出現故障或者誤判,例如決策算法邏輯缺陷、傳感器數據處理錯誤或通信中斷等,可能導致車輛在行駛過程中出現失控或者誤操作,引發車輛碰撞或者失控等交通安全事故,影響社會安全。
3. 遠程攻擊帶來車輛非法控制風險
隨著汽車功能的豐富和服務的不斷升級,越來越多的遠程控車功能被廣泛使用,用戶可以通過手機控車軟件連接至車輛或者云端以實現遠程開關車門、啟動關閉引擎、燈光控制和鳴笛等操作。一旦遠程服務軟件被惡意攻擊者攻破,攻擊者就可以通過互聯網遠程入侵車輛的控制系統,且遠程服務端被非法入侵可能造成批量非法控車,使得風險等級大大提高。
二、智能網聯汽車軟件安全治理國際做法經驗
近年來,以電信、金融、醫療等領域為熱點攻擊對象的軟件供應鏈安全事件也引起了世界各國的高度重視,在軟件安全治理方面也推出了一系列的治理舉措,也已經有針對汽車行業的專門實踐,有必要總結相關的治理做法,從而提煉出可以指導汽車行業軟件安全治理的先進經驗。
(一)政策法規維度
針對軟件供應鏈的安全保護,美國受到SolarWinds供應鏈攻擊、微軟Exchange漏洞攻擊事件的警醒,早在2021年發布的《關于改善國家網絡安全的行政令》(EO 14028)中,就提出了針對軟件開發建立基線安全標準、確保信息技術服務提供商與政府共享威脅信息、設立網絡安全審查委員會等要求,其中,要求聯邦機構應在切實可行的范圍內,確保其采購或使用的軟件是根據安全軟件開發實踐開發和維護的,包括提供軟件物料清單(Software Bill of Materials,SBOM),其中列出所使用的庫、依賴項和自定義源代碼等組件。美國食品藥品監督管理局(FDA)規定,自2023年3月起,所有使用軟件的醫療設備都必須創建并維護SBOM。2024年3月,歐洲議會宣布批準了《網絡韌性法案》,法規要求所有出口歐洲的數字產品都必須提供安全保障、SBOM、漏洞報告機制和為期五年的補丁更新。
(二)實踐指南維度
為了進一步幫助行業企業高效落地開展軟件安全治理,在實踐指導維度,各國也發布了系列指南文件。2023年11月,美國多個政府機構部門聯合發布《保障軟件供應鏈安全:SBOM實踐應用相關指南》,詳細地提供了在軟件供應鏈中使用開源軟件的準則以及SBOM使用最佳實踐,并強調將供應鏈風險評估分配到采購決策中,持續更新和評估軟件產品的威脅與風險。2023年7月,日本經濟產業省(METI)商務和信息政策局發布《軟件管理引入軟件物料清單(SBOM)指南1.0版》,面向軟件供應商和使用方提供了采用SBOM開展軟件管理的具體實踐指南。相關指南提供了對于SBOM生成、交付、使用以及實施等多個環節的相關指導性建議,從而實現和保障軟件供應鏈中各利益相關方的網絡安全。同時,在漏洞利用性方面,美國國家電信和信息管理局(NTIA)于2021年推出漏洞可利用性交換(Vulnerability Exploitability eXchange,VEX),可與SBOM配合判斷有關軟件產品是否受到特定漏洞的影響。
(三)行業生態維度
在跨行業軟件安全治理方面,GitHub、Google、IBM等行業巨頭于2020年聯合牽頭成立開源軟件安全基金會(OpenSSF),通過建立開源開發者最佳實踐、保護關鍵項目、開源項目安全威脅識別、供應鏈完整性、安全工具和漏洞披露等專項工作組,以提高開源軟件安全性。在汽車行業,日本汽車信息共享與分析中心(Japan Automotive ISAC,J-Auto-ISAC)于2023年4月成立了軟件物料清單工作組(Software Bill of Materials-Software Working Group,SBOM-SWG),專門致力于促進提升汽車行業軟件供應鏈的透明度,重點針對有效管理和跟蹤汽車軟件組件的安全性。自2023年10月起,該中心同北美汽車信息共享與分析中心就SBOM工作開展合作,探索建立國際性的統一標準。2024年,J-Auto-ISAC宣布計劃于2025年統一日本汽車SBOM規則,以記錄車載軟件中的關鍵信息并應對潛在安全漏洞。
總體來看,各行業圍繞軟件開發安全、軟件供應鏈安全、軟件漏洞披露共享等在政策法規、實踐指南及行業生態維度采取了一系列治理舉措,且均重點圍繞SBOM開展軟件供應鏈透明度提升、威脅識別和漏洞披露跟蹤等重點工作。
三、啟示、思考及建議
汽車作為新的高集成化軟件集合體,智能網聯汽車中軟件安全問題會直接對車輛安全、用戶隱私乃至公共安全構成嚴重威脅,為進一步提升智能網聯汽車軟件安全治理水平,參考國際各行業軟件安全治理經驗,可從頂層設計、技術創新和行業生態等多方面協同發力。
(一)完善頂層設計,從企業維度和產品維度完善政策法規及標準建設
重視汽車行業軟件質量管理,加快推動相關政策規范制定工作,尤其是針對汽車企業在產品全生命周期過程中的軟件安全管理要求以及車輛產品的軟件安全基線要求,并做好相關技術標準的配套工作,提升汽車行業軟件安全治理制度化、規范化、程序化水平。進一步研判將SBOM納入汽車行業信息安全監管的必要性,并探索建立車聯網關鍵設備的SBOM強制性認證制度。同時,在行業指導維度,統籌推進汽車行業軟件安全治理實踐指南的制定,以行業相關主管部門作為牽頭單位,聯合行業研究機構、重點行業企業等主體,從行業實際需求出發,梳理適合我國國情的汽車軟件治理方案,供業內相關主體用作落地實踐參考。在汽車行業軟件供應鏈風險管控維度,應設置一定的行業供應商準入門檻,并要求汽車生產企業通過合同協議或其他方式強化對軟件供應商的約束及管理,增強汽車供應鏈的透明度,以便汽車企業能夠從源頭上強化軟件安全風險管控。從意識層面、行業指南層面、行業監管層面等多維度入手,強化汽車行業的軟件安全治理制度保障。
(二)加強技術研發,強化汽車行業亟須的軟件安全治理關鍵技術攻關
針對當前汽車行業軟件安全存在的軟件成分信息不透明、漏洞識別難度大、漏洞驗證門檻高以及潛在的開源軟件知識產權合規風險等行業共性問題,應加強車聯網專用軟件安全工具鏈的研發及技術攻關,面向智能網聯汽車軟件安全需求開展專門研究,包括汽車軟件安全開發流程體系、車聯網軟件成分分析技術、安全風險靜態檢測及動態檢測技術、模糊檢測技術等。研發端到端的車聯網軟件安全生命周期管理工具,升級汽車產品開發模型,在車聯網開發、安全與運維(DevSecOps)框架中集成軟件安全管理體系及SBOM生成和安全掃描等關鍵技術,結合自動化漏洞掃描工具,基于SBOM自動生成補丁,修復漏洞并發布更新,從而實現從原型車設計、零部件開發,到后期遠程升級技術(OTA)更新等各個環節都通過SBOM進行安全審查和管理,實現汽車軟件研發全生命周期的自動化安全漏洞管理,為汽車軟件的安全研發提供可靠保護。
(三)發揮行業力量,鼓勵行業組織探索建立汽車行業軟件安全治理組織
借鑒國際做法,支持并推動行業研究機構、第三方組織等牽頭成立我國汽車行業軟件安全治理組織或行業聯盟,鼓勵共同開展汽車軟件安全治理相關研究工作。搭建行業級的合作和交流平臺,匯聚政府部門、研究機構及企業的各類資源,在組織內開展技術交流、數據共享、軟件漏洞披露以及最佳實踐共享等。組織應包含汽車生產企業、零部件供應商、軟件開發商、開源社區組織等,核心推動行業數據資源匯聚,重點是各車企、供應商和研究機構,在一定的范圍內進行資產數據、安全數據的共享和匯集,從行業角度進一步提升汽車軟件供應鏈透明度,探索行業級的軟件安全風險數據交換機制,從而提升行業整體的安全防御能力。
四、結 語
隨著智能化、網聯化的進程加快,汽車日益成為一個高利用價值的移動智能終端,數據量激增和互聯接口增加使得對其網絡攻擊更加有利可圖,吸引了更多的黑客和惡意組織將攻擊方向轉向汽車行業,而軟件安全問題則不可避免地成為惡意攻擊的突破口。不同于其他行業,汽車軟件安全問題一旦被惡意利用,可能會造成個人隱私泄露、財產損失等不良影響,嚴重的還會對交通運行安全、社會公共安全乃至國家安全構成重大威脅。借鑒各行業軟件安全治理的做法經驗,應當構建自上而下的汽車軟件安全治理體系,逐步配套標準規范,加強供應鏈風險管控,強化關鍵核心技術攻關,同時充分發揮生態力量,從多維度逐步筑牢汽車行業軟件安全。
(本文刊登于《中國信息安全》雜志2025年第4期)